Getting Found by Agents: A Builder's Guide to Tool Discovery in 2026

Getting discovered used to be a human problem. You stuffed keywords into title tags, begged for backlinks, wrote blog posts nobody wanted to read, and prayed to the Google algorithm. The audience was a person with ten blue links and a short attention span. You were fighting for a click. That game is over.

The new audience doesn't click. It doesn't browse. It doesn't have a favorite blog. The new audience is an LLM picking tools at runtime, and it makes its choice in milliseconds. It reads a description, inspects a schema, queries a registry, and commits. Your human customer never sees the shortlist. Never knows you existed.

If your tool isn't discoverable by machines, your Google rank is a vanity metric. And the machine discovery game is nothing like the one you learned. MCP registries now list thousands of tools across hundreds of servers. When an agent needs a task management tool, it finds dozens of candidates with overlapping names and near-identical descriptions: create_issue, create_ticket, create_card, add_task.

Research shows agent accuracy collapses past 30 tools when descriptions overlap. Past 100, it's basically random. GitHub looked at the data and cut its GitHub looked at the data and cut its Copilot MCP server from 40 tools to 13. Benchmarks went up. Latency went down. Block rebuilt its Linear integration three times, from 30+ tools to 2. The tools that win are not the most feature-rich. They are the ones agents can find, understand, and trust. This is a guide for the people building those tools. The old SEO playbook is dead. Here is what replaced it.

Quick distinction that matters: in MCP, a server is the thing you build and deploy. A tool is a single function that server exposes. The Stripe MCP server exposes tools like create_payment_intent and list_customers. When GitHub cut from 40 to 13, they cut tools, not servers. When agents choose wrong, they are choosing the wrong tool from a crowded menu. The server is the restaurant. The tools are the dishes. As a builder you should make a brief, but very good menu.

Where to Post: An Agent Discovery Checklist

SEO had Google. Agents have registries, package managers, skill directories, and protocol-native discovery layers. There is no single front door. You need to be in every room where an agent might look for you. Here is what that looks like in practice, and why each one matters.

Smithery. This is the closest thing to a homepage for MCP servers. Agents using Smithery's Toolbox can search it by keyword or natural language at runtime. Frameworks like CAMEL query it natively. If you are not on Smithery, you are invisible to a large chunk of the agentic ecosystem. List your server, write your description for machines, and make sure your tool names are clear and unambiguous.

npm. This is where the install actually happens. When someone runs npx -y @your-org/your-mcp-server, they are pulling from npm. When your agent searches for tools, it checks npm alongside the registries. Your npm package description, README, and keywords are not just for human developers anymore. They are the text an agent reads when deciding whether to install you. Treat your package page like a tool description, not a marketing page.

Skill directories. Claude Code has Skills. OpenAI adopted Agent Skills. These are curated capability sets that agents load for specific workflows. Getting listed on directories like ClawHub means your tool can be discovered as a reusable skill, not just a server. Skills are a different discovery surface than registries. Registries say "this server exists." Skills say "this server is good at this job." Both matter.

x402 directories. If your tool supports pay-per-request via the x402 protocol, listing on x402scan puts you in front of agents that are actively looking to spend. The x402 Bazaar is a machine-readable directory where agents discover, compare, and pay for services without human sign-up. This is the commerce layer of agent discovery. If you have a monetized API, this is not optional.

Docs for bots. This one is easy to miss and hard to overstate. Stripe hosts an /llms.txt file that tells AI tools how to consume their documentation. All their docs are available as plain markdown by appending .md to any URL. This is not a nice-to-have. When an agent is evaluating your tool, it may try to read your documentation directly. If your docs are locked behind JavaScript rendering, auth walls, or complex navigation, the agent cannot read them. Publish an llms.txt. Make your docs available as plain text. Make your OpenAPI spec clean and complete. The agent's ability to understand your tool is gated by the format you publish it in.

The official MCP Registry. GitHub now hosts a Model Context Protocol registry where servers are discoverable through a standardized schema. This is where enterprise governance tools and IDE integrations look first. If you want Cursor, VS Code, or Claude Desktop to find you natively, register here.

The awesome-mcp-servers repo. Still one of the highest-traffic discovery surfaces in the ecosystem. A pull request to punkpeye/awesome-mcp-servers is the 2026 equivalent of submitting your site to DMOZ in 2003. It sounds quaint. It works.

None of these are optional. The compound effect of being listed everywhere is what separates 47 tool calls from 47,000. An agent can search the MCP Registry, Smithery, and npm in parallel. A buyer agent on x402 checks the Bazaar. A developer in Cursor sees what the GitHub registry surfaces. You do not know which path the agent will take to find you. Be on all of them. All roads should lead to your thing.

What Wins: Lessons From the Top 20

You can list your tool everywhere and still get ignored. The servers that actually get selected share patterns that have nothing to do with marketing and everything to do with how agents think.

We looked at the real usage data. FastMCP tracks views and installs across 1,864 servers. The results are not what most builders expect.

Context7 sits at number one. 11,000 views. 690 installs. Nearly double the traffic of the second place server. It does one thing. It fetches up-to-date library documentation and injects it into the LLM's context. That is the entire product. No dashboard. No multi-feature platform. One problem, solved cleanly. It was built by a small team at Upstash and it now outranks servers from Microsoft and Anthropic.

Playwright Browser Automation is number two. DuckDuckGo Search has the highest install-to-view ratio in its category, partly because it requires zero API keys. Sequential Thinking, built by Anthropic, converts views to installs at a higher rate than almost anything else on the platform. Seven of the top ten are official implementations maintained by the creators or core MCP community.

Three of the top ten are browser automation. Three more are documentation servers. The pattern is loud. Agents reach for tools that solve frequent, universal problems with minimal setup friction.

Here is what the top servers have in common and what you should steal.

Fewer tools, not more. This is the single most counterintuitive lesson in the data. At 107 tools, both large and small models fail completely in the Speakeasy experiments. At 20, large models score 19 out of 20. At 10, performance is perfect. The failure is not gradual. It is a cliff. GitHub saw the same thing. They cut tools and benchmarks went up. Vercel's engineering team put it simply: think of MCP tools as tailored toolkits that help an AI achieve a particular task, not as API mirrors. If you are exposing your entire REST API as individual tools, you are making your server harder to use, not easier. Pick the five to fifteen tools that represent complete workflows. Cut the rest.

Descriptions are the interface. A human developer reads your docs and figures out what your API does. An agent reads your tool description and decides in one pass whether to use it or skip it. Research shows 97% of tool descriptions have quality issues. A tool described as "code quality" will not get selected for security reviews even if it is perfect for that job. Write descriptions that state the purpose, the limitations, the expected input, and what comes back. Be specific. "Create a new issue in Linear with title, assignee, labels, and project scope via OAuth 2.0" beats "Issue management tool" every time. The agent is not browsing. It is pattern matching.

Name tools for the task, not the resource. API convention says POST /issues. Agent convention says create_issue_with_labels. The agent does not know your data model. It knows what the user asked for. Name your tools after the job the user is trying to do, not the endpoint you built. Block went through three rebuilds of their Linear server before landing on two tools named for outcomes, not resources.

Zero friction installs. DuckDuckGo Search requires no API key. Context7 works with a single npx command. The servers with the highest install-to-view ratios all share this trait. Every key, every environment variable, every OAuth dance is a point where an agent or a developer drops off. If you can make your server work with one line in an mcp.json file and nothing else, do it. If you need auth, support OAuth 2.0 with PKCE so the flow can be automated. API keys that require a dashboard login and manual copy-paste are the new "registration wall" that killed conversion in the SaaS era.

Structured output, not prose. When your tool returns results, return them as structured data the agent can reason over. JSON with consistent shape and clear field names. Not paragraphs of text. Not HTML. Not raw error dumps. The agent is going to take your output and make a decision with it. Make that decision easy. Return structured results with consistent semantics, and handle errors gracefully with messages that tell the agent what went wrong, what was expected, and how to fix it. Your API should have responses tailored for agents.

Be the only thing in your lane. Context7 does not try to also do browser automation. Playwright does not try to also serve documentation. The top servers own a single category and do it better than anything else. When an agent searches "up to date library docs," Context7 is the obvious match. There is no ambiguity. If your server does six different things, you are competing with specialists in all six categories and winning in none. Pick one lane. Own it.

You Built the Right Tool. The Agent Picked the Wrong One.

Everything above helps you get found. But being found is not the same as being correctly matched.

MCP tool discovery is fundamentally broken. Semantic search can't tell a good tool from a good description. Similarity is not satisfiability. Tool descriptions are ads, not specs.

When an agent faces fifty tools with overlapping descriptions, semantic matching ranks them by how similar the description sounds to the query. Not by whether the tool actually has the capabilities the agent needs. A tool that says "create and manage engineering tasks with full project support" scores higher than one that says "create issues in Linear with label and assignee support via OAuth 2.0." But the second one is the actual match. The first one just has better copy. You lose the selection not because your tool is worse, but because the ranking is a vibes check.

This gets worse when incentives enter the picture. In an agent marketplace, sellers are optimizing descriptions for selection, not accuracy. A competitor emphasizes "project management" when the buyer needs "engineering task tracking." Another buries the fact that it uses API keys instead of OAuth. The descriptions are not wrong. They are just optimized. And semantic search rewards the optimization, not the truth.

We built PreFlight to replace vibes with verification.

Here is how it works. A buyer agent uses natural language to define what its looking for. Preflight compiles those requirements into a formal policy using Automated Reasoning checks. No product names. No brand preferences. Just constraints: must support OAuth 2.0, must support labels, must support write operations, must have a verified identity. The policy gets compiled once, battle tested against generated scenarios, and refined until every variable is unambiguous. Then when the agent searches.. every seller's advertised capabilities get checked against constraints by a formal logic solver.

VALID means the seller has everything the buyer needs. INVALID means they don't. The seller never sees the buyer's policy. They never know which rules exist or which one they failed. They cannot game a system they cannot see. The result is a cryptographic receipt recording exactly what the seller claimed. If the tool does not deliver what was advertised, the receipt is proof of what was promised. Honesty becomes the dominant strategy because lying creates provable liability with no information advantage.

This privacy guarantee is not a promise. It is cryptography. When the buyer's policy is compiled into formal logic, it stays on the buyer's side. The seller never sees it. But how does the seller trust the result? How do they know the solver actually ran their capabilities against a real policy and did not just return a fabricated VALID or INVALID? This is where zero-knowledge proofs come in.

PreFlight uses JOLT and JOLT Atlas, high-performance ZK frameworks that generates a cryptographic proof of every verification decision. The proof confirms that a specific policy was evaluated against a specific set of seller capabilities by the actual solver, and it produced the result it claims. The seller can verify this proof without ever seeing the buyer's policy. The buyer can prove the decision was legitimate to their human auditor later.

No trust required in either direction. The proof is the trust. Every decision produces a receipt that is permanent, verifiable by anyone, and impossible to forge or retroactively alter. For the seller, this means a VALID result is not just a claim from some API. It is a mathematical proof that your tool was checked against real buyer requirements and passed.

That is the buyer's side. But if you are reading this guide, you are a builder. Here is why this matters for you.

With agentic software you should compete on capabilities, not copywriting. When a buyer's policy says "must support OAuth 2.0" and your tool supports OAuth 2.0, you match. A competitor with a better marketing team and a vaguer description cannot leapfrog you. The solver does not read your Smithery listing. It checks whether your advertised capabilities satisfy the constraints. The best tool wins, not the best copy.

You stop guessing what buyers want. In the SEO world you had to reverse-engineer the algorithm. In semantic search you have to guess which keywords agents look for. With PreFlight, buyers define what they need. You define what you have. Formal logic with a touch of cryptography: finds the match! You might get selected for use cases you never marketed for, because a buyer's policy said "must support assigning tasks to team members" and your tool does that, even though you call yourself a bug tracker.

VALID receipts become your track record. Every confirmed match is a cryptographic proof that your tool met real demand. Over time that is a portfolio. Stars can be gamed. Reviews can be written by friends. A VALID receipt is proof.

INVALID results with public buyer policies can also tell you what to build next. If buyer after buyer requires OAuth and you only support API keys, you do not have to guess why you are not getting selected. The gap is explicit. It is product feedback from the demand side. No surveys. No guessing. Just the constraint your tool did not meet.

The most important thing you can do as a seller is describe your capabilities accurately and completely. Not in marketing language. In structured, specific terms that a solver can check. What authentication methods you support. What operations you support. What scoping you offer. What identity verification you have. The more precise your capability advertisement, the more buyers you match cleanly and the fewer you lose to a competitor who just sounds better.

Agentic search is a ruthless quality matching machine.

Discovery gets your tool on the candidate shortlist. Verification gets your tool used.

This article will be added to as new services and processes for agentic discovery come out. Follow my Twitter to keep up-to-speed.