What is Tool Discovery?

Discovery is the first half of MCP's tool model — before any tool call, the client issues tools/list (paginated via an optional cursor) and receives tool definitions: name, optional title, description, inputSchema, optional outputSchema, and optional annotations. These definitions are what the language model reads when deciding which tool to invoke.

Tool sets are dynamic. Servers that declare the listChanged capability should send notifications/tools/list_changed whenever their tools change, prompting the client to re-fetch. That flexibility is useful — servers can add tools, gate them on auth state, or retire them — but it also means what you reviewed yesterday is not guaranteed to be what runs today:

• Rug pulls — a server can serve benign definitions at review time, then swap in altered descriptions or schemas later (see MCP rug pull). The spec itself warns that clients must treat tool annotations as untrusted unless the server is trusted.
• Tool sprawl — across a fleet of servers, discovery surfaces hundreds of tools into the model's context, inflating cost and making manual review impractical (see MCP tool sprawl).

Discovery-time review — capturing what tools/list returns, diffing it against what was previously approved, and alerting on change — is therefore a control point in its own right, distinct from call-time enforcement.

PolicyLayer's crawler performs discovery at scale: it extracts tool definitions from thousands of public MCP servers and classifies each tool's risk in the catalogue at policylayer.com/tools, with per-server context cost at policylayer.com/token-cost. In the hosted gateway, registered servers' tool sets are known to the control plane, so policies bind to specific tools and unexpected changes in a server's tool list are visible rather than silently absorbed.