Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Confirmation and gated tools

Five tools can do damage that’s awkward to undo: down, destroy, update-etc-hosts, ca trust, and ca untrust. The server doesn’t run them on the first call. It asks the client to confirm with you.

How the handshake works

The server uses MCP’s multi-round-trip request mechanism, which relies on elicitation, the protocol’s way for a server to ask the user a question through the client.

  1. The agent calls a gated tool. The server doesn’t run it. It returns an “input required” result carrying a prompt, for example “Really run xianyun destroy? This destroys the local cluster and deletes all its data. This cannot be undone.”
  2. Your client shows the prompt to you.
  3. If you accept, the client retries the call with your answer attached, and the command runs.
  4. If you decline, the server returns exit code 1 and aborted at the user's request, and nothing happens.

Your client has to support it

The mechanism needs MCP protocol version 2026-07-28 or newer and a client that declares elicitation. A client that can’t answer gets an error, and the command doesn’t run:

tool 'xianyun_update-etc-hosts' failed to execute: config error: middleware asked the
client for input, which requires MCP protocol 2026-07-28 or newer; this client
negotiated 2025-11-25

That’s what a client on protocol 2025-11-25 sees. Check what your client negotiates. If it’s older, the gated tools are unavailable through MCP, which fails safe. Run the matching xianyun command in a terminal instead.

Even a dry run goes through the gate, so xianyun_update-etc-hosts with dry_run set returns the same error on an older client.

What the gate doesn’t do

The gate trusts whatever answer the client sends. It doesn’t remember that it asked. A client that attaches {"confirm": {"action": "accept"}} to the first call skips the prompt, and the command runs. That was measured on 2026-10-13 against xianyun_down.

An AI model can’t set protocol fields through ordinary tool arguments, so the realistic risk is a hostile or buggy client, not a prompt-injected model. It does mean the gate is a speed bump for a human-in-the-loop client and not a security boundary. See Security and TM-MCP-003.

The prompt also shows a general consequence message, not the arguments of the call. Look at the arguments your client displays.

Don’t auto-approve

Many clients can auto-approve tool calls. Leave the gated tools off any auto-approve list, and treat xianyun_up, xianyun_deploy, and xianyun_update with care too, since they can run hooks from your config.