An MCP client can discover the tools offered by a server. That list tells the client what can be requested. It does not answer whether the current agent, task and target are permitted to cause the tool’s effect.
01 / Read the source
What the primary material says
The MCP tools specification describes listing and calling tools; the authorization specification describes access to protected resources. NSA’s design guidance reinforces the importance of examining tool and server trust. Enterprise policy over a particular action must be layered into the actual invocation and downstream boundary.
The MCP specification does discuss human involvement around tool calls. A confirmation prompt is valuable when a user understands and approves the specific effect, but it should not become a reusable permission for unrelated targets. The organization’s authorization model remains separate from the mere fact that a tool is exposed.
02 / Architectural consequence
Where the trust boundary changes
A customer-service agent sees a delete_customer tool because the shared server advertises it. The agent may legitimately read a customer record, while deletion requires a separate owner and approval. Hiding the delete tool can reduce accidental selection, but an alternate client or changed catalog could still call it unless execution is checked.
A list is a planning aid, not an enforcement boundary
A tool list can help the model choose an action and a client can hide tools to reduce mistakes. Neither changes what a determined or misconfigured caller can request from the server. A tool definition may change between discovery and invocation; its annotation is metadata, not a signed grant from the organization. At call time the server should validate the named tool and normalized arguments for the authenticated caller and task, then ensure the downstream action remains constrained.
03 / ProofGrid analysis
Authority beyond the credential
ProofGrid treats discovery, authentication and authority as different facts. A per-call decision binds the actor, originating task, operation, arguments and current constraints; the tool catalog is context, not the source of permission.
04 / A testable next step
What a security architect can do
Test a visible but unauthorized tool call, a hidden tool invoked directly and a permitted tool with forbidden arguments. Verify the final executor rejects all three improper effects and produces a reviewable reason.
Can a client invoke a tool without listing it first? What happens when the server updates a tool description or target? Does the policy inspect parameters as well as name? Does a direct downstream route avoid the call check? Each case should be verified, not inferred from the catalog UI.
Primary sources
Read the documents
Durable references