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.
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
Before invocation, show the server, tool name, action class, destination, requested arguments, data classes used, and whether untrusted content influenced the call.
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.
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
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.