Resources and prompts

Besides tools, the server offers three things the client uses on its own: resources (documents the user attaches to the conversation), prompts (ready-made scripts the user picks) and completions (autocomplete for their arguments). On the 2026-07-28 era 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 token scope. Resources, prompts and completions all count as reading.

Resources

A resource is a document identified by a URI. The user picks, say, a charge, and the client reads the document and puts it in context, without the model having to call a tool. Each resource is read by a read tool:

URI	Tool	What comes back
kobana://dunning/me	dunning_me	The connection's identity: person, organization, scopes, token expiry (JSON)
kobana://dunning/metrics/recovery	dunning_metrics_recovery	Recovery metrics (JSON)
kobana://dunning/notification-preferences	dunning_notification_preferences_get	The organization's notification preferences (JSON)
kobana://dunning/people/{id}	dunning_people_get	One debtor (JSON)
kobana://dunning/people/{id}/statement-pdf	dunning_people_statement_pdf	The debtor's statement (PDF)
kobana://dunning/charges/{id}	dunning_charges_get	One charge (JSON)
kobana://dunning/charges/{id}/settlement-pdf	dunning_charges_settlement_pdf	The settlement letter (PDF) — paid charges only
kobana://dunning/agreements/{id}	dunning_agreements_get	One agreement (JSON)
kobana://dunning/agreements/{id}/pdf	dunning_agreements_pdf	The agreement term (PDF)
kobana://dunning/disputes/{id}	dunning_disputes_get	One dispute (JSON)
kobana://dunning/collection-rules/{id}	dunning_collection_rules_get	One collection rule (JSON)
kobana://dunning/collection-rules/{id}/steps	dunning_collection_rule_steps_list	The rule's steps (JSON)
kobana://dunning/templates/{id}	dunning_templates_get	One message template (JSON)

resources/list returns the fixed URIs and resources/templates/list the templates with {id}.

• Permissions. A resource is only listed, and only read, if you can run its tool.
• Binaries. PDFs come back base64-encoded (blob), up to 10 MB. Unlike the tools, which only describe 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 organization, is -32002 on the 2025 era 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 can run all the tools it relies on.

Every prompt only reads. None of them sends a message, reports to a credit bureau or files a protest: they end by suggesting next steps and tell the model not to act on them unless you ask.

Prompt	Arguments	What it does
review_overdue_charges	person_id (optional, UUID)	Overdue charges — status overdue, or pending with a due date up to yesterday (the date is computed for the model) — in a table by age, grouped by delay band (up to 30, 31–90, over 90 days), with suggested next steps.
debtor_overview	person_id (required, UUID)	One debtor's picture: their data, charges, agreements and latest interactions.
recovery_report	months (optional, 1–24, default 6)	Recovery report: amount and number recovered, recovery rate, average days overdue, average collection-rule steps, what is still overdue, a monthly series and breakdowns by payment method and channel.
pending_legal_actions	—	Credit-bureau reports and protests in pending status (waiting for human approval), pointing out inconsistencies. It approves and cancels nothing.

A missing required argument, or one in the wrong format, is -32602.

Completions

completion/complete suggests values while you type an argument:

• person_id, and the {id} of people, charges and templates: searches the matching listing with search, under its permission.
• The {id} of agreements, disputes and collection-rules: takes the most recent ids from the listing and filters them by the prefix you typed.
• months: 3, 6, 12, 24.

With no source for suggestions — or no permission to list — the answer is an empty list, never an error. At most 100 values come back.

Confirming destructive tools

Destructive tools carry destructiveHint. They are the ones that:

• delete or archive, bulk operations included;
• cancel — charges in bulk, agreements, protests, credit-bureau reports;
• talk to the debtor or a third party — dunning_charges_notify, dunning_notifications_create, dunning_notifications_resend, reporting to a credit bureau (dunning_negativations_create), protesting (dunning_protests_create), approving a credit-bureau report or protest (dunning_negativations_update, dunning_protests_update), and testing or retrying a webhook;
• apply a collection rule to charges (dunning_charges_bulk_assign_rule), since that triggers messages;
• decide on the debt — accepting an agreement (dunning_agreements_accept), resolving a dispute (dunning_disputes_update), creating or ending a discount campaign;
• rotate the webhook secret.

An ordinary configuration update (*_update) is not destructive.

The server does not rely on the client alone: on the 2026-07-28 era, with a client that declares form elicitation, it asks for confirmation itself:

1. The first tools/call runs nothing. It comes back with resultType: "input_required", an inputRequests.confirm (an elicitation/create with one boolean, "Run this action") and a requestState.
2. The client shows the question and re-sends the same call with the requestState and the answer in inputResponses.confirm.
3. Only action: "accept" with confirm: true runs it. Anything else returns an isError result with USER_DECLINED, and nothing changes.

The confirmation holds only for that call: the same tool, the same arguments, the same person and organization, for 5 minutes. If the state is missing, expired or tampered with, the server simply asks again. And it is single-use: re-sending a call that was already confirmed returns isError with confirmation_replayed, and nothing runs — to repeat the action, call the tool again and confirm again.

A client that cannot confirm — on the 2025 era, or on 2026-07-28 without form elicitation — does not run destructive tools: the call returns isError with confirmation_required and nothing is executed. Reads and ordinary writes keep working. If the server cannot record the confirmation at that moment, the tool is refused too, with confirmation_unavailable; try again later.