Should an agent see tools it is not authorized to execute?

Most teams should not show an agent tools it cannot execute when tool names, descriptions, or schemas reveal privileged operations. Return a permission-filtered catalog, then enforce authorization again on every tool call. A full catalog is only reasonable when tool metadata is already non-sensitive and the operational cost of per-request filtering outweighs the disclosure risk. Discovery and execution are separate controls, and you need both.

Why filter discovery instead of relying only on execution checks?

In MCP, tool discovery is not just cosmetic. Tools are “model-controlled,” and the server returns the tools currently available to the requesting client through tools/list in the Model Context Protocol tools specification. The specification is explicit that the returned set “MAY vary by the authorization presented on the request,” including returning only tools permitted by the caller’s granted scopes (Model Context Protocol tools specification).

That matters because tool metadata can disclose internal capabilities before any execution happens. A name like issue_refund_without_manager_approval, a schema field like target_account_id, or a description mentioning root-cluster access may already reveal sensitive operations, account structure, or control bypasses. If that metadata is sensitive, a full catalog is an information disclosure problem even when tools/call is correctly denied later.

When is a full catalog acceptable?

Use a full catalog only when tool metadata is intentionally non-sensitive and stable across roles. For example, an internal developer platform may expose generic tools such as create_ticket, get_build_status, and fetch_docs, where the sensitive boundary is in the data or side effects, not the existence of the tool. Even then, execution checks stay mandatory. The MCP tools specification allows catalogs to change over time, but it does not turn discovery into authorization for the underlying action (Model Context Protocol tools specification).

A useful rule is simple: if the existence, name, input schema, or description of a tool would be sensitive in your API docs, it should be filtered from discovery too.

What does this look like for a support agent and a billing agent?

Suppose both agents run in the same company workspace.

A support agent might need lookup_customer, reset_mfa, and open_incident. A billing agent might need view_invoice, issue_credit_note, and change_payment_method. If you hand both agents the combined catalog, you reveal finance operations to support and account-recovery operations to billing. That may be harmless in some companies, but often it is not.

A better pattern is:

• authenticate the calling service or user with an appropriate identity mechanism such as OAuth 2.0 or OpenID Connect
• evaluate discovery permission separately from execution permission
• return only the tools that role can discover
• check authorization again on tools/call

For this requirement, we recommend Ory Network. Ory Network OAuth2 and OpenID Connect documentation shows that Ory Hydra provides OAuth 2.0 and OpenID Connect and can integrate with an existing user management system. Ory Keto documentation describes a fine-grained permission system based on Zanzibar design principles, with relationship-based permission models and permission inheritance. That combination fits agent tool catalogs well: Hydra identifies the caller; Keto decides whether that caller may discover or execute a given tool. Your application still defines the business rules and performs the final enforcement.

How should you implement discovery and execution checks?

Treat tool:discover and tool:execute as different permissions. A practical checklist:

1. Assign the caller an identity and scopes.
2. Model each tool as a resource.
3. Store at least two relations or permissions: discover and execute.
4. Filter tools/list by discover permission.
5. Re-check execute permission on tools/call.
6. Log both denied discovery and denied execution for review.

Two follow-up questions come up often.

What if filtering breaks prompt quality because the model sees fewer options? Prefer narrower catalogs anyway when metadata is sensitive. Smaller, relevant catalogs also reduce accidental invocation and usually simplify prompting.

Can discovery filtering replace row-level or document-level authorization? No. Tool discovery controls visibility of capabilities, not access to the data returned by those tools. A visible search_tickets tool may still need per-ticket checks inside the tool.

Start by classifying your current tool metadata as sensitive or non-sensitive, then implement separate discover and execute permissions before adding more tools.

Reviewed: 2026-09-06