FAQ

Common questions about MCP Description (mcpdesc) and how it relates to the MCP ecosystem.

What is {mcpdesc}?

The {mcpdesc} project is an independent open source initiative promoting an open, portable, machine-readable description format for MCP servers — an open proposal whose goal is to help the MCP ecosystem converge on interoperable server descriptions.

MCP Description (mcpdesc) is that format: it declares everything an MCP server offers — tools, resources, prompts, transports, and security — much like OpenAPI does for REST APIs.

Where does mcpdesc fit in the MCP ecosystem?

The MCP ecosystem is moving fast. Registries help users discover servers. Server Cards explore pre-connection discovery. Bundle formats make local installation easier. Gateways help teams run, secure, and observe MCP traffic. Inspectors help developers test servers at runtime. OpenAPI-to-MCP generators help teams expose existing APIs to agents.

mcpdesc focuses on a different layer. It is about the lifecycle, documentation, and compliance of MCP servers.

When a server changes from one release to the next, teams need a stable artifact that captures what that specific version exposes. They need these artifacts to compare capabilities, detect major changes, generate changelogs, produce documentation, and/or check compliance.

Does mcpdesc replace registries, gateways, or inspectors?

No. MCP Description documents do not replace registries, Server Cards, gateways, inspectors, or package formats. They complement them by giving engineering teams a versioned description of server capabilities that can be stored, reviewed, compared, and reused across workflows.

Server Cards exclude primitives — why does mcpdesc describe them?

SEP-2127 (MCP Server Cards) intentionally omits primitive definitions (tools, resources, and prompts) from Server Cards. Its reasoning is sound for what a Server Card is: a small, public, read-only document served for pre-connection discovery. Because an MCP server’s runtime surface can vary by user, session, and configuration, a public discovery document should not carry primitives — and clients should never treat a static manifest as an access-control or safety signal.

mcpdesc operates at a different layer: an MCP Description document is not a public discovery endpoint; it is a versioned engineering artifact that describes what one specific release of a server exposes — reviewed in pull requests, stored in Git, and used to compare releases, generate documentation, and check consistency. It answers “what does this version globally offer, and what changed?”, it does not address: “what can a particular authenticated user call right now?” (which is covered by the runtime tools/list).

Notably, the SEP itself flags this gap as unfinished work: “a follow-on SEP should address the prerequisites … before primitive advertisement is added.” The {mcpdesc} project explores that space today.

How do the project, community, and tools relate?

The {mcpdesc} project stewards the format, its specification, examples, and the neutral catalog of compatible tools; it is led by its maintainers and open to contributions.

The {mcpdesc} Community is the people around it — maintainers, contributors, users, adopters, and tool builders.

The curated list of tools illustrates the benefits of the MCP Description format by covering specific use cases.

How is the project governed?

The {mcpdesc} project uses a lightweight, consensus-oriented governance model. Maintainers review and merge changes, guide the roadmap, maintain the specification, and curate the tools catalog; larger changes — to the specification, schemas, governance, or public positioning — call for broader feedback before merging. See Governance for the summary, or the full GOVERNANCE.md document.

Is this project affiliated with Anthropic or other MCP vendors?

The {mcpdesc} project is an independent and community-based initiative.

The project is NOT affiliated with or endorsed by Anthropic, or other MCP ecosystem vendors. It is also NOT a Cisco product, service, or official Cisco standardization effort.