claude-connector-routing

Claude connector routing (measured)

The measured mechanism behind signal-set-and-weights. That page is the inventory of candidate signals; this page is the evidence for the two levers Claude actually controls — how it builds the search keywords and how it re-ranks the registry’s results. Method that produced it: discovery-analysis-method (run-artifact mining at corpus scale). Grades the levers map to: the four R’s in discoverability-framework.

Corpus

• ~4,358 Claude runs with evidence payload; 4,290 ended in the connection picker; 4,397 registry searches carrying 16,370 keywords; 42,335 backend candidates scored against a registry of 542 connectors / 7,664 tools. This is our own benchmark/run data, not a host export — the kind of pre-connection visibility rivals working off server logs cannot see (agent-discovery-market).
• Raw report: raw/research/2026-06-24-claude-connector-routing-report.md.

Current truth

Claude controls exactly two things in the routing path; everything else is the opaque backend match. Both are now measured.

Key insight — backend rank strongly predicts picker survival

Connectors ranked higher in Claude’s backend search_mcp_registry results are much more likely to survive into the visible connector picker, and much more likely to be picker #1. This is the strongest measured evidence that Retrievability rank feeds Rank, even though it is not the final decision: Claude still re-judges the retrieved candidates from their tool/name/description content before presenting the picker.

Backend rank	Shown in picker	Picker #1
1	74.3%	44.0%
2	45.9%	15.2%
3	39.5%	10.6%
4	37.3%	7.3%
5	37.4%	8.4%
6	35.3%	5.3%
7	25.2%	3.5%
8	18.6%	2.1%
9	17.3%	0.8%
10	15.7%	0.8%

Interpretation: backend rank is a strong first-stage prior, not a deterministic picker order. About a quarter of backend #1 candidates are still dropped, and some lower-ranked candidates get promoted when the model judges their tool content, brand fit, or task directness to be stronger.

Lever 1 — prompt → keyword compression (drives Retrievability + Relevance)

• Claude compresses a full prompt into ~3–4 short capability keywords. Modal counts: 3 (1,875 actions) and 4 (1,634); 2–5 covers the vast majority. It searches on capability nouns, not sentences.
• Only ~half the keywords are the user’s words. 38% are exact phrases from the prompt, 8% same-token, 4% partial overlap — but 18% are synonyms/generalizations and 31% are added/inferred terms the user never typed. Claude routinely infers the capability.
• Constraints are stripped before search. Dates/times appear in 45% of prompts but 0% of keywords; numbers/money 19% → 0.3%; action verbs 69% → 8%. The when / how-much / what-action is discarded; only the capability survives.
• Brand terms are amplified, not just preserved. Brand-like terms appear in 19% of prompts but 39% of keywords — Claude adds brand/category names beyond what the user named. (Consistent with the brand-recall “boost” — see Lever 2.)
• Compression is category-dependent. recruitment-hiring is 61% inferred / only 22% exact (users never say “recruitment”); ecommerce (64%) and content-seo (63%) are mostly literal. So how literally a category’s intent is phrased varies — the keyword you must own to be retrievable is the inferred capability noun, which differs by category.
• Implication for clients: optimize the name + description to carry the inferred capability noun and the brand term for the category, not the user’s verbatim phrasing or any date/price/quantity language. Matching the literal prompt is the wrong target; matching what Claude compresses it to is the right one.

Lever 2 — backend rank is a strong prior the model then overrides (drives Rank)

• Backend rank predicts survival but is not final order. Backend #1 is shown in the picker 74% of the time and is picker-#1 44%; survival decays monotonically to backend #10 (shown 16%, picker-#1 0.8%). Being retrieved high matters a lot — but ~26% of even the top hit gets dropped.
• The model re-judges from tool content and overrides rank. Strong brands are systematically promoted above their retrieval rank: HubSpot #3→picker-#1 ×90, Asana #3→#1 ×89, Expedia #5→#1 ×77, Semrush #2→#1 ×53, Shopify 4→#1. Brand recall acts as a re-ranking boost on top of retrieval.
• And it discards top hits that don’t fit. Backend-#1 candidates dropped most often: Synapse.org ×181, Booking.com ×172, Goodnotes ×114, Uber Eats ×55. A high retrieval score does not buy a picker slot if the tools don’t match the task.
• Lower auth friction improves survival. Authless connectors are shown 43% vs 33% for auth-required — reachability/auth friction is a selection signal, not just an operational gate.
• Mechanism (qualitative, cross-validated swimlane): triage (is this an app task? is a tool already in hand? is a connector named + connected?) → build the 2–4-term keyword array (brand+function if named, else category) → search_mcp_registry → opaque backend match/score/rank → model inspects each candidate’s tools first, requires a domain match, discards the backend rank order, re-orders by directness → presents the picker → user picks. The two model-controlled steps are keyword construction and the post-retrieval re-judge; the backend score is not observable to the model.

So what (for the score / product)

• Confirms the score’s two halves are causally real: Retrievability = “does the keyword array Claude builds return you” (Lever 1), Rank = “does Claude keep and promote you after reading your tools” (Lever 2). See ado-score-model.
• The Fixes engine (discoverability-framework) should target: capability-noun + brand coverage in name/description; specific, task-matched tool names (generic “search” tools fall back to the description and lose the re-rank); and authless access where viable.
• Brand recall is measurable as a promotion delta (rank-in → picker-rank-out) — a concrete way to quantify the “boost” signal the thesis flags.

Open questions

• Is the promotion of strong brands training-data recall, or just better tool/description content on well-resourced connectors? (Confounded here — needs the held-one-signal experiment from signal-set-and-weights.)
• The backend match/score/rank is opaque RESOLVED (2026-07-04): the backend is decoded — indexed fields, matching rules, ranking shape, and causal edit effects, live-validated → claude-registry-search-decoded. Residual: it drifts as Anthropic updates it; that page owns re-verification.
• Does the same compression shape hold on ChatGPT / other hosts, or is 3–4-keyword stripping Claude-specific?
• Faithfulness caveat (discovery-analysis-method): this is observational correlation at scale, strong but not a controlled cause.

Timeline

• [2026-07-04] (research) The opaque middle stage is decoded: claude-registry-search-decoded completes the pipeline (compression → registry search → re-judge).
• [2026-06-24] (research) Synthesized from the Claude connector-routing report (~4.3k runs). Established the two-lever model (keyword compression + rank override) with corpus-level numbers; upgraded several signal-set-and-weights candidates to evidenced.