How Does Claude Choose Which MCP Server to Use?

The Invisible Decision

Picture this. A developer using Claude Code types: "Check if there are any outstanding invoices in freee and send reminders for the overdue ones."

Claude doesn't ask which MCP server to use. It doesn't show a dropdown menu. It searches, evaluates, selects, and calls — all within a few seconds. The developer sees the result. The decision process is invisible.

For one-off personal use, this is fine. But for SaaS companies whose products are the ones being selected (or not), this invisible decision is the most consequential thing happening in their product's distribution. If Claude picks a competitor's MCP server — or fails to find yours entirely — you'll never know. No log, no alert, no analytics event. The developer simply moves on.

This article breaks down what we know about that decision process. Some of this comes from Anthropic's public documentation. Some comes from KanseiLink's analysis of 11,000+ services and their MCP discoverability patterns. None of it comes from speculation — we'll be explicit about what's verified and what's inferred.

What Is Tool Search?

Tool Search is Anthropic's system for matching a user's task intent to available MCP servers. Think of it as Google for AI agents — but instead of ranking web pages by links and content quality, it ranks MCP servers by how well their descriptions match what the agent is trying to do.

The key word is semantic. Tool Search doesn't do keyword matching. It does meaning matching. A server described as "manage billing documents and payment records" can match the query "send an invoice" even though the word "invoice" never appears in the description. Conversely, a server named "InvoiceMaster Pro MCP" might not match "track my expenses" even though invoices and expenses are related — because the description doesn't signal expense-tracking capability.

This is fundamentally different from how Google works. Google ranks pages partly by links pointing to them, domain authority, content freshness, and hundreds of other signals. Tool Search has a narrower signal set: it primarily works with what the MCP server says about itself.

Anatomy of a Selection: Step by Step

When Claude receives a task that requires an external service, the selection process follows a rough sequence. We say "rough" because Anthropic hasn't published a detailed algorithm spec, and the internals likely evolve. But the observable behavior is consistent enough to describe:

Step 1: Intent Extraction

Claude parses what the user wants to accomplish. "Check outstanding invoices in freee" becomes something like: target service = freee, action = retrieve invoices, filter = outstanding/unpaid. If the user doesn't name a specific service ("send an invoice to my client"), Claude needs to find one that can do it.

Step 2: Server Search

Claude searches the available MCP servers. In Claude Desktop or Claude Code, the "available" pool includes locally configured servers plus any servers accessible via remote MCP. In environments with the MCP Registry, the pool is much larger. The search matches the extracted intent against server names and descriptions.

Step 3: Tool Matching

Once candidate servers are identified, Claude looks at their individual tools. Each MCP server exposes a set of tools (functions), each with a name, description, and parameter schema. Claude evaluates which specific tool within which server best matches the task. A server might have 15 tools — Claude needs the right one.

Step 4: Selection and Execution

Claude picks the best-matching server and tool, constructs the appropriate parameters, and makes the call. If the call fails (auth error, rate limit, wrong parameters), Claude may retry with a different server or ask the user for help.

What Actually Matters for Selection

Based on KanseiLink's analysis across 11,000+ services, the signals that influence selection fall into a clear hierarchy:

Server Naming: The First Filter

The name of your MCP server is the first signal an agent sees. It works like a storefront sign — if it tells passersby what's inside, they walk in. If it just says "Acme Corp," most people keep walking.

Here's the pattern we see across KanseiLink's data:

The best pattern combines both: brand + function. Names like freee-accounting, slack-messaging, or github-repository-management serve both human users (who search by brand) and agents (who search by task).

Tool Descriptions: Where Most Servers Fail

Every MCP tool has a description field. This is the single most important piece of text for agent selection — and it's where the majority of servers underperform.

The problem is that most developers write descriptions for other developers. They use internal terminology, API-specific jargon, or minimal placeholder text. But the reader of this description isn't a developer browsing documentation — it's an LLM trying to match a natural language task to a function.

{
  "name": "create_doc",
  "description": "Creates a new document entity in the system."
}

{
  "name": "create_invoice",
  "description": "Create and send a PDF invoice to a client. Supports line items, tax calculation, payment terms, and due dates. Returns the invoice URL and tracking status."
}

The difference is specificity. The first description could be anything — a wiki page, a contract, a spreadsheet. An agent looking for "create an invoice" has no reason to pick it. The second description matches on multiple intent patterns: "send invoice," "bill a client," "create a PDF invoice," "add payment terms."

The Description Formula

Good tool descriptions follow a consistent structure:

1. Start with a verb phrase — what the tool does ("Create and send," "Retrieve all," "Update the status of")
2. Name the object — what it operates on ("PDF invoices," "calendar events," "employee records")
3. List capabilities — what options it supports ("Supports line items, tax, and payment terms")
4. State the output — what gets returned ("Returns the invoice URL and tracking status")

The Four Failure Patterns

KanseiLink classifies tool selection failures into four categories. Understanding these helps you diagnose why agents might be skipping your server.

1. search_miss — The Silent Killer

The agent searches for a capability, and your server doesn't appear in the results. This is the most common failure and the hardest to detect because it generates no error, no log, no signal on your end. Your server just isn't there.

Cause: Server name and description don't match the agent's search intent. Often happens with brand-only names or generic descriptions.

2. Description Overlap — The Coin Flip

Multiple servers describe themselves identically, so the agent can't meaningfully distinguish between them. Selection becomes arbitrary. You might win sometimes and lose sometimes, with no clear reason.

Cause: Copy-paste descriptions, overly generic capability claims ("manage your business data"), or lack of differentiating details.

3. Tool Confusion — The Wrong Tool Problem

The agent finds your server but picks the wrong tool within it. It calls list_contacts when it should have called search_contacts, or create_draft instead of send_email.

Cause: Tool descriptions within the same server overlap, or tool names are ambiguous. If list_contacts and search_contacts have nearly identical descriptions, the agent guesses.

4. Parameter Mismatch — The Last Mile Failure

The agent finds the right server and the right tool but constructs the wrong parameters. The call fails or returns unexpected results.

Cause: Parameter descriptions are missing, unclear, or use internal ID formats without examples. If a parameter requires a specific format like "YYYY-MM-DD" and the description doesn't say so, the agent will guess.

A Practical Optimization Checklist

If you operate an MCP server and want to improve your selection rate, here are concrete steps ranked by impact:

High Impact (Do First)

• Rewrite your server description to lead with what it does, not who you are. "Create, send, and manage invoices with automatic tax calculation" beats "Acme Corp's official MCP integration."
• Audit every tool description against real user queries. Read 10 support tickets or feature requests. Those are the phrases agents will search for. Does your tool description match?
• Use function-descriptive server names. brand-function pattern. If you're an accounting tool, yourname-accounting beats yourname-mcp.

Medium Impact

• Add parameter descriptions for every parameter. Include the expected format, valid values, and a one-sentence explanation of what it controls.
• Differentiate overlapping tools. If you have list_items and search_items, make sure their descriptions clearly explain when to use which.
• Provide concrete examples in tool descriptions. "Search for contacts by name, email, or company — e.g., search_contacts({query: 'Tanaka'})" gives the agent a clear mental model.

Lower Impact (But Still Worthwhile)

• Keep tool count reasonable. A server with 50 tools creates cognitive load for the agent. Group related tools logically or split into multiple focused servers.
• Use consistent naming conventions across tools. If one tool uses create_, don't switch to new_ or add_ for similar operations.
• Document error responses. When the agent knows what errors look like, it can retry more intelligently or give better feedback to the user.

FAQ

Does Claude prefer official MCP servers over community-built ones?

Not based on observable behavior. Tool Search matches on descriptions and capabilities, not on whether the server is "official." A well-described community server can outrank a poorly-described official one. That said, if a user asks for a service by name ("use Slack"), Claude will prioritize servers that include that name.

Can I pay to rank higher in Tool Search?

No. As of mid-2026, there is no paid placement in Tool Search. Rankings are determined by semantic matching. This is analogous to early Google — organic relevance is the only signal.

Does this apply to agents other than Claude?

The specific mechanics of Tool Search are Anthropic's implementation. But the MCP protocol is open (now under the Linux Foundation's Agentic AI Foundation), and other platforms — OpenAI's Agents SDK, Google's ARD, IDE integrations like Cursor — have their own discovery mechanisms. The principle is the same everywhere: clear, task-aligned descriptions win. The Agent AEO approach covers all these surfaces.

How often should I update my server's descriptions?

Whenever you add features. Think of your tool descriptions the way you think about your product's landing page copy — if the feature exists but isn't described, it's invisible. Check your AEO grade on KanseiLink quarterly at minimum.

What about llms.txt and mcp.json — do those affect Tool Search?

These emerging standards (llms.txt, MCP Server Card, Google ARD) complement MCP tool descriptions. They provide additional signals for discovery across different AI platforms. Tool Search primarily uses what's in your MCP server's manifest, but as the ecosystem matures, these files are likely to become additional input signals. See our complete discoverability guide for implementation details.