Tools MCP and External Integration
Tool Discovery — Stack
Tool discovery › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
Two different mechanisms are being chosen: how a surface is enumerated from its sources, and how that surface is narrowed to a candidate set.
- Recall at the candidate-set size you can afford. How often the correct entry appears in the top handful, measured on real requests rather than on paraphrased descriptions.
- Cold-start behaviour. Whether narrowing works for a newly added entry with no usage history, since the entries most at risk of being missed are always the newest.
- Vocabulary gap handling. Whether the mechanism bridges the difference between how users phrase a need and how tool authors phrase a description — through synonyms, hybrid lexical and semantic matching, or generated paraphrases.
- Enumeration cost and freshness. How expensive a full enumeration is, whether sources support incremental change notification, and how stale a cached surface may be.
- Source trust. Whether admissibility can be expressed per origin and enforced before any advertised text reaches an index.
- Index maintenance. What has to happen when an upstream adds or renames an entry, and whether that is automatic or a scheduled job somebody owns.
- Explainability. Whether you can reconstruct, for a past request, which candidates were offered and why — without this, a wrong-tool incident cannot be diagnosed.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Static configured list, fully enumerated per session | Fewer than roughly fifty entries with a stable set | Stops working abruptly rather than gradually; the failure looks like declining model quality |
| Protocol-native enumeration across connected servers with change notifications | Deployments where sources speak a protocol that advertises its own offerings | The combined surface is whatever happens to be connected; size is not controlled by anyone |
| Lexical search over names and descriptions (BM25-style) | Entries with distinctive names and jargon that users actually type | Fails on paraphrase; a user asking for "time off" misses a tool named for the leave system |
| Dense retrieval over embedded descriptions | Bridging phrasing differences between requests and descriptions | Near-duplicate entries become near-identical vectors; thresholds need recalibration as the surface grows |
| Hybrid lexical and dense retrieval with reranking | Large surfaces where both exact names and paraphrases occur | Three components to tune and monitor; reranking adds latency inside the turn |
| Hierarchical grouping: choose a source or domain first, then its entries | Surfaces that partition naturally by backing system | A wrong first-level choice is unrecoverable and the model rarely backtracks |
| Usage-weighted retrieval from logged successful invocations | Mature deployments with enough traffic to learn from | Entrenches current behaviour; a correct but unused tool stays unused |
Models
Where retrieval is used to narrow the surface, the embedding model is a real choice with measurable consequences.
- Tool descriptions are short, dense, and jargon-heavy, which is unlike the paragraph-length passages most general-purpose embedding models were tuned on. Retrieval quality on them tracks published passage-retrieval benchmarks poorly.
- Asymmetric models, trained to match short queries against short items, usually outperform symmetric ones here, as do instruction-conditioned embeddings where the retrieval intent can be stated.
- A small cross-encoder reranker over a generous first-stage candidate list is frequently the cheapest large gain, because it can read the whole description rather than a compressed vector of it.
- Any model change silently reindexes the entire surface and shifts every threshold. Treat it as a migration with a recall measurement on both sides, not as a configuration update.