Should MCP servers provide a portable description artifact?

[ObjectIsAdvantag]

Welcome, I’m introducing the {mcpdesc} project today, with this simple question:

Should MCP servers provide a portable, versioned description artifact alongside runtime discovery?

Over the past year, we have been experimenting at DevNet — Cisco’s developer program — with MCP server lifecycle, documentation, quality, compliance, and governance.
That work repeatedly highlighted the value of a durable engineering artifact for MCP servers: something teams could store in git, review, compare across releases, use to generate documentation, and to evaluate design, quality, consistency and compliance.

After several iterations, the MCP Description format —mcpdesc— emerged, based on our experience with OpenAPI, API lifecycle best practices and tools available across the broader OpenAPI community.

Twelve months later, the MCP ecosystem has not yet converged on a format for static server descriptions, although interest is beginning to emerge.
On July 28, 2026, MCP will publish its next major specification revision. The revision brings important improvements that should help the protocol and its ecosystem continue to scale. It does not, however, introduce a general, portable artifact for describing the capabilities of a specific MCP server version.

Runtime discovery remains essential. The goal of {mcpdesc} is not to replace runtime discovery, registries, or Server Cards.
It is to explore how a static description artifact could complement these across the lifecycle of an MCP server.

A few weeks ago, the toolset we have been using internally to document and govern MCP servers was open sourced. The tools build on a common format - MCP Description - mcpdesc documents.

Today, I am launching the {mcpdesc} project to gather practical feedback, extend the tooling ecosystem, and help shape an open and interoperable approach to MCP server descriptions.

The project begins with a concrete draft specifications and tools.
Success may mean that MCP Description evolves into a shared format. It may also mean that its ideas and lessons contribute to a different approach adopted by the broader MCP ecosystem.
What matters is convergence toward one interoperable way to describe MCP servers.

And that discussion starts with the people who use, design, implement, document, test, operate, and govern MCP servers.

I invite you to read the launch post, explore the project, and share your perspective. Looking forward to hear from you and your own experience.

Stève