MCP First-Invoke Approval Checklist

A launch checklist for clients that discover MCP tools dynamically. The goal is simple: no newly discovered tool should run for the first time until the user understands the action class, data boundary, approval rule, and rollback expectation.

First-use gate

1. Classify the tool

Group the tool before first use: read public data, read private data, draft external output, write internal records, execute code, change permissions, or financial/identity/credential action.

2. Show the first-call preview

Before invocation, show the server, tool name, action class, destination, requested arguments, data classes used, and whether untrusted content influenced the call.

3. Require explicit approval

Ask on first invocation for any tool that reads private context, writes, sends, deletes, executes code, changes permissions, or reaches a person. Block financial, identity, credential, card, bank, tax, and OAuth setup flows from autonomous use.

4. Record a receipt

Store a non-sensitive receipt with policy id, side-effect class, approval state, redaction result, denied tools, reviewer, rollback expectation, and replay result.

Acceptance criteria

  • Newly discovered tools start in `ask` or `deny` until classified.
  • Approval is tied to side-effect class and destination, not just tool name.
  • Untrusted document, page, email, ticket, issue, OCR, or tool output cannot grant approval.
  • Consent can be remembered only as a narrow rule: server, tool, action class, destination, data class, and argument shape.
  • The client fails closed if the policy engine, redactor, approval UI, or receipt writer is unavailable.
  • Every write/send/delete/execute/permission action has a rollback or disable expectation before launch.

Minimum receipt shape

tool_server: placeholder-mcp-server tool_name: placeholder_tool action_class: write_internal_record first_invocation: true approval_state: ask untrusted_input_involved: true redaction_result: no sensitive fields included decision: denied until explicit user approval rollback_expectation: restore previous record state replay_result: same fixture produced same decision

Launch rule

Do not ship dynamic MCP tool discovery with auto-invocation unless first-use approval, receipt logging, prompt-injection fixtures, and rollback expectations all replay cleanly. This page is a public planning aid, not legal advice, compliance certification, penetration testing, incident response, or a security guarantee.