01 / The difference
Two facts that must stay separate
A client lists a delete_customer tool to plan a workflow, but its current assignment permits only reading the customer record.
MCP tool discovery tells a client what a server offers; authorization still needs to decide whether a specific caller and task may execute a specific invocation.
Filter visibility when useful, then always recheck permission at tools/call and downstream execution because catalogs change.
- 01Client / task
- 02MCP server
- 03Tool call + arguments
- 04Downstream effect
02 / Decision boundary
Put the check where it can stop the effect.
Filter visibility when useful, then always recheck permission at tools/call and downstream execution because catalogs change.
Architecture review / negative test
Make the boundary testable.
A tool list is a capability advertisement, possibly filtered for convenience. It is not an immutable contract: servers can change definitions, clients can cache them, and another client may call a name directly. The action decision should use the current tool implementation and its actual arguments.
03 / Failure and evidence
What goes wrong, and what can be proven?
A hidden tool is callable through another route, or a visible tool is assumed safe for every argument.
Compare discovery version, invocation arguments and action decision for incident review.
04 / Canonical scope
Why this reference stands alone
MCP tool authorization covers how to decide a call; this distinction explains why catalog or allowlist is not the decision.
Primary references