## TL;DR

Agents find MCP tools through a patchwork: preconfigured servers from their host, registry browsing by their operator, and tool descriptions matched against the task at hand. There is no Google for MCP tools yet, which means being preinstalled or well-described beats being merely listed. Tool builders should optimize for all three paths: make hosts want to bundle you, make registries list you well, and make your tool descriptions match how agents phrase tasks.

```text
how agents find MCP tools: the discovery problem
```

## Use this when

- You want to understand how agents discover tools in practice
- You are designing a tool for agent discoverability
- You need to explain the MCP ecosystem gaps to a team
- You are deciding where to invest: registries, host partnerships, or descriptions

## Not for this skill when

- You need human user acquisition (different playbook)
- You are building the discovery infrastructure itself (different project)
- You want a list of current registries (that changes too fast; check live sources)

## Steps

1. Map the three discovery paths. Host-bundled (the agent's platform ships your server), operator-browsed (a human picks servers from a registry), and task-matched (the agent picks tools from descriptions at runtime). Expected: you know which paths you currently serve.

```
Paths: bundled by host, chosen by operator, matched by agent.
Most tools only serve one; winners serve all three.
```

2. Win the bundled path with host partnerships. Talk to host and harness developers; make integration trivial with great docs and stable transports. Expected: your server ships by default somewhere.

```
Moves: docs a host dev can follow in an hour,
stable releases, responsive maintainer.
```

3. Win the operator path with registry presence. Complete listings, clear descriptions, evidence it works (docs, demos, usage). Expected: operators pick you when browsing.

```
Registry listing as a pitch: what it does, proof it works,
how to try it in five minutes.
```

4. Win the task-matched path with descriptions. Tool names and descriptions should mirror the words agents use for the task. Expected: agents select your tool at runtime over vague alternatives.

```
Description rule: name the task in the agent's words,
state the inputs and the output shape.
```

5. Instrument which path works. Ask new users how they found you, or tag installs by source where possible. Expected: data on where to double down.

```
Track: install source, first-use survey, registry click-throughs.
Reinvest in the winning path.
```

## Variant phrasings

### MCP tool discovery explained

Three paths: host-bundled, operator-browsed, task-matched; no central search yet.

### How do AI agents find tools

Mostly through what their host ships and what their operator installs; runtime matching is the third path.

### Getting your MCP server adopted

Serve all three discovery paths; descriptions are the highest-leverage investment.

## Why it happens

MCP standardized the connection but not the discovery: there is no PageRank for tools, no universal registry every host queries, and agent runtimes pick from whatever tools are already configured. Discovery therefore fragments across human curation (operators, hosts) and runtime matching (descriptions). Tool builders who assume "list it and they will come" learn that listing is necessary but far from sufficient; the ecosystem rewards the builders who work all three paths.

## Edge cases / pitfalls

- Runtime matching depends on the agent's model and prompt; test your descriptions against real agents, not just your intuition.
- Host bundling is a partnership, not a submission; it needs relationships and reliability.
- A new "universal MCP directory" appears every quarter; evaluate before investing listing effort.
- Descriptions written for humans often miss; agents match on task verbs, so lead with the verb.
- Discovery without reliability is churn: a found-but-broken tool gets removed everywhere.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SdJeDAX2wyXHj8YjCUSJNQ