MCP 集成能力
数据墙DBW 内置了 MCP（Model Context Protocol，模型上下文协议）服务端能力，可以将数据库操作以 MCP 工具形式暴露给 AI 代理或 MCP 客户端。代理无需直接编写 SQL——它通过标准 MCP 工具与数据库交互，全程受权限配置约束。
MCP 是什么
MCP 是一项开放标准，定义了 AI 代理如何发现和调用外部工具。每个工具描述自己的输入、输出和行为。MCP 客户端（如 AI 应用、聊天机器人、IDE 插件）通过协议与 MCP 服务端通信，服务端提供工具列表、接收工具调用并返回结果。
数据墙DBW 中的 MCP
数据墙DBW 复用已有的实体模型和权限配置，自动将数据库能力生成为 MCP 工具。启用 MCP 后，引擎会暴露以下工具集：
| 工具 | 对应操作 |
|---|---|
describe_entities | 列出所有可访问实体及其字段和描述 |
read_records | 查询记录，支持筛选、排序、分页 |
create_record | 创建新记录 |
update_record | 更新已有记录 |
delete_record | 删除记录 |
execute_entity | 调用存储过程 |
aggregate_records | 执行聚合统计查询 |
代理通过 tools/list 发现可用工具，通过 tools/call 执行具体操作。整个过程由引擎的查询构造器生成确定性的 SQL，代理无需理解数据库 schema 细节。
安全模型
MCP 工具完全遵守数据墙DBW 的 RBAC 体系：
- 相同权限：MCP 与 REST、GraphQL 共享同一份角色和权限配置。你在实体上配置的权限自动适用于 MCP 调用。
- 角色感知：代理只能看到当前角色有权访问的实体和操作。未授权的实体不会出现在工具列表中。
- 字段过滤：权限配置中的字段限制同样作用于 MCP 查询。
- 行级策略：数据库策略对 MCP 读操作同样生效。
这意味着你不需要为 MCP 单独配置安全规则。REST、GraphQL、MCP 三者的权限策略天然一致。
确定性数据访问
许多数据库 MCP 方案采用 NL2SQL（自然语言转 SQL）方式，让模型直接生成 SQL 语句。这种方式存在不确定性——模型可能生成语法错误、不安全或不符预期的查询。
数据墙DBW 采用不同的策略（可称为 NL2DAB）：代理描述它想做什么，引擎通过内部查询构造器生成确定性的 SQL。这避免了 SQL 注入风险、语法错误和权限绕过，同时保持了代理交互的灵活性。
存储过程作为自定义工具
除了内置的通用 DML 工具外，你可以将存储过程注册为命名自定义 MCP 工具：
{
"entities": {
"GetBookById": {
"source": {
"type": "stored-procedure",
"object": "dbo.get_book_by_id"
},
"mcp": {
"custom-tool": true
},
"permissions": [
{ "role": "anonymous", "actions": ["execute"] }
]
}
}
}当 custom-tool 设为 true 时，该存储过程会作为一个独立命名的工具出现在 MCP 工具列表中。代理可以直接按名称调用，传递已声明类型的参数。这为复杂或参数化的数据库操作提供了更精确的暴露方式。
语义描述
MCP 场景中，AI 代理依赖实体的语义说明来理解数据含义。你可以通过以下方式增强代理理解能力：
- 在实体上设置
description，描述其业务含义。 - 在字段上设置
description，说明每个字段代表什么。 - 在存储过程参数上设置
description，指导代理正确传参。
这些描述会自动出现在 MCP 工具定义中，帮助代理做出更准确的数据访问决策。
双传输模式
数据墙DBW 的 MCP 支持两种传输方式：
- Streamable HTTP：适合标准 Web 部署，通过
/mcp端点提供服务。 - Stdio：适合本地开发和 CLI 工作流，直接通过标准输入输出通信。
两种模式共享同一套配置，无需额外适配。
显式设计边界
MCP 集成的设计中有两个明确的边界：
- 不支持 DDL：不支持建表、修改结构等数据定义操作。MCP 工具聚焦于数据操作（DML），这是生产环境中 AI 代理与数据库交互的推荐安全边界。
- 不支持原始 SQL：代理不能发送任意 SQL 语句。所有数据访问必须通过工具和实体模型，确保权限和权限策略始终生效。