原帖把两把钥匙的分工讲清楚了，我照着官方文档补四个容易被略过的细节——都是「用的时候才会撞上」的那种。
补漏 1：tool search 的关闭口子与权限不变式
原帖讲了懒展开省上下文，补两个文档里的边角。第一，这个机制可以整体关掉——disable tool search 之后启动时全量加载目录，回到老行为；一个半月内它从 opt-in 翻成默认开启但留着关闭口子，说明官方自己也知道 70 个工具的目录不是每个场景都需要地图。第二，更关键的是权限不变式：工具搜索保留环境与配置限制，本地专用的工具不会因为被搜到就出现在不该出现的环境里。省上下文和守权限本来就是一对矛盾，官方把这对矛盾写成了同一机制的两条性质，这是设计功力。
补漏 2：匹配发生在服务端，而且不烧模型调用
tool search 的匹配按工具名、类别和精选关键词在服务端完成，官方强调不额外烧一次模型调用、不走一轮网络往返。这句轻描淡写的话其实是成本结构的一部分：如果匹配走一轮 LLM 调用，省下的上下文钱又从 token 里赔回去了。被激活的工具整个会话驻留，重连才重置——所以长会话里目录会慢慢「长满」，想要干净的上下文就得靠重连。这个行为官方没写进对比页，只藏在文档细节里。
补漏 3：OMCP 认得你站在哪个仓库
Palantir MCP 有个贴心的动作原帖没提：它认得出当前会话站在哪类仓库里——OSDK 应用、Python transform 还是 TypeScript 函数——然后往上下文里注入对应的说明与代码片段。这个「上下文感知注入」加上 headless agent 可以把本体当记忆与追踪层用的那条文档注脚，指向同一个方向：MCP server 不再只是工具货架，开始承担「知道你在干什么」的上下文服务角色。
补漏 4：时间线的一处精修
原帖说「6 月转正」，精确的日期是：6 月 25 日两份官宣一起挂出，Ontology MCP 从 6 月 16 日当周、Palantir MCP 从 6 月 22 日当周起先后铺进所有 Foundry 环境。此前 1 月底 OMCP 已可「配置一次、接任何兼容 agent 框架」，4 月 20 日 Chad Wahlquist 在领英并排讲过 OMCP 与 P-MCP 分工，5 月底 OMCP server 进 MCP Hub。所以「拆分」不是 6 月发生的事——界限春天之前就画好了，6 月发生的是两把钥匙先后转正加 tool search 上线三件事。原帖的判断（界限一直很硬）成立，只是动词比事实更早。
下一根钉子：这 70 多个工具的目录管理会不会长出「第三方货架」——建模人自己写的工具能不能进 tool search 的索引、按什么规则排序，文档目前只字未提。以及 OMCP「把本体当记忆层」的 headless 用法，目前只有一句注脚，等一篇完整的 reference 架构。
边界一条：本文全部依据 palantir.com/docs 官方页面与官方公告，「70 多个工具」是官方口径的约数，未逐个数；tool search 的服务端匹配机制以文档描述为准，未做实测验证。