Resources and prompts

Besides tools, the server offers three things the client uses on its own: resources (documents you attach to the conversation), prompts (ready-made scripts you pick) and completions (autocomplete for the arguments of both). On era 2026-07-28, it also asks for confirmation before running a destructive tool.

None of this opens a new path to your data: everything goes through the same tools, under the same permissions and the same scopes. Every resource and prompt here only reads, so a read-only token reaches all of them — as long as the person may run the tools behind them.

Resources

A resource is a document identified by a URI. You pick, say, an e-mail, and the client reads the record and puts it in the context, without the model having to call a tool. The URIs live under kobana://inbox/, so they sit alongside those of other Kobana products in the same client.

URI	What comes back
kobana://inbox/models	The LLM models an agent can run on, with their prices (JSON)
kobana://inbox/usage	E-mails processed, runs, tokens and cost of the workspace over the last 30 days (JSON)
kobana://inbox/workspaces/{id}	One workspace, with its limits (JSON)
kobana://inbox/inboxes/{id}	One inbox: address, agent, recipients, filters and attachment rules (JSON)
kobana://inbox/emails/{id}	One received e-mail: headers, body, attachments and processing status (JSON)
kobana://inbox/emails/{id}/eml	A short-lived signed URL to download the raw .eml (JSON)
kobana://inbox/agents/{id}	One AI agent: model, system message and skills (JSON)
kobana://inbox/agent-runs/{id}	One agent run: status, output, tokens and cost (JSON)
kobana://inbox/workflow-runs/{id}	One workflow run: the steps and their outcome (JSON)
kobana://inbox/webhooks/{id}	One outbound webhook: URL, events and status (JSON)
kobana://inbox/system-events/{id}	One entry of the event log, with its payload (JSON)

resources/list returns the fixed URIs and resources/templates/list the parameterised templates.

• Permissions. Each resource is read by the matching tool (kobana://inbox/emails/{id} is emails_get). It is only listed, and only read, if you may run that tool.
• Secrets. There is no secret resource — not even the metadata. Use the secrets_* tools.
• Not found. An unknown URI, or a record that does not exist in this workspace, is -32002 on era 2025 and -32602 on 2026-07-28 — see Errors.
• No change subscriptions. The server is stateless: there is no resources/subscribe and no list-changed notice.

Prompts

A prompt is a ready-made instruction you pick in the client, which becomes the first message of the conversation. It is only listed if you may run every tool it relies on. None of them writes: reprocessing an e-mail or deleting anything stays for you to ask explicitly.

Prompt	Arguments	What it does
review_failed_runs	since (optional, YYYY-MM-DD; default: last 7 days), agent_id (optional)	Finds the failed agent runs, groups them by cause and points at the e-mails behind them.
inbox_overview	inbox_id	One inbox's picture: its configuration, the latest e-mails and how its agent is doing.
webhook_health	—	Which outbound webhooks are failing to deliver, and since when.
usage_report	month (optional, YYYY-MM)	What the workspace processed and spent in the month, by model.

A missing required argument, or since/month out of format, is -32602.

Completions

completion/complete suggests values while you type an argument:

• Ids (inbox_id, agent_id and the parameter of the record templates): the most recent records of the matching listing, by the typed prefix, under the same permission. If you may not list, there is no suggestion.
• month: the last twelve months.

With no source of suggestions, the answer is an empty list, and you keep typing.

Confirming destructive tools

Tools that delete, send something outside (webhooks_test, webhooks_deliveries_replay, emails_reprocess — the agent may reply or act), rotate a webhook secret or change who may send to an inbox (inboxes_add_recipient, inboxes_remove_recipient) are flagged destructiveHint. The server confirms each of them with the user before running it:

1. The first tools/call runs nothing. It comes back with resultType: "input_required" and a one-question form: run this action, with these arguments?
2. The client shows the question and sends the same call again with your answer.
3. Only an explicit yes runs it. Declining or cancelling comes back as an isError result with user_declined, and nothing changes.

The confirmation is valid for that call only, and once: the same tool, the same arguments, the same person, organization and workspace, for 5 minutes, and it runs the action a single time. An answer cannot be reused for another record or another action — if anything does not match, the server simply asks again — and sending the same confirmed call a second time answers confirmation_replayed without running anything. To run it again, call the tool without requestState and answer the new question.

Asking needs protocol 2026-07-28 and a client that declares support for elicitation forms. Any other client cannot run a destructive tool: on era 2025, or without that support, the call answers confirmation_required and nothing runs. If the server cannot take the confirmation at that moment, the call answers confirmation_unavailable, also without running anything — try again later.