Azure DAB 数据库 API 与 SQL MCP 工具

要解决的问题

让 AI Agent 访问数据库的常见做法是给它连接字符串和凭据，但这样等于把整个数据库的读写能力直接交出去。权限无从收敛、SQL 可以自由拼写、哪张表能被哪些 Agent 访问全靠约定——一旦 Agent 判断失误或用户注入恶意请求，后果直接作用在数据层。

这个技能的思路是：不让 Agent 直连数据库，而是先通过 Azure Data API Builder（DAB）生成一组有 schema 约束、有角色权限的 API，再把 SQL 访问封装成 MCP 工具暴露给 Agent。

技能如何工作

• 用 DAB CLI 配合一份 JSON 配置文件定义 data-source、runtime 和 schema：哪些表对外可见、每个角色允许哪些操作（如 select / insert）。
• 对受支持的数据库启动 DAB 服务后，同一套配置会生成三种访问面：REST 端点、GraphQL 端点，以及 SQL MCP 工具。
• MCP 兼容的 Agent 客户端通过工具调用完成查询或写入，权限判定由 DAB 按角色执行，数据库账号本身可以保持最小权限。
• Agent 拿到的不再是凭据，而是一组有边界的工具：能做什么、能看什么表，都在配置里写死。

适用边界与注意点

• 需要 .NET 8 及以上运行时，配置文件的编写和维护是绕不开的成本，大型库中要先梳理清楚需要暴露的表集合。
• SQL MCP 工具保留了即席查询的灵活性，也意味着 DAB 无法拦截语义层面的误操作，比如 DELETE 缺少条件；这类防护仍需在业务层处理。
• GraphQL 端点同样缺少深度和复杂度限制，嵌套查询可能放大查询成本。
• 静态 API key 仅适合本地与测试，生产环境建议接入 Azure AD 或 OAuth。