MCP
Discovery
MCPmcp / discovery

Discovery

Understand what an agent should discover first through MCP and how discovery should stay explicit, narrow, and safe.

This page explains the first machine-facing handshake, what an agent needs to learn before deeper integration and why discovery should stay boring.

Before you continue

Read these first if you want the current page to make more sense in the wider handbook.

What discovery should answer

An agent arriving at the MCP surface should be able to answer:

  • what system is this
  • what role does this surface play
  • what stable contracts exist
  • where examples and schemas live
  • what the boundaries of the surface are

That is enough for safe orientation.

What discovery is not

Discovery should not be confused with:

  • business trust evaluation
  • public market visibility
  • live runtime execution
  • permission to perform protected actions

Those belong to other layers.

The shape of good machine discovery

Good discovery is:

  • explicit
  • shallow
  • parseable
  • stable
  • easy to cache

That means the first machine-visible responses should emphasize clarity over richness.

Why boring is better

If discovery becomes too clever:

  • parsing gets harder
  • behavior becomes less predictable
  • tooling becomes more brittle

The best discovery surface often feels almost plain.

That is a feature, not a weakness.

  • platform identity
  • document index or tool listing
  • schema locations
  • example locations
  • capability summary
  • boundary notes about runtime or auth

Relationship to MechaReg

MechaReg helps external AI systems discover businesses.

MCP helps a machine client discover the Mecharim contract surface itself.

These are related but distinct forms of discovery.