How AI agents discover and pay for tools
An agent's toolset is fixed when you configure it. Real tasks aren't. Here's how agents find the tools they're missing at runtime — and how they pay for them.
An AI agent is only as capable as the tools wired into it. But you can't wire in everything: there are already 10,000+ MCP servers — for databases, search, Slack, scraping, payments, maps, and more — and the right one for a given task usually isn't the one you pre-loaded. The interesting question in 2026 isn't "which tools should I install," it's "how does an agent get a tool it doesn't already have, mid-task, and pay only for what it uses?"
This guide covers the three discovery models, the registries that matter, and the payment layer that most write-ups skip.
The three ways an agent discovers tools
1. Manual configuration
The baseline: a developer lists the servers and their tool schemas in the agent's config (a config.json, a system prompt, or hard-coded). Reliable, but static — the agent can only ever use what you predicted it would need.
2. Direct server connection
The agent connects to a known MCP server over stdio (local) or Streamable HTTP (remote). On connect, the server answers a list tools request and tells the agent what it can do. Still requires knowing the server up front.
3. Registry-based discovery
This is the one that unlocks runtime capability. The agent queries an MCP registry in natural language — "find something that can convert currencies," "what can query Postgres?" — and gets back ranked, relevant servers it can wire up on the spot. This is how an agent handles a task it was never pre-configured for.
No single registry has everything, and each phrases and ranks results differently. Searching one registry means missing servers listed only in another. A discovery layer that fans out across all of them and deduplicates gives the agent the widest, cleanest view.
The registries that matter in 2026
- mcp.so — the largest directory, tens of thousands of servers.
- Smithery — strong discovery UX and one-click setup.
- Glama — indexed catalog with quality signals.
- awesome-mcp-servers — the community-curated GitHub list.
- The official MCP registry — authoritative, verified metadata (
server.json).
If you publish an MCP server, list it in all of them — that's where agents (and the discovery layers agents rely on) look.
The missing half: paying for tools
Discovery gets an agent to the right tool. It still has to run the tool and settle the cost — and most remote tools aren't free. Installing and managing credentials for every server an agent might touch defeats the point of runtime discovery.
The cleaner model is a metered gateway: the agent calls the discovered server through one endpoint, the gateway proxies the call and meters it, and each successful call is billed per use (e.g. via Stripe usage-based billing). Tools become a pay-as-you-go runtime resource — no install, no standing credentials, no commitment for a tool used once.
find_mcp_server (free) searches every major registry and returns ranked, ready-to-use servers for a plain-language task. call_tool (paid) proxies the call to any remote MCP server, guards it, and meters it. Both live at one hosted MCP endpoint:
claude mcp add --transport http toolhail https://mcp.toolhail.com/mcpAny MCP client works the same way. Once it's connected, an agent can go from "I need X" to a running, billed tool call without a human wiring anything up.
Takeaways
- Treat tools as a runtime resource, not a fixed install list.
- For discovery, search across registries — no one directory is complete.
- For execution, a metered proxy turns "found a tool" into "used and paid for a tool" with no setup.
FAQ
How do AI agents discover MCP servers?
Three ways: manual configuration (hard-coded), direct connection (connect to a known server and read its tool list), and registry-based discovery (query a registry in natural language at runtime). The third is what lets an agent find a tool it wasn't pre-configured with.
Which MCP registry should I list my server in?
All the major ones — mcp.so, Smithery, Glama, awesome-mcp-servers, and the official MCP registry. Agents and discovery layers query different registries, so a listing in only one leaves you invisible to the rest.
How does an agent pay for a tool it just discovered?
Through a metered gateway that proxies the call and bills per successful use — for example ToolHail's call_tool, which settles each call via Stripe usage-based billing. No install or standing subscription required.