1. 为什么 AI 直连数据库这件事必须先把链路管起来MCP 协议这两年被讨论得很多但真正落到“AI 安全调用数据库”这个场景问题往往不在模型聪不聪明而在链路有没有被约束住。我见过太多团队的做法是在本地 AI 工具里塞一个数据库连接串让模型直接跑 SQL。跑通是跑通了可一旦模型生成了一条UPDATE或者DELETE你连它什么时候执行的都不知道。MCPModel Context Protocol解决的正是这个“调用入口”问题。它把数据库操作封装成一组标准工具AI 客户端不直接碰数据库而是通过 MCP Server 转发请求。Server 这一层可以做参数校验、访问控制、SQL 类型白名单数据库账号本身还能再收一道权限。两层约束叠起来AI 才算是被套上了缰绳。这篇要交付的东西很具体在 TaoToken 统一 Key 和 API 通道的前提下给出一份可复制的 MCP 配置骨架覆盖config.toml和settings.json两种客户端形态再补上权限最小化、连接验证和查询审计的动作。适合正在用 Cursor、TRAE 这类支持 MCP 的工具、又想把数据库调用纳入可控范围的开发者。读完你能拿到一套能直接改参数就用的配置而不是又一篇概念科普。需要先说明一点TaoToken 在这里的角色是统一的模型调用入口。MCP Server 负责数据库侧的工具暴露TaoToken 负责模型侧的 Key 和通道管理两者职责分开配置也分开写这样排查问题时不会互相干扰。2. TaoToken 前置统一 Key 与 MCP 的分工边界2.1 两套配置不要混在一起很多人第一次配 MCP 会犯一个错把模型 API Key 和数据库连接信息写在同一个配置文件里。结果换模型要动数据库配置调数据库权限又怕影响模型调用。正确的做法是分层模型侧走 TaoToken 的统一 Key所有 AI 客户端Cursor、TRAE、Claude Code 等共用同一个入口Key 只在 TaoToken 控制台管理。数据库侧走 MCP Server 自己的配置连接串、访问模式、账号权限都在 MCP 配置里。两边通过 MCP 客户端的启动命令关联起来但配置项互不嵌套。TaoToken 的 API 地址是https://taotoken.net/api这个地址填在 AI 客户端的模型配置里不是填在 MCP Server 里。MCP Server 只认数据库连接参数。这个边界先划清楚后面配置才不会乱。2.2 拿 Key 和确认通道先去 TaoToken 控制台创建 API Key。控制台地址是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_configKey 的管理页面在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_config。创建时建议按用途命名比如cursor-mcp-db方便后面审计时对得上。如果你用的是 Claude Code 这类偏编码场景的工具模型通道可以走 Coding Plan入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_config。这一步只是把模型调用通道准备好数据库那边还没开始配。注意TaoToken 的 Key 只用于模型调用不要把它写进 MCP Server 的数据库配置里。两者混用会导致权限边界模糊出问题时很难定位是哪一层放行的。2.3 数据库侧的准备动作在配 MCP 之前先在数据库里建一个 AI 专用账号。这个账号的原则是只给需要用的库和表的读权限写权限默认不给。如果确实需要 AI 执行某些写操作单独开一个受限账号不要和读账号混用。以常见的 SQL 数据库为例建账号时把权限收窄到具体 schema-- 创建 AI 专用只读账号 CREATE USER ai_mcp_reader WITH PASSWORD 换成强密码; GRANT CONNECT ON DATABASE your_db TO ai_mcp_reader; GRANT USAGE ON SCHEMA public TO ai_mcp_reader; GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_mcp_reader; -- 后续新建的表也要授权 ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO ai_mcp_reader;这个账号就是 MCP Server 连接数据库时用的身份。模型能看到的对象、能执行的 SQL最终都受这个账号的权限约束。MCP Server 的 Restricted 模式是第二道闸数据库账号权限是第一道闸两道都要有。3. 可复制配置config.toml 与 settings.json 骨架3.1 MCP Server 的 config.toml 骨架不同 MCP Server 的配置字段会有差异下面这份骨架以“数据库 MCP Server Stdio 传输”为模板字段名按你实际用的 Server 文档微调。核心结构是连接参数、访问模式、传输方式三块。# config.toml - MCP Server 数据库连接配置骨架 [mcp] # 传输方式本地开发用 stdio团队共享用 streamable_http transport stdio # 访问模式restricted 只允许白名单 SQLunrestricted 开放完整权限 access_mode restricted [database] # 数据库类型按实际填写 type postgresql host 127.0.0.1 port 5432 database your_db # 使用上一步创建的 AI 专用只读账号 user ai_mcp_reader password ${DB_PASSWORD} # 从环境变量读取不要明文写死 # 连接池上限避免 AI 并发查询打满数据库 max_connections 5 # 单条查询超时单位秒 query_timeout 30 [security] # Restricted 模式下的 SQL 白名单只放行查询类语句 allowed_sql_types [SELECT, EXPLAIN, SHOW] # 禁止访问的系统表 blocked_schemas [pg_catalog, information_schema] # 单次返回行数上限防止大结果集拖垮客户端 max_rows 1000 [audit] # 审计日志输出路径 log_path ./logs/mcp_db_audit.log # 记录完整 SQL 还是只记录摘要 log_full_sql true几个字段值得单独说。access_mode设成restricted后Server 会按allowed_sql_types做白名单拦截UPDATE、DELETE、DROP这类语句在到达数据库之前就被挡掉。max_rows和query_timeout是防呆用的模型有时候会生成SELECT *不带LIMIT没有这两个限制一次查询就能把客户端卡住。password用${DB_PASSWORD}这种环境变量占位实际运行时由启动脚本注入。明文密码写进配置文件再提交到仓库是数据库泄露最常见的入口之一。3.2 客户端 settings.json 骨架AI 客户端这边要配两件事模型走 TaoTokenMCP Server 走本地启动命令。以支持 MCP 的编辑器为例settings.json结构大致如下{ models: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: ${TAOTOKEN_API_KEY}, model: claude-sonnet-4-20250514 }, mcpServers: { db-mcp: { command: uv, args: [ run, kingbase-mcp, --access-mode, restricted, --config, ./config.toml ], env: { DB_PASSWORD: ${DB_PASSWORD} } } } }这里base_url填 TaoToken 的 API 地址api_key从环境变量读。mcpServers下面的db-mcp是自定义名字客户端里显示的工具列表会挂在这个名字下。command和args按你实际用的 MCP Server 启动方式改上面用的是uv run的形态。提示env里只放 MCP Server 需要的环境变量不要把 TaoToken 的 Key 也塞进来。模型 Key 由客户端自己的模型配置管理MCP Server 不需要知道它。3.3 权限最小化的三个动作配置写完只是骨架真正让链路安全的是这三个动作。第一个动作数据库账号只给SELECT。上面建账号的 SQL 已经体现了但要注意ALTER DEFAULT PRIVILEGES那行否则后续新建的表 AI 账号读不到你会以为是 MCP 配置问题其实是权限没跟上。第二个动作MCP Server 开restricted模式。这个模式下即使模型生成了写语句也会被 Server 拦下。测试环境如果确实需要放开单独开一个unrestricted的 Server 实例不要在生产配置上改。第三个动作审计日志必须开。log_full_sql true会记录每一条到达数据库的 SQL包括时间、账号、语句内容。出问题时这份日志是唯一能还原现场的东西。4. 验证请求从连接测试到一次完整查询4.1 先验证 MCP Server 能连上数据库配置写完后不要急着在 AI 客户端里提问先在命令行单独跑一次 MCP Server确认它能连上数据库。用 Stdio 方式启动时Server 会等待客户端输入你可以手动发一条初始化请求测试# 启动 MCP Server观察启动日志 uv run kingbase-mcp --access-mode restricted --config ./config.toml # 正常启动会输出类似 # [INFO] MCP server started, transportstdio # [INFO] Database connection established: your_db127.0.0.1:5432 # [INFO] Access mode: restricted, allowed_sql_types[SELECT, EXPLAIN, SHOW]如果卡在Database connection established之前多半是连接参数或账号权限问题。先确认ai_mcp_reader能单独登录数据库再回来查 MCP 配置。4.2 在客户端里验证模型通道模型通道的验证走 TaoToken 的模型对话入口地址是https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_config。在里面发一条简单请求确认 Key 和通道正常。这一步和数据库无关只是排除模型侧的问题。如果模型对话正常但客户端里 MCP 工具调不通问题就在 MCP 配置或数据库权限不在 TaoToken。这个排查顺序能帮你快速定位故障层。4.3 一次完整的查询验证在 AI 客户端里输入一个具体问题比如“列出 orders 表的字段和索引”。正常流程是客户端判断需要调用 MCP 工具向db-mcp发请求MCP Server 收到请求后按restricted模式检查 SQL 类型确认是SELECT或结构查询后放行数据库返回结果Server 记录审计日志再把结果回传给客户端模型基于真实结果整理回答。验证成功的标志有三个客户端能返回表结构信息./logs/mcp_db_audit.log里出现对应的查询记录数据库侧用ai_mcp_reader账号能看到这次连接。# 查看审计日志确认查询被记录 tail -f ./logs/mcp_db_audit.log # 输出示例 # 2025-01-15T10:23:41Z | userai_mcp_reader | typeSELECT | rows12 | sqlSELECT column_name, data_type FROM information_schema.columns WHERE table_nameorders4.4 验证拦截是否生效安全配置最怕的是“以为生效了其实没有”。主动测一次拦截在客户端里让模型执行一条写语句比如“删除 orders 表里 status 为 cancelled 的记录”。如果restricted模式生效MCP Server 会拒绝这条请求客户端会收到类似SQL type DELETE is not allowed in restricted mode的报错数据库里数据不变。这个测试做完你才能确认白名单真的在拦。如果写语句被执行了说明access_mode没生效或者配置没被加载要回去检查启动参数和配置文件路径。5. 本篇常见错排查5.1 MCP Server 启动报配置解析失败最常见的原因是config.toml字段名和 Server 实际要求的不一致。不同 MCP Server 的字段命名差异很大有的用access_mode有的用accessMode有的放在[server]段下。解决办法是拿你实际用的 Server 的 README 对照不要直接套用模板字段名。另一个原因是 TOML 语法错误比如字符串没加引号、数组写成[SELECT, EXPLAIN,]多了个逗号。用toml校验工具过一遍能快速定位。5.2 客户端里看不到 MCP 工具先确认settings.json里mcpServers的command在系统 PATH 里能找到。uv如果没装或者路径不对客户端启动 MCP Server 时会静默失败。在命令行里手动跑一遍command加args能跑通再回客户端看。如果命令行能跑通但客户端看不到工具检查客户端是否需要重启。多数编辑器加载 MCP 配置是在启动时改完settings.json要重启才生效。5.3 查询被拦截但不知道拦在哪一层拦截可能发生在三个地方MCP Server 的 SQL 白名单、数据库账号权限、数据库自身的行级安全策略。排查顺序是从外到内先看 MCP Server 日志有没有拒绝记录有就是白名单拦的没有的话看数据库日志如果是权限错误就是账号权限问题两者都没有但查询失败再查数据库自身的策略。审计日志在这里很关键。log_full_sql true时被拦截的 SQL 也会记录你能看到它是在哪一步被挡下的。5.4 模型通道报 401 或 403这类错误和 MCP 无关是 TaoToken 的 Key 问题。检查settings.json里api_key引用的环境变量有没有正确注入Key 有没有过期或被删除。模型对话入口能正常用的话说明 Key 本身没问题那就是客户端读取环境变量的方式不对比如用了${TAOTOKEN_API_KEY}但实际没导出这个变量。5.5 查询超时或返回行数被截断query_timeout和max_rows设得太小会导致正常查询被误伤。如果业务查询确实需要更大范围调这两个参数但不要直接去掉限制。更好的做法是给不同用途配不同的 MCP Server 实例分析类查询用一个宽松配置日常查询用严格配置。6. 把链路固定下来再谈扩展配置跑通之后建议把config.toml和settings.json纳入版本管理但密码和 Key 用环境变量占位实际值放在本地.env或密钥管理服务里。这样团队里其他人拉下来改一下环境变量就能用不会因为配置文件里写死了某台机器的连接串而互相冲突。审计日志要定期看尤其是刚接入 AI 调用的头两周。你会从日志里发现模型实际在查什么、有没有生成意料之外的 SQL。这份日志也是后面调整白名单和权限的依据。如果后面要扩展到多个数据库或者多个 AI 客户端MCP Server 可以按库拆成多个实例每个实例用独立的数据库账号和访问模式。TaoToken 这边统一 Key 不变客户端配置里加一个mcpServers条目就行。模型通道和数据库通道分开管理的好处到扩展阶段会体现得很明显。需要再确认模型通道或 Key 配置的话模型对话入口在https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_config接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmcp_db_config。数据库侧的配置以你实际用的 MCP Server 文档为准上面这份骨架改字段名就能套。