Modern AI agents discover capabilities through several layers: static configuration, MCP tool catalogs, A2A Agent Cards, skill metadata and searchable registries. Discovery is becoming its own infrastructure problem because loading every tool and agent into every prompt does not scale.
Keep three decisions separate: what exists, which candidate best fits the task and whether the caller is allowed to use it.
Five Discovery Patterns
| Pattern | Use |
|---|---|
| Static config | Small stable capability sets |
| MCP listing | Tools/resources on a known server |
| A2A Agent Card | Capabilities of an agent |
| Registry | Search across many agents/servers |
| Semantic skill search | Find capabilities by intent |
Static Configuration
Explicit allowlists remain the safest and simplest discovery mechanism for small systems. Dynamic discovery should solve a real scale problem rather than replace understandable configuration with unnecessary complexity.
MCP Tool Discovery
A client can learn what a known MCP server exposes. Tool names, descriptions and schemas help the agent choose a capability. The July 2026 MCP revision adds cache hints for capability lists, reducing repeated catalog retrieval.
MCP Is Not a Global Directory
MCP tells you what a connected server can do. A separate registry, marketplace or configuration layer answers which servers exist in the organization.

A2A Agent Cards
An Agent Card describes identity, endpoint, capabilities, security requirements and skills. It gives a client structured information to decide whether an agent is relevant before delegation.
A2A Skills
Skills are descriptive capabilities with fields such as ID, name, description, tags and examples. They are useful for search and routing but do not guarantee quality.
Agent Registries
Google Cloud Agent Registry illustrates ecosystem-level discovery. It catalogs agents, MCP servers, endpoints and skills and supports searches across different capability types.
Keyword and Prefix Search
Keyword search is transparent and useful when vocabulary is known. Prefix search supports low-latency autocomplete and developer interfaces. Both are deterministic compared with semantic matching.
Semantic Search
Google Cloud currently documents semantic search for standalone skill content. This can match intent when the user does not know the exact capability name. Because semantic search is probabilistic, results should still be filtered and validated.
Discovery vs Routing
Discovery produces candidates. Routing considers capability fit, identity, owner, region, latency, availability, cost, historical quality and data sensitivity before choosing one.
Discovery vs Trust
A malicious provider can advertise an attractive description. Validate identity, signatures where applicable, ownership and policy. Metadata is a resume, not a security guarantee.
Discovery vs Execution
Finding a destructive tool should not give the agent permission to call it. Tool authorization and task policy must remain separate from search relevance.
Context Efficiency
Discovery can reduce context pressure by loading full schemas only for a small set of relevant capabilities instead of sending hundreds of tool definitions into the model.
Secure Discovery Pipeline
- Interpret the goal.
- Extract required capabilities.
- Search approved catalogs.
- Filter by identity and policy.
- Rank candidates.
- Load minimal metadata.
- Grant minimum permissions.
- Execute in a bounded environment.
- Validate and log the result.
Bottom Line
MCP helps discover what a known server can do; A2A describes what an agent can do; registries search across many providers. Safe systems keep discovery, routing, authorization and execution as separate decisions.
Discovery Quality
Discovery metadata should be written for machines and humans. Tool descriptions need clear side effects and required inputs. Agent skills need narrow scope and representative examples. Vague metadata makes semantic routing unreliable and increases the chance that an orchestrator chooses the wrong capability.
Capability Taxonomy
Large organizations benefit from a shared taxonomy: read, write, analyze, communicate, transact, administer and so on. Taxonomy labels can complement natural-language descriptions and make policy filtering easier. For example, a research workflow can automatically exclude capabilities labeled transact or administer.
Freshness
Discovery systems need to know whether a capability is still alive. Track heartbeat or health information, last update time, supported protocol versions and deprecation state. A semantically perfect result is useless if its endpoint is retired.
Owner and Environment Filters
Before semantic ranking, filter structured constraints: production approval, owner, region, data classification and user authorization. This prevents the model from seeing attractive but prohibited capabilities.
Ranking Signals
After policy filtering, rank by semantic fit, historical success, latency, cost and availability. A specialist with slightly lower semantic similarity but a much higher success rate may be the better choice.
Fallback Strategy
Discovery can return no suitable capability. The orchestrator should know how to fall back: use a simpler approved tool, ask the user for clarification or stop safely. It should not broaden permissions automatically just because the first search failed.
Tool Schema Loading
One efficient design uses a two-stage process. Search lightweight metadata first, then load full tool schemas only for the top candidates. This reduces context consumption and keeps the model focused on relevant options.
Security Against Malicious Metadata
Registry entries and tool descriptions are themselves untrusted input. Do not allow descriptive text to override system policy. Strip executable content, validate URLs and keep search results separate from privileged instructions.
Observability
Log the query, filters, candidates, selected capability and reason for selection. When an agent chooses the wrong tool, this trace helps determine whether the problem was bad metadata, poor semantic ranking, weak policy or model reasoning.
Measuring Discovery
Track precision: how often the chosen capability was actually useful. Track recall: how often the system failed to find a capability that existed. Track safety: how often prohibited candidates were correctly filtered. Discovery quality can be evaluated like a search system.
Enterprise Reference Flow
- User goal is converted into required capability types.
- Structured policy removes prohibited environments and owners.
- Keyword/semantic search produces candidates.
- Operational signals rank candidates.
- The chosen agent/tool is authenticated.
- Only necessary schemas and credentials are loaded.
- Execution is traced and validated.
- Outcome metrics feed future routing quality.
Discovery Is a Separate Infrastructure Layer
A small assistant can be initialized with five tools. An enterprise may have hundreds of agents, MCP servers, APIs and reusable skills. Loading every capability into every prompt wastes context and makes tool selection harder. Discovery narrows the candidate set before expensive agent reasoning begins.
Pattern 1: Static Configuration
Static configuration is underrated. An explicit list of approved capabilities is predictable, easy to audit and often the best solution for a small stable system. Dynamic discovery should solve a real scale problem, not simply make the architecture look more agentic.
Pattern 2: MCP Capability Discovery
An MCP client can learn what a known server exposes. Tool names, descriptions and schemas tell the agent how to use those capabilities. The 2026 MCP revision adds cache guidance for capability lists, which can reduce repeated metadata retrieval.
MCP does not automatically answer which servers exist across an organization. That belongs in configuration, a catalog or a registry layer.
Pattern 3: A2A Agent Cards
An Agent Card tells a caller how to reach an agent and what capabilities and skills it declares. Official A2A discovery guidance describes well-known Agent Card locations, curated registries and direct configuration as possible strategies.
Pattern 4: Registries
Registries aggregate capabilities across many providers. Google Cloud Agent Registry is a current example that indexes agents, MCP servers, endpoints and skills. A registry can provide both deterministic keyword discovery and more flexible semantic matching depending on resource type.
Keyword, Prefix and Semantic Search
Keyword search is transparent and precise when vocabulary is known. Prefix search is useful for interactive browsing. Semantic search is useful when the user describes an intention in different words from the capability metadata. Semantic similarity should never override hard constraints such as environment, region or authorization.
Two-Stage Schema Loading
A useful context-efficiency pattern is to search lightweight metadata first and load full tool schemas only for the top candidates. This keeps hundreds of irrelevant schemas out of the model context and can improve selection quality.
Freshness and Health
A perfect semantic match is useless if the endpoint is retired. Discovery systems should track lifecycle state, last update time, supported protocol versions and health. Orchestrators should avoid stale capabilities automatically.
Ranking with Operational Evidence
Declared skills can be combined with actual performance. Historical task success, latency, cost and escalation rates can help choose between several agents that claim similar abilities. This creates a feedback loop from execution back into routing.
Fallback Behavior
Sometimes discovery should return “nothing suitable.” The orchestrator can ask the user for clarification, use a simpler approved tool or stop. It should not broaden access automatically because the first search failed.
Measure Discovery Like Search
Track precision: how often the selected capability was actually useful. Track recall: how often the system failed to find a capability that existed. Track safety: whether prohibited candidates were filtered. Search-quality metrics turn discovery from an intuition into an optimizable system.
Enterprise Discovery Pipeline
- Interpret the user goal.
- Extract required capability classes.
- Apply hard policy filters.
- Search approved catalogs.
- Rank candidates using semantic and operational signals.
- Load only necessary schemas.
- Authenticate and authorize the selected endpoint.
- Execute in a bounded environment.
- Validate the result and record outcome metrics.
Cold Start and New Capabilities
Historical routing signals are weakest when a new agent or skill first appears. A registry may know what the provider claims, but it has no success-rate history. Treat new capabilities conservatively: route low-risk tasks first, collect evaluation evidence and increase traffic only after quality is demonstrated. This is similar to a cold-start problem in recommendation systems.
Human review can accelerate this process. Domain experts can validate whether a skill description matches the actual capability, whether examples are representative and whether the service belongs in production search results.
Schema Explosion and Capability Granularity
Discovery quality suffers when one server exposes hundreds of extremely granular tools or when one agent advertises vague mega-skills. Too much granularity creates schema overload; too little granularity makes routing ambiguous. Design capabilities around meaningful task boundaries and use hierarchical metadata where possible.
A useful pattern is coarse discovery followed by detailed negotiation. First select the relevant domain or specialist, then expose only the narrower tools needed for the current job. This reduces model context, improves security and makes tool choice more explainable.
Continuous Discovery Evaluation
Discovery should improve from outcomes. When users frequently override the selected agent, when a tool call fails because the wrong capability was chosen, or when no-result searches repeat, feed those signals back into metadata, ranking and taxonomy. A registry becomes more valuable when it learns from actual usage rather than remaining a static directory.
FAQ
Can an agent discover any tool on the internet?
Not safely. Discovery should normally be bounded to approved catalogs or domains.
Is an A2A skill executable?
It is primarily descriptive capability metadata.
Does semantic search replace keyword search?
No. They have different strengths and can be combined.
Why not load every tool into the prompt?
Large catalogs consume context and can reduce tool-selection quality.




