MCP 值不值得接，我的答案一直是同一句：看你是在替谁付账。工具 schema 每轮都要进上下文，这笔钱按轮计，不是一次性的接入成本。自己写的三个内部函数包成 MCP server，等于给自己加一层协议税。反过来，接 GitHub、Stripe 这类别人维护的东西，MCP 是现在最省事的接口。这周外部没什么直接讲 MCP 的新料，但 HarnessTax 那篇离得很近——harness 本身有成本，只是平时没人量。
这笔账得自己量
MCP 的成本结构很清楚：server 把 tools 的名字、描述、参数 JSON Schema 交给客户端，客户端每轮请求都带上。描述写得越细——通常也是必要的——每轮付得越多。
怎么量？把 tools 数组 dump 成 JSON，跑一遍 tokenizer 得到单轮开销，再乘上你估的平均轮数。一个描述写得比较细的 server，在十来轮的对话里能吃掉相当一块上下文预算。具体数随 server 差异很大，我不给，你测两分钟就有。
Harnesstax 和那篇 harness design 的实证研究（arXiv）在做同类的事：把 harness 拆成组件，看哪个组件真在影响结果。它们讲的是 coding harness 不是 MCP，但方法能直接搬——别把「接了 MCP」当整体评估，拆成 schema 开销、往返延迟、错误处理三块分别量。
自己写的工具走 MCP 是加税
工具就是自己团队写的五六个函数——查订单、发通知、读内部库——那 MCP 给的东西你一样用不上。
直接函数调用：类型编译期就查了，参数错了堆栈直接指到那一行，日志、断点、单测全在熟悉的地方。套上 MCP 之后中间多一层 JSON-RPC，出错要看两边日志，还得管连接、超时、子进程。这些活本来不需要存在。
我不太信「统一协议以后好维护」。自己写的东西接口怎么改你说了算，重构一次 grep 就完了。协议的价值在跨边界的地方，不在边界内部。
值得接的就三类场景
第三方生态排第一。GitHub、Slack、各种 SaaS 都有官方或社区维护的 server，自己写一遍既慢又会烂——上游 API 在变，让维护者去跟。这里省下的是持续维护成本，比 token 那点开销值钱。
热插拔排第二，工具集要按用户配置在运行时增删，MCP 的进程模型天然适配。跨客户端跨语言排第三：同一套工具给 Claude Code、Cursor 和自己写的 agent 共用，或者 server 是 Go 写的而 agent 是 Python，协议就是唯一的公共语言。Skillsync 这种「会话跨 agent 可移植」的项目能冒出来，说明需求是真的。
接第三方等于接别人的信任边界
这条比 token 账更该算。ZCode 那个事——coding agent 静默上传 git history——提醒的正是这个：agent 手里有多大权限，接进来的 server 就有多大。第三方 server 拿到的是你的文件、网络和凭据。
我的做法是第三方 server 一律跑容器里，只挂它真需要的目录，凭据单独发。麻烦，但比事后翻日志便宜。
落到判断：三条都占才接
工具不是自己写的、需要在运行时增删、有跨语言跨客户端的硬需求——三条都占才接。一条不占：自己写、集合固定、单语言单客户端，那就别接，直接函数调用。这不保守，是少一层能坏的东西。
Claude Code 这周开始认 AGENTS.md（changelog），说明「配置进上下文」这件事大家都在往同一个方向收。也许 6 个月后生态成熟到维护成本可以忽略，结论会变。按我现在看到的，账还是这么算。