A standard way to document an MCP server
An MCPDoc describes one MCP server: what it does, how to connect to it, which tools it offers and on what terms. Every fact in it is marked with where that fact came from, so a reader can tell the publisher's own description from something somebody confirmed by connecting to the server.
Three marks
Every field carries exactly one of these. They are the only thing MCPDoc adds to documentation a publisher has already written.
A publisher's documentation is right on the day it is written, and
most of an MCPDoc is that documentation, marked said. The
marks let a reader see which parts have been confirmed since, and
when.
Why the marks earn their place
Browserbase's README lists all six of its tools and says the table
matches their hosted server. In it, navigate takes
{ url: string }, and start and
end take nothing at all.
Ask the hosted server, and all six tools take a sessionId that the README does not mention once.
Nobody was careless. That repository is archived, so its README stopped while the server kept going. This is ordinary, and it is why a tool list is worth marking with a date rather than printing as a plain fact. That server's MCPDoc is the worked example on this site.
Generating one
An MCPDoc can be written by hand, but for a hosted server most of it can be read directly. The generator opens a session, asks for the tool list, and optionally reads the server's public repository metadata.
# a hosted server, and its repository
npx mcpdoc https://mcp.example.com/mcp --repo owner/name --by "Your Name"
It writes mcpdoc.json, which is the document, and
mcpdoc.html, which renders it. It never calls a tool,
never installs anything, and never writes outside the directory you
run it in. Full instructions.
What MCPDoc is not
It is not a review, a rating or a score, and there is no badge. A badge collapses provenance into one word, and provenance is the part a reader needs.
It does not replace a publisher's own documentation. Setup, credentials and worked examples are theirs to write and nobody else can. MCPDoc gives that documentation a shape other tools can read, and records which parts anybody has stood behind.
Related
AgentDoc does the same job for an agent rather than an MCP server: one document about one agent, assembled from several sources, with every line saying where it came from. Both are chapters of the same family of standards developed alongside AgentMesh.