Skip to main content
Explainer3 min read

MCP server discovery protocol: how agents will find tools without static configs

Static MCP configs do not scale. The discovery protocols emerging in 2026 — DNS-SD, well-known endpoints, and the proposed mcp-discover spec — let agents find servers dynamically. Here is how each works and which to bet on.

In 2026 every agent host loads its tools from a static config file. By 2027 the same hosts will discover tools the way browsers discover printers — dynamically, with capability negotiation and signed advertisements. Here are the three discovery approaches in flight, and which one to build against today.

Why static configs hit a wall

A team with 50 MCP servers across 200 developers needs every laptop's config kept in sync. The current solutions — ChatOps copy-paste, version-controlled configs, team config tooling — all paper over the underlying problem: configs are static and tools are dynamic.

Discovery solves the underlying problem. The host asks "what tools are available here?" instead of being told.

The three approaches

DNS-SD (RFC 6763)

Reuse mDNS / DNS-SD: tools advertise themselves on the network as _mcp._tcp services with TXT records describing capabilities. Hosts subscribe and discover everything visible on the network.

  • Strengths: existing infra, zero new protocols, multicast on LAN works out of the box.
  • Weaknesses: does not cross network boundaries; sparse capability metadata.
  • Best for: corporate LANs, dev environments.

Well-known endpoints

A host fetches https://example.com/.well-known/mcp and gets back a JSON list of available servers with auth requirements and capability summaries.

  • Strengths: works across the public internet; easy to secure (TLS + signed).
  • Weaknesses: push model — hosts have to know to ask.
  • Best for: SaaS providers exposing their own MCP servers; per-domain discovery.

mcp-discover (proposed)

A protocol-level extension to MCP itself: a discovery endpoint returns server descriptors, capabilities, signing fingerprints, and renewal hints. Standardisation in flight at the time of writing.

  • Strengths: native to MCP; signed; fine-grained capability metadata.
  • Weaknesses: not yet standardised; client support patchy.
  • Best for: future-proof setups; bet on the standard once it lands.

Capability negotiation

Discovery alone is not enough. The host needs to know:

  • Which tools the server exposes.
  • Required permissions / scopes.
  • Compatibility (MCP protocol version, transport).
  • Signing fingerprint for verification.

A discovery descriptor:

{
  "name": "internal-postgres",
  "version": "1.4.0",
  "protocol": "mcp/1.0",
  "transport": "stdio",
  "tools": ["query", "schema"],
  "scopes_required": ["postgres:read"],
  "signature": "ed25519:a8f3...",
  "ttl_seconds": 3600
}

The host subscribes, validates the signature, checks compatibility, and only then offers the server to the agent.

Trust on top of discovery

Discovery without verification is worse than static configs — it surfaces every server an attacker can advertise. Three layers of trust:

  1. Signed descriptors — refuse unsigned advertisements.
  2. Anchored to a registry — only trust servers whose signing key is in your self-hosted registry.
  3. Scope enforcement at the gateway — even discovered servers must request scopes the user has.

Discovery surfaces options; trust layers decide what is allowed.

Migration path

Don't replace static configs overnight. Layer:

  1. Keep static configs for production-critical tools.
  2. Add discovery for dev-environment tools.
  3. As discovery proves out, move tools one at a time.
  4. Eventually static configs hold only the bootstrap (where to discover).

Most teams will live in a hybrid state for years.

What to build today

Bet on mcp-discover with a well-known endpoint fallback. DNS-SD is useful for LAN scenarios but not where most production agents live. Implementing the well-known endpoint today is a one-day job; the descriptor format is forward-compatible with the standard.

Failure modes

  • Stale advertisements — TTL too long, server gone but still advertised.
  • Capability misadvertising — server claims tools it does not implement.
  • Discovery floods — too many servers; UI noise. Filter at the host.
  • Spoofing — unsigned discovery is a phishing vector.

Where this is heading

Two shifts to expect by mid-2027: a finalised discovery protocol in MCP spec, and MCP-aware DNS extensions for cross-network discovery. Whoever builds the descriptor schema today will shape the standard.

Loadout

Build your AI agent loadout

The directory of MCP servers and AI agents that actually work. Pick the right loadout for Slack, Postgres, GitHub, Figma and 20+ integrations — with install commands ready to paste into Claude Desktop, Cursor or your own stack.

© 2026 Loadout. Built on Angular 21 SSR.