Send inbox message
send_inbox_messageREAD$0.008 / callWRITE A LETTER INTO THIS PROJECT'S INBOX — the owner's mailbox, the first screen of their panel. Free on every plan. Use it for a REPORT worth a human read (a run finished and found something) or a QUESTION you cannot decide without the owner's own words. 🔴 THIS IS NOT A LOG LINE. The Inbox exists because a station runs unwatched — call this once per RUN, for what the run is worth reading, never once per tool call inside it. A letter for every step is exactly the failure this call exists to prevent: a mailbox nobody reads any more, which is worse than no mailbox at all. 🔴 NAME THE SUBJECT SPECIFICALLY. "Questions about the pricing page rewrite" lets a later run of yours recognise this letter at a glance and check whether it was answered; "Question" or "Update" does not, and by the time the owner has opened ten of those the mailbox is unreadable. body is Markdown, rendered as the owner reads it — headings, lists, links and code all work. Keep it to what a person needs, not everything the run collected. kind: "question" needs at least one line in questions (up to 6) — each becomes its own answer box under the letter, and the owner's typed reply comes back through list_inbox_messages on a LATER call, matched to the same question by position. A question with nothing in questions is refused: without a box there is nothing for the owner to answer, and it is a report wearing the wrong kind. kind: "report" may not carry questions, for the same reason in reverse. list_inbox_messages FIRST, to see what you already asked and whether it was answered — asking the same thing twice because a status was never checked is the other way this becomes noise.
Workspace ID (optional when MCP endpoint is auto-scoped). Numeric workspace id — OR the project as the user names it: 'owner/repo', the repo name alone, the site's display name, its docs URL or custom domain. Text is resolved server-side; an ambiguous name returns the candidates instead of guessing, so pass what the user said rather than calling list_workspaces first.
report — something finished that is worth a human read. question — something you cannot decide without the owner; needs questions. One of: report, question.
The mailbox's subject line — name the SPECIFIC topic ('Questions about the pricing page rewrite'), never a generic 'Report' or 'Question'. One line, no trailing period.
The letter, in Markdown — what actually happened, or what you need decided, written for the owner to read cold. No call ids or tool names unless they are themselves what the owner asked about.
Default neutral. ok — finished well. error — finished badly, printed in red. due — a deadline or something owed. Never error for a question the owner merely needs to answer; that paints asking for input as a failure. One of: ok, error, due, neutral.
For kind: "question" only — one short prompt per thing you need typed, in order. Each renders as its own answer box; the reply comes back from list_inbox_messages as that question's answer, null until the owner types one.
Call it#
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "send_inbox_message",
"arguments": {
"kind": "report",
"subject": "<subject>",
"body": "<body>",
"tone": "ok"
}
}
}curl -X POST 'https://docsbook.io/api/mcp/server' \
-H 'Authorization: Bearer dbk_YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"send_inbox_message","arguments":{"kind":"report","subject":"<subject>","body":"<body>","tone":"ok"}}}'