MCP server

MCP server 表示仓库主要交付一个 Model Context Protocol 服务面，供 agent/client 通过 MCP 调用工具、资源或相关能力。这里的重点不是“有 HTTP API”，而是协议层契约、工具语义和上游/下游映射。

它通常会和 Dockerized dev、Rust web service、Service ports 一起出现，但不替代这些 Topic：MCP server 解释的是协议服务面，其他 Topic 解释服务实现、部署或端口边界（projects/mineru-remote-mcp.md、projects/tavily-hikari.md）。

当 README、project snapshot 或服务描述明确表明仓库暴露 MCP endpoint、MCP-over-HTTP、tool proxy 或 agent-facing tool/resource surface 时使用。若只是普通 Web API，不应命中。

如果一个改动会影响工具契约、协议 transport、上游映射、auth、operator console 对 MCP 状态的可见性、或代理服务器如何转发/审计 MCP 请求，就应该命中本 Topic。

• Typically packaged as a Rust HTTP service with supporting tooling (projects/mineru-remote-mcp.md)
• Often paired with operator-friendly scaffolding like Docker/compose and/or a small web UI (projects/tavily-hikari.md)
• MCP 服务通常会包装成 Rust HTTP 服务，但真正要保的是协议契约：哪些工具暴露给谁、输入输出怎样稳定、出错时怎样定位。
• operator scaffolding 如 Docker/compose、小型 Web UI 或审计视图很常见，因为 agent-facing 服务一旦出问题，维护者需要可视化地看见 upstream、请求和结果状态（projects/tavily-hikari.md）。
• 回答此 Topic 时，应先分清仓库是在“原生 MCP 服务”还是“为某个上游做 MCP proxy/adapter”。这两种都叫 MCP server，但维护重点不同。
• 协议层 smoke test 很重要。普通服务测试无法证明工具清单、参数映射和 MCP transport 仍然一致。

• projects/mineru-remote-mcp.md：更偏“原生远程 MCP server”，适合说明协议服务面和文档处理后端之间的边界。
• projects/tavily-hikari.md：更偏“MCP proxy/adapter”，适合说明上游匿名化、key pool、审计和 operator UI 怎样共同支撑一个 agent-facing 服务。

• 把普通 HTTP 服务误写成 MCP server，会把 Topic 语义直接掏空。
• 把 MCP server 当成整个仓库的总括标签，忽略 Dockerized dev、Rust web service、Service ports 等相邻 Topic，会让后续 Agent 无法判断真正该看的是协议契约、部署边界还是服务实现。
• 只测后端处理逻辑、不测 MCP 工具契约，会让协议漂移在很晚才被发现。
• 不区分原生服务与 proxy/adapter，也会让后续维护者在错误层级修问题。

• projects/mineru-remote-mcp.md
• projects/tavily-hikari.md
• skills/style-playbook/references/data/topics/mcp-server.json