MCP Server Card
An MCP server card is an agent-readable summary of an MCP server's tools, resources, authentication requirements, and safe usage boundaries.
MCP Server Card
An “MCP server card” is a proposed documentation artifact: a concise summary of what a Model Context Protocol server offers. It is not a separate object defined by the MCP specification, and clients should not assume a file named server-card.json exists.
MCP already defines capability negotiation during initialization and protocol methods for listing tools, resources, and prompts. A server card can help a human evaluate a server before installation, but it must not replace live protocol discovery.
For a practical implementation model, read MCP Server Card for SEO and Product Websites.
Documented summary versus live truth
| Concern | Documentation can explain | Protocol or runtime must verify |
|---|---|---|
| Capabilities | Intended tool and resource categories | Negotiated capabilities and list methods |
| Input safety | Consequential actions and confirmation rules | Tool input schema and server-side validation |
| Authentication | Setup flow and required account | Actual OAuth or transport authorization |
| Data handling | Retention and privacy policy | Effective permissions and outbound requests |
| Versioning | Release and compatibility notes | Initialized protocol version |
If the summary and live server disagree, the client must treat the live negotiated interface as authoritative and surface the mismatch.
What It Should Include
- Server name and publisher
- Tool categories and example use cases
- Required authentication
- Data boundaries and privacy notes
- Rate limits or usage constraints
- Documentation and support links
- Version and last updated date
Why It Matters for SEO
For product and content websites, an MCP server can expose capabilities that a normal page cannot:
- Product lookup
- Inventory or pricing checks
- Documentation search
- SEO audit tools
- Support knowledge base retrieval
A server card can give operators a safer first read before they connect a client. It does not make a tool safe by itself.
Evaluation checklist
- Connect with a test client and capture the initialization result.
- Compare declared capabilities with
tools/list,resources/list, andprompts/listwhere supported. - Verify that every consequential tool has a precise input schema, least-privilege authorization, and confirmation boundary.
- Test invalid input, permission denial, timeout, cancellation, and partial failure.
- Check whether tool descriptions overstate guarantees or hide external side effects.
- Record protocol version, server version, publisher identity, support path, and review date.
Publication boundary
Do not create a new public “card” URL only to target an SEO query. Publish it when a real installation or trust decision needs a stable, reviewable summary. Otherwise, keep authoritative information in the MCP server, product documentation, and security policy to avoid another drifting metadata surface.