Resources and prompts
Besides the 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 2026-07-28, it also asks for confirmation before running a destructive tool — including the ones that move money.
None of this opens a new path to your data: everything goes through the same tools, under the same permissions and the same access level. Every resource and every prompt here only reads, so a read token reaches all of them — as long as the person can run the tools behind them.
Resources
A resource is a document identified by a URI. You pick, for example, a payable, 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://finance/, so they coexist with those of other Kobana products in the same client.
| URI | What comes back |
|---|---|
kobana://finance/schemas | The catalogue of the API contract's schemas (JSON) |
kobana://finance/schemas/{schema} | One schema: the fields a tool returns or accepts (JSON) |
kobana://finance/payables/{id} | A payable (JSON) |
kobana://finance/receivables/{id} | A receivable (JSON) |
kobana://finance/financial-transactions/{id} | A transaction (JSON) |
kobana://finance/financial-accounts/{account_id} | A financial account (JSON) |
kobana://finance/financial-accounts/{account_id}/balances/latest | The account's most recent recorded balance (JSON) |
kobana://finance/people/{id} | A person — supplier, customer or both (JSON) |
kobana://finance/companies/{id} | A company in the workspace (JSON) |
kobana://finance/fiscal-documents/{id} | A received fiscal document (JSON) |
kobana://finance/attachments/{attachment_id} | An attachment's data and what it is linked to (JSON) |
kobana://finance/attachments/{attachment_id}/download | The attachment's file — receipt, bank slip, XML |
resources/list returns the fixed URIs and resources/templates/list the parameterized templates.
- Permissions. Each resource is read by the matching tool (
kobana://finance/payables/{id}isfinance_payables_get). It only shows up, and is only read, if you can run that tool. - Files. An attachment's file comes back as base64 bytes (
blob), or as text when it is text (an XML), up to 10 MB. Unlike the tool, which only describes the file, here the document is the answer: the client asked for it. - Not found. An unknown URI, or a record that does not exist in this workspace, is
-32002on 2025 and-32602on2026-07-28— see Errors. - Workspace. The URI carries no workspace: the resource is read in the connection's default workspace. Without a default — the person reaches several workspaces and the connection did not pin one —, reading a record resource fails with
workspace_required; use the tools, which takeworkspace_id. The schema catalog does not depend on a workspace. - No change subscriptions. The server is stateless: there is no
resources/subscribenor a list-changed notice.
Prompts
A prompt is a ready-made instruction you pick in the client that becomes the first message of the conversation. It only shows up if you can run all the tools it relies on. None of them moves money, edits or deletes: sending to the bank or charging is left for you to ask for explicitly.
| Prompt | Arguments | What it does |
|---|---|---|
overdue_payables | company_id (optional) | Lists the overdue payables still open, oldest first, with the total due. |
overdue_receivables | person_id (optional) | Lists the overdue receivables and groups them by customer, largest totals first. |
cash_flow_outlook | until (optional, YYYY-MM-DD; default: 90 days) | Today's balance and where cash is heading, week by week, with the lowest point. |
monthly_summary | month (optional, YYYY-MM) | What was paid, received and left open in the month. |
person_overview | person_id | A supplier or customer: their data and what is open on each side. |
A missing required argument, or a month/until in the wrong format, is -32602.
Completions
completion/complete suggests values as you type an argument:
- Ids (
person_id,company_id,account_idand the parameter of the record templates): the most recent records from the matching listing, by the typed prefix, under the same permission as that listing. If you cannot list, there is no suggestion. The records come from the connection's default workspace; without one, the list comes back empty. {schema}ofkobana://finance/schemas/{schema}: the contract's names, by prefix.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, cancel, send a payment to the bank, charge, transfer between accounts, reconcile or adjust a balance are flagged with destructiveHint. A client may or may not ask for confirmation because of it — so the server asks, and a destructive tool only runs with its confirmation:
- The first
tools/callruns nothing. It comes back withresultType: "input_required"and a one-question form: run this action, with these arguments? - The client shows the question and resends the same call with your answer.
- Only an explicit yes runs it. Declining or cancelling returns an
isErrorresult withUSER_DECLINED, and nothing changes.
The confirmation applies only to that call and only once: the same tool, the same arguments, the same person, organization and workspace, for 5 minutes. An answer cannot be reused for another bill or another action; if anything does not match, the server simply asks again. Resending a confirmation that already ran the tool returns confirmation_replayed — to repeat the action, call the tool again without requestState and confirm again.
Without a way to confirm, the tool does not run. The server can only ask on 2026-07-28, to clients that declare support for elicitation forms (elicitation: {} or elicitation: { form: {} } in clientCapabilities). On 2025, or with a client without that support, a tools/call of a destructive tool returns isError with confirmation_required and nothing is changed — reads and ordinary writes keep running. If the server itself cannot guarantee the confirmation at that moment, the answer is confirmation_unavailable, also changing nothing.