MCP Server Card 是一种在 agent 调用工具前，先说明 MCP server 能力和边界的紧凑描述。
对 SEO 团队来说，关键问题不是“能不能再加一个 agent 文件”，而是：
这个产品网站是否有真实能力，需要让 agent 安全地发现？
如果答案是肯定的，Server Card 可以把普通网站发现和产品能力发现连接起来。如果答案是否定的，它就太早了。先从 面向 AI Agents 的 Link Headers、llms.txt、干净 sitemap 和 Agent SEO 审计 基础层开始。
这篇文章解释 MCP Server Card 什么时候应该进入 Agent SEO 路线图、需要包含哪些字段、如何连接 API discovery，以及如何验证它，同时避免把它写成排名因素。
MCP Server Card 是什么
Model Context Protocol 让 MCP server 可以向 client 暴露 tools、resources、prompts 等能力。官方 MCP specification 已经说明了 server 侧的 tools、resources 和 prompts。
MCP Server Card 是围绕这个 server 的发现和说明层。它应该告诉 client：
- 谁发布了这个 server
- 这个 server 用来做什么
- 有哪些 tools 和 resources
- 哪些动作是 read-only、write-capable 或 sensitive
- 需要什么认证流程
- 会访问什么数据
- 有哪些 rate limits、安全规则和支持链接
这个说法仍在发展中。MCP 项目有 Server Card Working Group charter，它的范围包括定义什么是 Server Card、文档格式，以及 client 如何发现 Server Card。因此文章和实现都不应该把某一个 JSON 形状写成永久固定标准。
更稳定的 SEO 思路很简单：如果产品有 agent-callable capabilities，就发布一个稳定、诚实、可检查的 capability card。
为什么它和 Agent SEO 有关
传统 SEO 发现主要回答：
- crawler 能找到 URL 吗？
- 页面能渲染吗？
- canonical 是否正确？
- 页面是否有有用链接和结构化数据？
Agent SEO 进一步问产品问题：
- agent 能理解这个站点能做什么吗？
- 它能区分 read、search、export 和 change data 吗？
- 它能在尝试动作前发现文档吗？
- 它能理解认证和安全边界吗？
所以 MCP Server Card 会靠近 API Catalog SEO、Agent Skills Index、WebMCP、OAuth metadata，以及更大的 Agent SEO IsItAgentReady audit 集群。
它不是给所有网站用的。它更适合“产品能做什么”比“文章说了什么”更重要的网站。
MCP 适用性矩阵
在把 MCP 放进路线图前，先用这个表判断。
| 站点类型 | MCP Server Card 适配度 | 更应该先做什么 |
|---|---|---|
| 只有博客或 glossary | 低 | Sitemap、内链、llms.txt、Markdown access |
| 文档站 | 中 | 可搜索文档、llms.txt、Link headers、API docs |
| 没有公开工具的 SaaS marketing site | 低到中 | Agent SEO audit hub、产品文档、schema、清晰价格页 |
| 有公开 API 的 SaaS 产品 | 高 | API Catalog、OpenAPI docs、auth metadata、Server Card |
| Developer platform | 高 | API Catalog、MCP server docs、tools/resources list |
| 有搜索能力的支持知识库 | 中到高 | Resource discovery、docs search tool、隐私边界 |
| Commerce 或账号动作 | 高风险 | Product schema、认证流程文档、明确安全规则 |
重点是避免 protocol inflation。Server Card 应该描述真实 server，而不是为了 scanner score 装饰网站。
应该包含哪些内容
面向 SEO 和产品发现的 Server Card，至少应该覆盖这些部分。
| 字段组 | 应说明什么 | 为什么 agent 需要 |
|---|---|---|
| Identity | Server name、publisher、canonical docs URL、version、update date | 避免歧义和过期发现 |
| Purpose | server 帮用户完成什么任务 | 在调用前限定任务边界 |
| Tools | 名称、描述、input schema 链接、read/write 标签 | 帮助 client 选择安全工具 |
| Resources | 搜索索引、文档、catalog、产品数据、支持内容 | 说明可检索上下文 |
| Prompts | 如果暴露 reusable workflow 或 templates，就列出 | 帮助 client 理解引导式使用 |
| Auth | Public、API key、OAuth、account session、scopes | 避免认证失败或误触发 |
| Safety | 用户确认、破坏性动作规则、数据保留 | 降低自动化风险 |
| Limits | Rate limits、quota、允许的 user agents、支持入口 | 让行为可测试 |
| Discovery | 相关 Link headers、API catalog、docs、changelog | 把 card 接入站点图谱 |
对产品网站来说，最关键的往往不是技术字段，而是边界字段：auth、read/write 状态、用户确认、数据暴露和版本。
示例 Server Card
下面是一个 SEO 产品 MCP server 的说明形状。它是发布模型示例，不是最终标准。
{
"name": "fennecseo-audit-mcp",
"title": "FennecSEO Audit MCP Server",
"publisher": {
"name": "Fennec SEO",
"url": "https://fennecseo.app/"
},
"version": "2026-07-07",
"description": "Tools and resources for technical SEO, Agent SEO, crawler, and schema audit workflows.",
"documentation": "https://fennecseo.app/zh/audit/agent-seo/",
"capabilities": {
"tools": [
{
"name": "run_agent_seo_audit",
"title": "Run Agent SEO audit",
"mode": "read-only",
"description": "Checks discovery, content access, crawler policy, API discovery, and MCP metadata for a public URL."
},
{
"name": "simulate_bot_view",
"title": "Simulate bot view",
"mode": "read-only",
"description": "Compares raw HTML and rendered DOM signals for crawler-facing pages."
}
],
"resources": [
{
"name": "agent_seo_guides",
"type": "documentation",
"url": "https://fennecseo.app/zh/blog/agent-seo-isitagentready-audit/"
},
{
"name": "mcp_server_card_guide",
"type": "documentation",
"url": "https://fennecseo.app/zh/blog/mcp-server-card-seo-product-websites/"
}
]
},
"auth": {
"type": "oauth",
"docs": "https://fennecseo.app/docs/auth/"
},
"safety": {
"requiresUserConfirmationFor": ["write", "delete", "publish"],
"publicDataOnly": true,
"notes": "Read-only audits should not modify websites or accounts."
},
"limits": {
"rateLimit": "documented by plan",
"support": "https://fennecseo.app/contact/"
}
}
真实实现时，应随着 Server Card 工作组输出稳定而调整字段。内容原则不变：描述真实 tools、真实 resources、真实 auth 和真实 limits。
发现路径
如果没有任何地方指向它，Server Card 会很弱。
建议使用分层发现路径：
- 从可见的产品或开发者文档链接。
- 加到 Agent SEO 或 API documentation hub。
- 当 API Catalog 列出 MCP 相关资源时，从 catalog 引用它。
- 只有 URL 稳定且可维护时，再加 HTTP
Linkheader。 - 当 Agent Skills 映射到 MCP tools 时，从 skills index 引用它。
示例 Link header：
Link: </.well-known/mcp-server-card>; rel="describedby"; type="application/json"; title="MCP Server Card"
不要把 card 藏在只有 scanner 知道的位置。如果它对 agent 重要，也应该能被开发者、产品负责人和安全复查者理解。
如何验证
把 Server Card 同时当成技术 SEO 资产和产品契约来复查。
| 检查项 | 通过条件 |
|---|---|
| URL 稳定性 | Card URL 返回 200，并从文档链接 |
| Content type | JSON card 使用合适的 JSON content type |
| 新鲜度 | Version 和 updated date 与当前 server 行为一致 |
| Tool 准确性 | 列出的 tools 存在，名称与 MCP response 匹配 |
| Resource 准确性 | 列出的 resources 返回预期状态码 |
| Auth 清晰度 | Public、OAuth、API key 要求清楚 |
| Safety | Read-only 与 write-capable 动作分开 |
| 内链 | 连接到 API docs、Agent SEO docs 和 support |
| 不夸大 | 文案不承诺排名、引用或自动访问 |
然后继续用 Technical SEO、Bot Simulator 和 Schema Markup 检查围绕它的页面。Server Card 有效，并不代表页面没有 canonical、rendering 或内链问题。
常见错误
避免这些做法：
- 没有 MCP server，却发布 MCP Server Card
- 列出计划中但还不存在的 tools
- 不标注 read-only 与 write-capable 账号动作
- 忘记 auth、scopes 或用户确认要求
- Link headers 指向草稿或私有 card
- 把 card 当成 API docs、sitemap 或 schema 的替代品
- 多语言文档和支持不同，却所有语言复用同一张 card
- 承诺没有任何来源能保证的 AI visibility 收益
好的 Server Card 应该“朴素但可靠”：准确、有边界、有链接、能测试。
Fennec 工作流
判断 Agent SEO sprint 是否需要 MCP Server Card，可以按这个流程走。
- 先跑 Agent SEO Audit，检查当前发现信号。
- 复查 面向 AI Agents 的 Link Headers，确认基础 HTTP discovery 干净。
- 盘点真实产品能力：public APIs、search endpoints、docs、tools 和 auth flows。
- 判断站点需要 API Catalog、MCP Server Card、Agent Skills，还是三者都需要。
- 只为今天已经存在的能力写 Server Card。
- 验证状态码、Content-Type、auth notes、safety labels 和内链。
- 用 Bot Simulator 和 Technical SEO 复查页面。
对大多数内容站来说，第 4 步就会停止 MCP 工作。这没问题。Agent SEO 只有在每个信号都有真实用途时才有价值。
总结
MCP Server Card 不是魔法 SEO 文件。它是给 agent-facing 产品使用的能力说明。
当站点有真实 MCP tools、resources、prompts 或 API-backed workflows，并且这些能力需要结构化发现和安全边界时，再使用它。只是为了让 readiness scanner 好看，就不值得加。
这也是 Agent SEO 真正有用的地方：给 crawler 清楚的公开内容，给 agent 清楚的机器资源，并在任何动作发生前给出清楚边界。
Sources
- Model Context Protocol: Server Card Working Group charter
- Model Context Protocol specification: Tools
- Model Context Protocol specification: Resources
- Model Context Protocol specification: Prompts
- IETF RFC 9727: The api-catalog Link Relation Type
问答
MCP Server Card 是官方排名信号吗？
不是。它应该被看作 agent 能力发现信号，而不是 Google 排名捷径，也不是保证 AI 引用的信号。
内容站需要 MCP server 吗？
通常不需要。大多数内容站应该先做好可抓取性、sitemap、llms.txt、Markdown access、Link headers 和清晰策略信号。
什么时候适合做 MCP Server Card？
当站点有真实 agent-callable tools、API-backed workflow、文档搜索、账号安全动作或其他产品能力需要说明边界时，Server Card 才有意义。
MCP Server Card 应该从哪里被发现？
优先从可见文档、API 或 Agent Readiness hub 链接；只有当 URL 稳定、公开且可维护时，再通过 Link headers 等 HTTP discovery 暴露。
