一句话答案
MCP（Model Context Protocol）是让 AI 客户端以统一方式发现和调用外部资料、工具与工作流的开放协议。 对开发者最实用的开始方式，是先连接少量、权限受限的现成 MCP；当 AI 需要真正理解你的产品时，再为自己的业务 API 写一个小而安全的 MCP Server。
MCP Server 到底是什么？
可以把 MCP 想成 AI 世界的 USB-C。
以前，每个 AI 工具要连接 GitHub、数据库、文件或内部系统，都得各自写一套插件。MCP 把这件事标准化：一个 MCP Server 将能力公开为三种东西：
- Tools（工具）：AI 可以请求执行的动作，例如搜索 issue、读取订单或创建草稿。
- Resources（资源）：给 AI 阅读的上下文，例如文件、数据库 schema、产品文档。
- Prompts（提示模板）：由用户选择的、可复用的工作流程入口。
这不等于把控制权交给模型。好的 MCP 客户端会展示工具说明和输入；你的 Server 也应该把每个工具限制得很清楚。一个叫 get_order_summary 的工具比一个能执行任意 SQL 的 run_sql 安全得多。
官方说明与规范在 Model Context Protocol 文档；它也解释了 Server 的 tools、resources 和 prompts。
在哪里看 MCP Server 清单？
从 官方 MCP Registry 开始，而不是从一张过期的「Top 100 MCP」清单开始。Registry 是公开 Server 的官方元数据目录；可以按名称和能力搜索，并查看安装与配置资料。它仍在 preview，因此把它当成发现入口，不当成安全背书。
选一个 Server 前，先做这五个检查：
- 发布者是谁？ 优先公司或开源项目的官方仓库，而不是同名的第三方包装。
- 它能读什么、写什么？ 看工具名称、输入 schema 和 OAuth scopes，不只看简介。
- 凭证放在哪里？ 本地 stdio Server 通常从环境变量取凭证；远程 HTTP Server 应有合适的授权流程。
- 有没有源码、版本和维护记录？ 没有这些，就不该接触生产资料。
- 能否从只读开始？ 先让它搜索、预览、起草；确认流程后才开启创建、发送或删除。
开发者最值得先用哪些 MCP？
不要追求「装得最多」，要追求「每一个都解决一个明确摩擦点」。下面是一个适合 Web / Next.js 开发者的起步组合；用 Registry 搜索相应服务的官方或可信实现。
| 场景 | 优先能力 | 安全起点 | | -------- | ------------------------------- | --------------------------------------------------------- | | 代码库 | Git、GitHub、issue、PR | 只读搜索和 diff；不要一开始允许 merge 或 push | | 本地项目 | 文件系统 | 只允许当前仓库或指定工作目录，绝不授权整个 home directory | | 技术资料 | 文档搜索 / API reference | 只读；让 AI 取得框架和 SDK 的最新文档 | | 前端验证 | 浏览器自动化 / Playwright | 只针对本地或 preview URL；用测试账号 | | 数据库 | PostgreSQL、Supabase 等数据工具 | 单独的只读角色、只读 view、行数限制与审计 | | 可观测性 | Sentry、日志、分析 | 先查错和汇总，不开放修改 alert 或删除数据 | | 发布流程 | Vercel、GitHub Actions | 先读取部署状态；生产部署应保留人工确认 | | 团队工作 | Linear、Slack、Notion | 先检索与起草；发送消息或改 ticket 前要确认 |
官方参考 Server 也很适合学习协议本身：filesystem、git、memory、fetch、time 和 sequential thinking 都可在 Example Servers 找到。它们是范例，不代表你必须在生产环境使用它们。
本地 MCP、远程 MCP，还是把 MCP 接进我的 App？
这三个做法很容易混在一起，实际上目标不同：
| 目标 | 最合适的做法 | | ---------------------------------------- | ---------------------------------------------------- | | 让 Codex、Claude Code 或桌面 AI 帮你开发 | 在开发机配置本地 MCP；一般用 stdio 启动 Server | | 让团队 AI 连接一个共享服务 | 部署远程 MCP；一般用 Streamable HTTP 和正式认证 | | 让 AI 能理解或操作你的产品 | 为你的业务 API 包一层 MCP Server，严格设计工具和权限 |
本地 stdio 很适合开发机：客户端启动子进程，经 stdin/stdout 传 JSON-RPC。注意：stdio Server 绝不能把日志写到 stdout，否则会破坏协议；日志写到 stderr。对于部署给多人使用的远程 Server，官方 TypeScript SDK 建议使用 Streamable HTTP；旧 SSE 方式仅用于兼容旧客户端。详见 TypeScript SDK Server 文档。
为 Next.js 应用设计 MCP：先从业务边界开始
你的 Next.js app 不应把整个数据库、所有内部 API 或环境变量暴露为一个「万能工具」。先列出 AI 真正要完成的用户任务，再把它切成小工具。
以一个内容网站为例，好的第一版可能只有：
search_published_articles(query, limit)：只搜索已发布内容，limit有上限。get_article_outline(slug)：返回标题、摘要、目录和公开 URL。draft_related_links(slug)：生成建议，不自动改文章。get_contact_message_summary(date_range)：仅给授权管理员的汇总，不返回不必要的个人资料。
不好的第一版则是：
execute_sql(sql)read_any_file(path)call_internal_api(url, body)
前者让权限、测试和审计成为可能；后者只是把万能管理员钥匙递给模型。
最小可行架构
AI client (Codex / Claude / your agent)
|
MCP transport
|
MCP Server (server-side)
|
authenticated business service / API
|
database, CMS, GitHub, Vercel
浏览器永远不应直接持有 MCP 的服务凭证。若你的网页需要触发 AI 动作，它只调用你自己的受保护 Next.js Route Handler；Route Handler 或后台 worker 再按当前用户权限调用业务服务或 MCP client。
从零开始：为你的应用写一个 MCP Server
Node / TypeScript 项目的官方 SDK 安装方式如下：
npm install @modelcontextprotocol/sdk zod
先做一个独立的 Server（例如 mcp-server/），而不要把它塞进前端组件。下面是结构示意：
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({ name: "my-app", version: "0.1.0" });
server.registerTool(
"search_published_articles",
{
title: "Search published articles",
description: "Search public, published articles only.",
inputSchema: {
query: z.string().min(2).max(120),
limit: z.number().int().min(1).max(10).default(5),
},
},
async ({ query, limit }) => {
const articles = await searchPublishedArticles({ query, limit });
return {
content: [{ type: "text", text: JSON.stringify(articles) }],
};
},
);
searchPublishedArticles 应是你自己服务端的函数：它只查 published 内容、参数化查询、限制返回字段和笔数，并记录调用者与操作。不要在工具 handler 中拼接 SQL，也不要信任模型提供的 URL、路径或用户 ID。
开发机整合时，接上 stdio transport；要部署远程服务时，改用 Streamable HTTP，并在每次请求建立身份、权限和 rate limit。SDK 也提供 client API 来列出和调用 tools，参考 TypeScript SDK Client 文档。
接入现有 Next.js API 的实际步骤
- 盘点可公开的业务能力。 为每个候选工具写清楚：谁能调用、能读写什么、输入上限、失败行为和审计字段。
- 先建立服务层。 把 Supabase、CMS 或第三方调用封装在 server-only 函数中；不要让 MCP handler 直接碰浏览器代码。
- 写一个只读工具并测试。 先用 5–10 笔确定数据测试 schema、错误讯息和权限拒绝。
- 加入身份与授权。 远程 MCP 不靠「知道 URL 就能用」；验证 access token，把用户和 tenant 传到每次业务查询。
- 加限制与日志。 每个工具设 timeout、分页 /
limit上限、rate limit，以及不记录敏感正文的审计日志。 - 最后才部署。 先在 preview 环境对测试资料跑通；确认所选 Vercel runtime 支持你的 Streamable HTTP 连接模式与认证流程，再接生产域名。
一个给这个网站的务实起点
这个网站现在以 Markdown 为内容来源，文章、工具和 Wiki 已有清晰的 loader。比起先把 Supabase 管理权限开放给 AI，更合适的第一批 MCP 工具是：
- 搜索已发布 articles、tools 和 wiki；
- 读取单一条目的公开 metadata 与目录；
- 根据现有 tags 建议内部链接；
- 验证新 Markdown frontmatter 是否符合项目 schema；
- 只在人工确认后，创建内容草稿或 Git 分支。
这会让 AI 帮你做内容维护和开发工作，却不会让它接触 SMTP 密码、Supabase 管理密钥或整个文件系统。
安全清单：MCP 最容易踩的坑
- 只安装你能追溯发布者和源码的 Server。
- 不要把 API key 写进 Git、MCP config、文章或 client bundle；使用环境变量和密钥管理。
- 对数据库和 SaaS 分离只读与写入凭证；生产写入最好经过审批。
- 将文件系统 Server 限制到单一项目目录。
- 不把不可信网页、issue、文档的文字直接当作系统指令执行；它们可能包含 prompt injection。
- 对删除、发送、部署、付款和权限变更设置显式确认与审计。
- 定期移除不用的 Server 和 token；权限会随着项目演变而累积。
官方的 MCP Security Best Practices 值得在上线远程 Server 前完整阅读。
结论
MCP 的价值不在于让 AI 获得「所有权限」，而在于让它在边界清楚的情况下完成真实工作。对开发者来说，最聪明的路径是：先装少量只读 MCP 解决日常开发摩擦；再将自己应用中最稳定、最可审计的业务能力做成小工具。这样 AI 才会成为可靠的协作者，而不是一把不知道交给谁的万能钥匙。
