The confirmation gate on writes

Read tools (GET, “Type: Read” in the catalog) are just called. Write tools — create a lead, update an appointment, send a message… any tool marked “Type: Write” — require an extra argument: confirm: true.

How it works

1. Your assistant decides to call a write tool (say, nuntius_leads_create).

2. If the call does not include confirm: true, the MCP server rejects it before touching the API — nothing is created — and returns a readable summary of what it was about to do:

   {
     "error": "confirmation_required",
     "message": "This action requires confirmation. Review the summary and call again with confirm: true.",
     "action_summary": "POST /public/v1/leads (nuntius_leads_create) with customerName='Sample lead', quality='hot'"
   }

3. A well-behaved MCP client shows that action_summary to the person and only calls the tool again with confirm: true if the person explicitly approves.

4. With confirm: true, the call reaches the API and the lead is really created.

What the user sees

What the person sees on screen depends on their MCP client, not on Nuntius: each client decides how it presents an action_summary and how it asks for approval (a confirmation dialog, the assistant’s own message asking for a “yes”…). What Nuntius guarantees is the minimum floor: the MCP server never executes a write without an explicit confirm: true in the call, whatever the client — this doesn’t depend on the client “behaving well”, it’s a check the server itself makes before forwarding anything to the API.

Why it exists

It’s the same principle that governs the rest of the product: a language model can decide to call the wrong tool, or misread an instruction — the LLM is never, by itself, the only barrier before a real write. The mandatory confirm means that error, if it happens, stops at a text summary — never at a lead that got created, an appointment that moved, or a message that got sent without anyone approving it.

No deletions

No tool can delete anything — the public API has no DELETE endpoint anywhere (see Use cases and the full reference). The worst case of a badly confirmed write is one extra record or a stale value, never data loss.