MCP协议正在悄然改变AI与本地工具的交互方式。它像一座隐形的桥梁，让Claude等AI客户端直接调用文件系统、数据库甚至自定义脚本的能力，省去繁琐的复制粘贴。本文将深入剖析MCP的工作原理，分享从server搭建到权限管控的一线实战经验，揭示如何让AI真正成为你的效率伙伴。

我最早接触 MCP 是因为 Claude 读不到我本地的笔记。每次想让它帮我整理一段会议记录，都得先复制粘贴一遍——文件大一点就被截断，几轮下来很烦。

MCP 解决的就是这件事：让 AI 客户端直接连到你手头的工具和数据，不用每次都把内容塞进对话框。

它到底在做什么

简化一点说，MCP 是一个协议。一头是 AI 客户端(比如 Claude Desktop 或者 Claude Code)，另一头是各种 server——可以是文件系统、数据库、Slack、GitHub、你自己写的脚本，什么都行。客户端通过协议跟 server 通话，调用 server 暴露出来的能力。

server 暴露三种东西：

1. Tools：模型可以调用的函数，比如”查询数据库”、”创建文件”
2. Resources：模型可以读取的数据，比如某个文件的内容、某个 API 的返回
3. Prompts：预设好的模板，用户主动触发

这三类的边界其实是模糊的。一个”读取日志文件”的能力，做成 tool 还是做成 resource 都说得通。

我自己的判断标准是：模型要自主决定什么时候用 → tool;用户明确想看 → resource。

实际跑起来长什么样

举一个我每天都在跑的场景。我有一个本地 server，挂在 Obsidian 笔记目录上。

Claude 启动的时候读到这个 server 的配置，建立连接。我在对话里说”找一下我上周关于产品复盘的笔记”，模型看到 server 提供了 search_notes 这个 tool，自己决定调用它。server 返回搜索结果，模型拿到几篇笔记的内容，整合回答。

整个过程我感觉不到协议在哪里。

但前两周我踩过坑。最早写 server 的时候，我把整篇笔记内容一次性塞回给模型，结果几次调用之后上下文就炸了。后来改成只返回标题和摘要，需要详情的时候模型再调一次 read_note 拿单篇——这才跑顺。

这件事提醒我：MCP 不是给模型开一个无限内存的接口，它是个带宽有限的通道。设计 tool 的返回值，跟设计任何 API 一样得考虑分页和粒度。

自己写一个 server 难不难

不难，但有几个坑。

官方有 Python 和 TypeScript 的 SDK。最小的 server 大概几十行代码：定义 tool 的 schema，写一个 handler，跑起来。

真正花时间的是 schema 设计。我第一版的 tool 描述写得很糙，类似”搜索笔记”四个字，模型经常不知道什么时候该调、参数该填什么。第二版我把描述写得更具体——什么时候用、参数格式举例、返回值长什么样——模型的调用准确率明显上来了。

调试也比想象中花时间。tool 调失败的时候，错误信息要写清楚：告诉模型是参数错了、是后端没数据、还是网络问题。模型看到清楚的错误才知道下一步该怎么试。

几件非显然的事

• 不是所有事情都该做成 MCP server。一次性的脚本让 Claude 直接跑就行，做成 server 反而增加维护成本。值得封装成 server 的，是那些反复用、需要持久状态、需要权限管控的能力。
• 权限要写死，不要让模型权衡。涉及删除、写入、对外发请求的 tool，要么默认关闭，要么有非常明确的确认机制。模型在长对话里偶尔会做出你预期之外的选择，安全边界得在 server 这一侧守住。
• 本地 server 比远程 server 好上手。stdio transport 用一个命令行进程就能跑，不用部署、不用鉴权。开始的时候没必要折腾 HTTP server。

跑通一个 MCP 流程其实不复杂，几十行代码的事。难的是判断哪些能力值得封装、哪些不值得。这点没有通用答案，得看你平时怎么干活。