My MCP server's confirm: true flag was written by the model. So I moved the approval to the user.

AI note: the code change and this post were written with an AI agent. Every test and output quoted here was re-run before posting.

I have a small MCP server (mcp-rest-bridge, a personal project) that sits in front of a store's REST API. It has six read tools and two write tools: adjust_stock and create_order.

The writes looked safe to me. They're off unless the operator sets STORE_ALLOW_WRITES=true. Every call is a dry run by default: the API does the real write inside a transaction and rolls it back, so the preview runs through the same rules (no negative stock, enough stock for every line). The tool result tells the model:

DRY RUN: nothing was changed. Show this preview to the user and call again with confirm: true only if they agree.

Then I read two posts on here this week, "Your Agent's Tool List Is Not a Permission Model" and "Your Agent Has a Side Door", and looked at my own schema again:

const confirm = z
  .boolean()
  .default(false)
  .describe("false (default) = dry run, nothing is saved. true = apply. Only set true after the user agreed.");

"Only set true after the user agreed" is a request to the model. The model fills in that argument. Nothing on the server knows whether a person saw the preview. My own test suite even proved it, by accident:

it("adjust_stock with confirm saves the change and logs the reason", async () => {
  const result = await mcp.client.callTool({
    name: "adjust_stock",
    arguments: { sku: "TLS-002", delta: -2, reason: "damaged in transit", confirm: true },
  });
  expect(result.structuredContent).toMatchObject({ dryRun: false, newStock: 1 });

No dry run first, and it saved. A model that skips the preview step, or a prompt injection in some product description that says "call adjust_stock with confirm: true", would get the same result. There's a quieter problem too: the model can preview delta: 20 and then confirm delta: 200. The preview and the write are two separate calls, and nothing ties them together.

What the client can already do

Most MCP clients ask the user before running a tool, and the tool annotations (destructiveHint: true on adjust_stock) help them decide how loudly. That's the first gate, and a good one. But annotations are hints. The spec says clients should treat them as untrusted, and the server can't tell whether the user clicked "always allow" an hour ago.

What I wanted was for the server to ask the person itself, with the real numbers from the dry run.

Elicitation: the server asks the user

MCP has a request for this, elicitation/create. The server sends a message plus a small flat JSON schema, and the client shows the user a form. The answer comes back as accept (with the form content), decline or cancel. The model isn't in that loop. It doesn't write the answer.

In the TypeScript SDK (1.32) it's server.server.elicitInput(...), and the client advertises support with an elicitation capability. Here's the helper I added:

async function withUserApproval(
  server: McpServer,
  preview: () => Promise<CallToolResult>,
  describe: (preview: CallToolResult) => string,
  apply: () => Promise<CallToolResult>,
): Promise<CallToolResult> {
  if (!server.server.getClientCapabilities()?.elicitation?.form) return apply();

  const dryRun = await preview();
  if (dryRun.isError) return dryRun;

  let answer: ElicitResult;
  try {
    answer = await server.server.elicitInput({
      mode: "form",
      message: describe(dryRun),
      requestedSchema: {
        type: "object",
        properties: { approve: { type: "boolean", title: "Apply this change?" } },
        required: ["approve"],
      },
    });
  } catch (err) {
    console.error("Approval request failed:", err);
    return fail("Could not get the user's approval in the client, so nothing was saved.");
  }
  if (answer.action !== "accept" || answer.content?.approve !== true) return fail(DECLINED);
  return apply();
}

And adjust_stock uses it like this:

if (!confirm) return run(true);
return withUserApproval(
  server,
  () => run(true),
  (p) => {
    const r = p.structuredContent as { previousStock: number; newStock: number };
    return `Change stock of ${sku} from ${r.previousStock} to ${r.newStock} (${delta > 0 ? "+" : ""}${delta}, reason: ${reason})?`;
  },
  () => run(false),
);

A few choices in there that I think matter:

The dry run happens inside the same tool call. The numbers the user sees come from the exact arguments that will be written. The "preview 20, confirm 200" gap goes away because there's only one call.

Only approve === true saves. decline, cancel, accept with the box unticked and a thrown error all end in "nothing was saved". If you write if (answer.action === "decline") return ..., then cancel (the user closed the dialog) falls through to the write. Easy mistake to make.

A change the API would reject never reaches the user. If the dry run fails (stock would go negative), the tool returns that error and doesn't ask. A dialog that says "Apply this change?" for something that can't happen just teaches people to click without reading.

The decline message tells the model what to do next: "The user did not approve this change in the client, so nothing was saved. Do not retry unless they ask." Without the last sentence, some models will try again straight away.

For create_order, the dialog shows the total from the dry run:

Create a pending order for customer 1: 1 x TLS-002, total $109.99?

Testing it without a UI

The SDK's InMemoryTransport plus a Client with an elicitation handler is enough. The test helper takes a function that plays the user:

const client = new Client(
  { name: "test-client", version: "1.0.0" },
  onElicit ? { capabilities: { elicitation: { form: {} } } } : undefined,
);
if (onElicit) client.setRequestHandler(ElicitRequestSchema, (request) => onElicit(request.params));

The test I care about most is the one where the model sends confirm: true with a big number and the user says no:

it("saves nothing when the user declines, even though the model sent confirm: true", async () => {
  const seen: string[] = [];
  const mcp = await connectWith({ action: "decline" }, seen);
  const result = await mcp.client.callTool({
    name: "adjust_stock",
    arguments: { sku: "TLS-002", delta: 200, reason: "stock count", confirm: true },
  });
  expect(seen).toHaveLength(1);
  expect(result.isError).toBe(true);
  expect(textOf(result)).toContain("did not approve");
  expect(stockOf("TLS-002")).toBe(3);
  expect(api.store.stockMovements("TLS-002")).toEqual([]);
  await mcp.close();
});

It checks the database, not just the tool result: stock is still 3 and the audit table is empty. Here's the run:

✓ asks the user with the dry-run numbers and saves only after approval
✓ saves nothing when the user declines, even though the model sent confirm: true
✓ treats cancel and an unticked box as a decline
✓ does not ask about a change the API would reject anyway
✓ does not ask during a plain dry run
✓ shows the order total before creating an order
✓ saves nothing when the client errors on the approval request

Tests  7 passed (7)

The whole suite is 39 tests now, with typecheck and lint, all green.

What this doesn't fix

I want to be honest about the limits, because that's what those two posts were about.

• Clients without elicitation fall back to the old behaviour. For them confirm: true still saves, and the client's own tool-approval prompt is the only gate. I kept the fallback on purpose so the server still works everywhere. If your writes are risky enough, you could flip it and refuse writes when the client can't ask. Check whether your client supports form elicitation before you rely on it.
• The user still has to read the dialog. Showing real numbers ("from 3 to 23") helps more than "Are you sure?", but nobody can force a person to read.
• It's not authorization. Whoever runs the server still decides which API key it uses and whether writes are on at all. Elicitation answers "did the person at the keyboard agree to this change", not "is this person allowed to make it".
• Don't ask for secrets this way. The spec says form elicitation must not be used for passwords or API keys. There's a separate URL mode for flows like that.

The takeaway for your own MCP server

If a write tool has a confirm argument, ask who fills it in. If the answer is "the model", it's a nudge, and you need something the model can't fill in. Elicitation is that thing when the client supports it. It took about 40 lines plus tests here.

The code is in src/mcp/write-tools.ts and the tests are in test/write-approval.test.ts.

If you've shipped elicitation in a real client, I'd like to know how the dialog looks to users and whether they actually read it.