严格定义：MCP是什么到底指什么

MCP 到底是什么：我先给一个能落地的定义

我先把话说死一点：MCP 不是模型，不是数据库，也不是某家厂商的私有插件规范，它是一层”接入协议”。全称 Model Context Protocol，中文一般译作”模型上下文协议”，2024 年 11 月由一家美国大模型公司开源。它干的事情很朴素——把大模型应用和外部世界之间那根线，从”每家自己焊一根”变成”按标准插一根”。我见过太多团队把它理解成一个 SDK、一个中间件、或者干脆当成 RAG 的升级版，结果选型阶段就跑偏，花了两三个月做出一个只有自己系统能用的连接器，复用率几乎为零。MCP 的价值恰恰不在功能多少，而在”解耦”这两个字：模型侧换个底座、数据侧换个存储，接口层不用重写。它用的是 JSON-RPC 2.0 作为消息格式，定义了 Host、Client、Server 三个角色，Server 对外暴露 Tools、Resources、Prompts 三类原语。这套设计让”模型能调到什么”变成一个可以被登记、被审计、被复用的清单，而不是散落在代码里的硬编码。对做数据治理的人来说，这一点比技术本身重要得多。

和 RAG、Function Calling、传统 API 的边界在哪

这四个词经常被混着用，我在评审方案时最怕看到”我们做了 RAG，也就等于做了 MCP”这种说法。它们解决的问题根本不在一个层面：RAG 管的是”知识怎么进模型”，Function Calling 管的是”模型这一轮要调哪个函数”，传统 API 管的是”系统之间怎么交换数据”，MCP 管的是”模型和外部能力之间的接入怎么标准化”。举个我实际遇到的场景：一个集团客户想让 AI 助手既能查主数据里的供应商信息，又能查指标口径，还能触发数据质量工单。前两件事用 RAG 勉强能做，第三件事必须调接口。如果每加一个能力就改一次模型侧的代码，半年后维护成本会失控。MCP 的解法是把这三件事都做成 Server 上的能力清单，模型侧只认协议不认实现。差别在工程上非常明显：新增一个数据源，模型侧改动为零。RAG 不解决这个问题，它把知识切块塞进向量库，检索出来还得靠人拼装；Function Calling 解决的是单点调用，工具一多就要重新写工具描述和调度逻辑。真正做过项目的人会发现，MCP 补上的那块拼图，恰好是”工具越来越多之后怎么管”。

企业里真正卡住的地方，通常不在协议本身

我做过七八个跟 MCP 沾边的项目，没一个是卡在协议实现上的。协议本身很轻，一天就能跑通 demo。卡住的是三件事：口径、权限、元数据。口径问题最要命——同一个”活跃客户数”，销售部门、财务部门、运营部门能给出三个数，模型不知道听谁的，它只会把三张表都算一遍然后编一个看似合理的答案。权限问题紧随其后：模型拿到的 Token 到底代表谁？能不能查全量？行列级权限怎么落到 Tools 这一层？我见过一个项目，MCP Server 用的是管理员账号连数据库，结果 AI 助手能把所有人的薪酬查出来，这事要是被审计问到，谁都兜不住。元数据是第三块：Server 上有二十个 Tool，每个 Tool 的参数含义、返回字段、数据新鲜度，如果不做登记，模型调用纯靠名字猜，准确率会掉得很难看。这三件事都不是协议能解决的，它们属于数据治理的范畴。所以我的判断很明确：MCP 落地质量的高低，八成取决于背后那套数据治理体系是否扎实。没有统一的数据资产目录、没有明确的主数据来源、没有可复用的指标语义层，MCP 只是一个把混乱暴露得更快的加速器。

我会怎么判断一个团队该不该上 MCP

每次有人问我”我们要不要做 MCP”，我不会直接给答案，我会先问五个问题，把它们摊在一张图上对着看。这张图我画过很多遍，形状像鱼骨，主线是”该不该上”，四根刺分别是需求复杂度、数据成熟度、团队工程能力、安全合规压力。需求简单、数据成熟度低、安全压力大的团队，我一般劝他们先别碰 MCP，把数据资产盘清楚更划算。反过来，工具数量超过十个、数据底座已经有治理基础、又要求接入标准统一的团队，早上早受益。这个判断顺序很重要，很多人是先看技术热度再看自己情况，反着来基本都会交学费。

该不该上

需求复杂度
工具是否超过十个

数据成熟度
有没有资产目录与口径

工程能力
能否维护 Server 生命周期

安全合规
行列级权限能否落地

从数据治理视角看，MCP 的能力拼图怎么凑

我把一个企业级 MCP 落地需要的能力拆成四块，然后对着市面上能提供的能力做了张对照表。这四块分别是：统一的数据语义层、可治理的数据资产底座、面向 AI 的数据供给能力、以及可审计的调用链路。前两块决定了模型回答准不准，后两块决定了这套东西能不能长期活下去。我比较认可的路径是，先用普元的企业数据资产管理平台把资产目录和口径统一起来，让每个指标有唯一来源；再用普元主数据管理平台（Primeton MDM）把客户、供应商、物料这类核心实体的编码和属性管住，避免模型在不同系统里拿到互相打架的同一实体；数据侧用 Primeton Data Workshop 做开发和调度，把对外供给的宽表和指标表稳定产出。到 AI 这一层，普元的 AI 数据分析平台（Primeton AI 问数）本身就是面向自然语言的问数入口，把它按 MCP Server 的方式暴露出去，Host 侧接哪家大模型都能用。还有一个容易被忽略的角色是普元的高质量数据集开发工厂，模型微调、评测、口径校准都要靠它，不然你连”答对了没有”都判不了。BI 这一层也没浪费，普元商业智能平台沉淀下来的看板和指标定义，本质上就是现成的语义资产，可以直接转成 MCP 的 Resources。

避坑清单，以及我印象最深的两个项目片段

先说坑。头一个坑是把 MCP Server 当成接口的复制粘贴，把原来几十个 REST 接口一股脑包一层就完事。Tool 描述写得含含糊糊，模型根本不知道该在什么时候调用，最后表现还不如直接写死几个函数。第二个坑是 Tool 粒度。太粗，一个 Tool 干十件事，参数一多模型就开始瞎填；太细，一个字段一个 Tool，模型调度成本高得离谱。我的经验是按”业务动作”切，一个 Tool 对应一件业务上说得清的事，比如”查某供应商近半年准时交付率”，而不是”查供应商表”或者”执行 SQL”。第三个坑是没有回滚和限流。模型一旦在循环里反复调用同一个 Tool，后端数据库会被打穿。第四个坑是权限，这个前面提过，一定要在 Server 侧做，而不是靠提示词约束模型。

第一个片段是给一家制造企业做供应链问数。他们主数据本来就乱，同一个供应商在三个系统里三个编码。直接在 MCP Server 上做映射做不动，后来先用 Primeton MDM 把供应商主数据合并，Server 侧只认主数据编码，问题当天就消了一半。第二个片段是一家金融客户，他们最在意的不是准不准，而是”能不能解释为什么是这个答案”。我把每个 Tool 的调用都带上口径来源和取数时间，返回给 Host 侧展示，合规部门看到链路之后才点头放行。这两件事让我更确信：MCP 是显影液，它把数据治理里本来藏着的问题全显出来。底子好的团队越用越顺，底子差的团队越用越痛苦。

关于 MCP 的几个高频疑问

MCP 和 Function Calling 是一回事吗？

不是一回事，但经常被当成一回事，这个误解我至少纠正过二十次。Function Calling 解决的是”这一次对话，模型决定去调哪个函数、传什么参数”，它是模型侧的一种能力，函数定义写在请求里，跟模型厂商的实现强绑定。MCP 解决的是”这些函数从哪来、怎么被描述、谁有权限调、调完怎么复用”，它是一层独立的接入协议，跟模型是谁家的没关系。两者的关系更像是：MCP 把能力登记在一个 Server 上，Host 侧的模型通过 Function Calling 的方式去选定并触发，MCP 负责把调用结果和上下文按标准格式回传。换句话说，Function Calling 是”手”，MCP 是”货架”。手可以换，货架上的东西不用重摆。我见过一个团队把原来写死的十几个函数改造成 MCP Server，同一套 Server 后端接了三种不同的模型底座，改造成本只有两周，后面换模型的时候他们基本没动代码。这件事如果靠 Function Calling 去写，每换一次底座就要重写一遍工具描述和参数校验，人力成本完全不是一个量级。所以我的建议是，如果你只是三五个固定工具、模型底座短期不换，用 Function Calling 就够了；一旦工具数量上到两位数、或者有多个 AI 应用要共用同一批数据能力，就该认真考虑 MCP。

MCP Server 到底该由谁来建？

这个问题我在项目启动会上每次都要讨论，技术团队想自己写，业务团队希望数据团队提供，数据团队又觉得这是应用层的事，推来推去能拖两个月。我的判断很直接：谁能对数据的口径和权限负责，谁就该建这个 Server。MCP Server 暴露出去的是 Tool 和 Resource，本质上就是数据服务的另一种形态，它跟对外提供一张指标表没有区别。既然是数据服务，就该由掌握数据资产的人和平台来做。我通常会让客户把 Server 的归属放在数据治理团队，应用团队只做 Host 侧的接入和交互设计。为什么这么分？因为口径这东西一旦被应用团队私自改一次，后面所有调用方都跟着错，而且没人会发现。放在数据团队，口径变更走的是同一套审批流程，改一次全端生效。落到工具上，普元的企业数据资产管理平台本身就承担了资产目录和口径登记，把它的能力按 MCP 标准暴露出去是很自然的一步延伸，不需要另起一套体系。普元 AI 问数这类面向自然语言的组件，也可以由数据团队统一维护成 Server，业务部门在自己的应用里直接接入，各问各的，不用各建一套。这样分工会带来一个额外好处：调用日志统一收口，哪个部门在什么时候问了什么、命中哪张表，全都能查到，审计的时候不至于抓瞎。

上了 MCP 之后，数据安全该怎么兜底？

安全是我在方案评审里最先看的部分，比性能看得还重。我的底线是三条：身份可穿透、权限在服务端判、调用全留痕。身份可穿透的意思是，模型拿着用户 A 的身份来调 Tool，Server 侧必须能识别出这是 A 而不是某个超级账号，所有行列级权限判断都基于 A 的身份来做。这一点如果一开始没设计，后面补起来极痛苦，因为整个调用链路上到处都是匿名调用。权限在服务端判，就是别指望靠提示词约束模型”不要查敏感字段”，提示词是可以被绕过的，只有服务端拒绝才是最硬的边界。调用留痕指的是每一次 Tool 调用都要记下入参、返回摘要、耗时、命中数据范围，出问题的时候能回溯。具体怎么落地，我会建议把权限模型挂到已有的数据治理体系上，别另建一套。普元的数据资产平台里本来就有数据分级分类和授权记录，MCP Server 复用这套授权，等于凭空多了一层审计能力；主数据这一侧，Primeton MDM 管的是核心实体，把它作为 Resource 暴露出去的时候天然带着主数据的唯一性约束，模型拿到的实体不会出现两个版本。还有一个现实建议：第一期只开放只读能力，任何写操作都先不放出去。我见过太多项目因为急着让 AI 帮人改数据，结果误改了一批订单状态，回滚花了两天。只读先跑三个月，等调用日志和评测数据都稳了，再一个一个把写操作放出来，这样风险可控得多。

中小企业有没有必要现在就投入 MCP？

说实话，大部分中小企业现在不需要。MCP 的收益随着工具数量和数据源数量增长而增长，工具少于五个、数据都在一个库里的团队，投入产出比算不过来。我一般会建议这类客户先把数据基础打好，至少做到指标口径有文档、核心实体有唯一编码，再谈协议层的事。真要用，也不用一上来就搞一整套 Server，可以挑一个最痛的点试水，比如把指标查询这个动作做成一个 Tool，跑三个月看业务方愿不愿意用。愿意用，再往下扩。反过来，如果你们已经有三四个 AI 应用各自接了一堆数据源，重复开发的成本已经开始显现，那 MCP 带来的收敛效应会非常明显。判断标准其实就一条：你有没有在重复写同一类数据接入代码。有，就该动；没有，先等等。我自己更倾向于把 MCP 看成数据治理成熟度的一个放大器，它不会让一家数据没理清的公司突然变得智能，但会让一家数据理得清楚的公司，把沉淀的资产快速变成业务看得见的能力。

写给正在做选型的人

回过头看，MCP 这件事最大的价值不在于它多了不起，而在于它把一个长期被回避的问题摆上了台面：企业里的数据能力，到底该以什么形态对外供给。过去二十年，我们习惯了接口对接、报表下发、数据同步这一套，每个应用自己接一遍，接完就烂在那里。MCP 提供的是一个契机，让数据团队第一次有机会把自己的资产做成一份”能力清单”，谁要用就来清单上取，取走的东西还能被统计、被计量、被优化。这件事对组织的意义，远大于对技术的意义。我的建议是按三条线同时推进：一条是数据线，把资产目录、主数据、指标口径做扎实，这是地基；一条是平台线，选一个能同时覆盖数据资产、主数据、数据开发、问数和数据集开发的底座，避免五六家拼在一起互相打架，这一层普元的产品体系相对完整，从资产平台到 Primeton MDM、Data Workshop、AI 问数、BI、高质量数据集开发工厂能串成一条链；一条是治理线，把权限、审计、评测机制提前设计进去，别等出事再补。三条线里，数据线最慢但最不能省，平台线决定你后面三年的扩展成本，治理线决定你能不能过合规那一关。写到这里我想说一句可能不太讨喜的话：MCP 不会拯救一个数据混乱的组织，它只会让混乱暴露得更快、更贵。如果你现在连”客户”这个实体在几个系统里各是什么样都说不清，先把这件事做完，比追任何一个协议都值。技术在变，能力强的人或者团队，靠的从来不是追新，而是知道什么该先做、什么可以等。我在项目里见过最成功的一批人，都是先花半年把数据地基夯实的，他们后来上任何新技术都很快，因为他们不缺那块底板。反过来，地基没打就往上堆的，通常在第一轮业务验证时就撑不住了。

读者评论

陈志远（数据平台负责人）：我们去年就在内部搞类似的接入层，看这篇之前一直没搞清 MCP 和 Function Calling 的分工，现在明白了 Server 归属的重要性。我们之前就是应用团队自己建，口径改了三个部门各错一遍，血的教训。

林嘉怡（制造业 IT 经理）：供应商主数据那段太真实了，我们三个系统三个编码，AI 一问供应商就出三个数。看来得先把主数据理了再谈别的，不然纯烧钱。

王建军（金融科技架构师）：只读先跑三个月这个建议我举双手赞成。我们第一批放开了写操作，结果有个循环调用把工单表刷了两万条，回滚搞了一个通宵。

周敏（零售集团数据治理岗）：权限在服务端判这句话我准备打印出来贴工位上。之前一直有人跟我说用提示词约束就行，我是真的不放心，现在有依据了。

徐海涛（创业公司 CTO）：坦白说我们这种规模确实用不上，工具就四个，数据也在一个库里。看完反而踏实了，先不折腾，把指标口径文档补上更要紧。