Agent 用的 MCP Server 怎么设计？把内部数据平台封装成 MCP 要注意什么？
面试怎么回答
我会先选高频、低风险的场景暴露，比如查元数据、按口径查指标、查任务状态，而不是开放任意 SQL。工具按场景设计，描述写清用途和口径；Server 以调用者本人身份访问后端，权限照常生效；只读优先，写操作单独成工具，需要确认和幂等键；返回结果限制行数和字段，大结果给摘要。扫描量、超时、脱敏这类护栏都放在 Server 里强制执行。上线后做审计、版本兼容、独立资源队列和调用监控，根据误用情况持续调整工具设计。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
MCP（Model Context Protocol）已经成了 Agent 连接外部系统的通用方式。很多数据团队接到的需求是：把数据平台（数仓查询、指标、元数据、调度）封装成 MCP Server，让公司里的各种 AI 助手都能用。面试官想看的是你能不能把一个内部系统设计成「好用又安全」的 MCP 服务。
先想清楚暴露什么
MCP Server 可以提供三类能力：
- Tools（工具）：模型可以调用的动作，比如「按指标查询」「查看任务运行状态」；
- Resources（资源）：可以被读取的上下文，比如表结构、指标定义文档；
- Prompts（提示模板）：预置的使用模板，比如「排查任务失败」的标准步骤。
数据平台不要把所有接口都暴露，先选高频、低风险、价值明确的场景：查元数据、按口径查指标、查任务状态和日志。
设计要点
- 工具粒度按场景：「查询指标 GMV，按渠道、按天」比「执行任意 SQL」更好用也更安全；
- 身份透传：Server 以调用者本人的身份访问后端，原有的库表、行列权限照常生效，而不是用一个大账号；
- 只读优先：写操作（重跑任务、改配置）单独成工具，需要人工确认，并带幂等键；
- 结果可控：限制返回行数和字段，大结果给摘要和下载链接，不把几万行数据塞进上下文；
- 描述即文档：每个工具写清用途、参数含义、口径说明和示例；
- 护栏放在服务端：扫描量、超时、LIMIT、敏感字段脱敏都在 Server 里强制执行，不依赖模型自觉。
运维和治理
- 审计：记录谁、通过哪个客户端、调用了什么工具、参数和返回行数；
- 版本管理：工具的名称和参数一旦被大量使用，改动要兼容，或者发新版本；
- 限流和隔离：AI 带来的查询放到独立资源队列，不影响生产任务；
- 监控：调用量、失败率、耗时、被拒绝的请求，以及哪些工具经常被误用。
常见的坑
- 直接把 OpenAPI 文档自动转成几百个工具，模型根本选不过来；
- 返回原始 JSON 太大，模型读不完也读不懂；
- 远程部署时鉴权没做好，任何拿到地址的人都能调用。