MCP 服务器：当 AI 接入你的数据栈
数据工程师花了几十年时间，解决如何把数据可靠地送达使用方：管道、Schema、访问控制，一个都不能少。而现在，AI 代理（Agent）成了一种全新的使用方——它不跑查询，而是调用函数；不拉数据行，而是读取上下文；它要的是自然语言答案，而不是 JSON 响应。模型上下文协议（MCP，Model Context Protocol）正是让这种交互方式变得明确的新兴标准。
这篇文章要讲清楚三件事：MCP 服务器到底是什么、如何融入生产环境的数据栈、以及数据工程师要构建一个 MCP 服务器需要知道什么。这里不讨论机器学习特征存储或模型服务基础设施——那是另一个话题，而且已经有很多文章讲过了。MCP 涉及的是更底层的东西：AI 代理如何发现并调用服务器暴露的工具，以及你作为数据工程师，如何定义这个接口。
MCP 是什么（以及不是什么）
模型上下文协议由 Anthropic 提出，现已在整个 AI 工具生态中被广泛采纳。它定义了 AI 代理（称为 MCP 客户端）如何连接外部工具和数据源（称为 MCP 服务器）。需要注意的是，MCP 服务器并不是模型服务层——它不跑推理、不管理特征向量，也不位于数据仓库和训练管道之间。它的角色是暴露工具：AI 代理可以发现并调用的类型化函数；此外还可以提供资源（代理可读取但不可修改的上下文数据）和提示词模板（常见操作的复用模板）。
你可以把它理解成一种 AI 代理天生就能读懂的 API 规范。当 Claude Code 或 Codex 这类 MCP 客户端打开一个项目时，它会读取项目根目录下的 .mcp.json 注册文件，发现其中列出的 MCP 服务器，然后把服务器上的工具当作原生能力直接使用。比如，你在 MCP 服务器上定义了一个 query_warehouse 工具，Claude 就能直接调用它——不需要专门设计系统提示词，不用写解析逻辑，客户端那边也不用装任何自定义插件。
客户端与服务器之间的契约由服务器的工具模式（tool schema）定义：每个工具都有名称、描述和类型化的输入模式（JSON Schema）。客户端发送结构化的工具调用，参数与模式匹配；服务器验证参数、执行操作、返回类型化结果。这一来一回就是应用层的全部协议——其余部分（传输、版本控制、能力协商）都由 SDK 处理。
为什么这对数据工程师很重要
大多数关于 MCP 的讨论都是从模型侧出发的——AI 产品如何为 MCP 服务器添加支持、有哪些客户端可用、哪些平台采纳了这个标准。这种叙事把数据工程师当作被动的一方：他们的系统只是 AI 最终要接入的对象，等 AI 腾出手来再说。
更有用的框架是：MCP 服务器是你主动构建的基础设施，用来向 AI 代理开放你的数据栈，控制力和可观测性与对待任何其他接口一视同仁。开放哪些操作由你决定，模式由你编写，验证、访问控制、错误处理也由你实现。是 AI 代理调用你的接口——而不是反过来。
这个区别很重要，因为你早已掌握的数据工程方法论可以直接套用：模式契约、版本控制、访问控制、审计日志、缓存——当使用方变成 AI 时，这些东西一个都不会消失，反而变得更加重要。因为一个定义含糊的接口，暴露出来的是 AI 幻觉或意外行为，这比一次失败的 API 调用难排查得多。
数据栈 MCP 服务器的实际形态
用于数据工程工作的 MCP 服务器，具体形态通常包含少量工具，每个工具对应一个适合 AI 使用方执行的操作。以下是几个真实使用中的例子：
run_query 工具：接受自然语言问题或结构化查询规范，将其转换为 SQL（或执行预定义的参数化查询），并以结构化 JSON 返回结果。AI 代理调用它来回答关于数据的事实性问题，无需直接访问数仓。
get_schema 工具返回某个表或一组表的模式信息——列名、类型、描述。AI 智能体要写出正确的 SQL 或理解数据结构，靠的正是这些上下文。把它做成显式的工具调用，比塞进系统提示词里可靠得多。
list_recent_events 工具返回某个实体或时间范围内事件流的最新 N 行数据。监控或调试用的智能体可以直接调用它来了解系统里发生了什么，而不必从头编写查询。
每个工具都有明确的输入模式，约束 AI 能传什么参数；有校验层，在任何数据库操作执行之前强制检查这些约束；还有 AI 可以直接解析的结果结构。细粒度的访问规则——比如工具能接触哪些表、暴露哪些列——都写在服务器实现里，而不是写在给 AI 的指令中。这才是它们该待的地方：在接口边界强制执行，而不是靠提示词来协商。
.mcp.json 约定
注册机制本身很简单。项目根目录下的 .mcp.json 文件，会告诉所有兼容 MCP 的客户端该连接哪些服务器、如何启动它们。这个文件只属于当前项目，默认被 gitignore 忽略，所以凭据和路径都留在本机，永远不会提交进仓库。
{
"mcpServers": {
"data-stack": {
"command": "python",
"args": ["-m", "my_mcp_server"],
"env": {
"WAREHOUSE_URL": "${WAREHOUSE_URL}"
}
}
}
}
当 Claude Code 打开这个项目时，它会读取该文件，以子进程方式启动服务器，通过 MCP 的能力协商握手发现工具，然后将它们提供给 AI 使用。同一个文件对 Codex 同样有效——我们直接验证过：Claude Code 在打开项目时读取的 .mcp.json，和 Codex 读取的是同一个文件，不需要针对每个客户端单独配置。一个文件，通吃所有智能体。
服务器本身可以用任何提供 MCP SDK 的语言来编写，Python 和 TypeScript 是最成熟的选择。SDK 负责处理传输层（stdio 或 HTTP/SSE）、能力协商以及工具调用的分发循环，你只需实现具体的工具处理函数。
把 MCP 融入现有技术栈
对大多数数据工程师来说，实际问题不是要不要采用 MCP——你的组织里已经有智能体在调用 API、问数据相关问题、往数据仓库里写查询，只是准确度参差不齐。真正的问题是：这类行为有没有一个明确的、受控的接口，还是说只是隐式地发生。
MCP 服务器让这个接口变得显式化。由你来决定暴露哪些操作，由你来定义契约，由你来实现可观测性——每一次工具调用都能记录输入、输出、执行时间和调用方的智能体，让你获得和任何生产级 API 一样的审计轨迹。当 AI 智能体参与数据管道决策时，这种可追溯性就非常关键：你要知道它调用了哪个工具、传了什么参数、返回了什么结果。
MCP 与现有数据工程工具的契合非常直接。MCP 服务器可以从你的智能体目前能访问的任何来源读取数据：Snowflake 或 BigQuery 数据仓库、dbt 加工好的数据集市、Redshift 集群、S3 里的 Parquet 文件。它不会取代这些系统，也不会替换为它们供数据的管道。它位于这些系统前面，暴露一个 AI 智能体知道如何使用的类型化接口。
它改变架构的位置在边界：AI 智能体不再直接查询你的数据仓库（或者拿着权限很宽的数据库凭据，盼着别搞坏什么），而是调用你的 MCP 服务器，由服务器强制执行契约。这是一个很熟悉的模式，设计良好的数据 API 从来都是这么做的。MCP 让这种模式在 AI 工具生态中变得原生。
快速上手
门槛最低的切入方式是挑一个高价值、范围明确的操作——比如团队经常跑的查询、智能体目前总做不好的表结构检查、总是返回错误结果的数据查询——把它封装成一个 MCP 工具。先把整条链路跑通：在 .mcp.json 里注册好，能从 Claude 或 Codex 调用，返回结构化输出。然后再从这里开始逐步增加工具。
Anthropic SDK 文档里详细写了 MCP 服务器的实现方式和工具 schema 格式。我们在 Labyrinth Analytics 自己构建的 LoreConvo 和 LoreDocs——分别承担会话记忆和知识库功能——也都是 MCP 服务器。如果你想看生产环境下的 schema 长什么样，可以直接去翻这两个工具的工具注册部分，都是现成的实际例子。
如果你正在思考 MCP 怎么适配你们的技术栈，欢迎来找我聊，我很乐意一起把接口设计捋清楚。想从使用者角度体验 MCP 原生工具是什么样的，去 /tools 看看就行。