MCP 解决的不是“更会聊天”

AI Agent 真正进入业务场景，需要访问模型之外的数据和工具。过去，每个 Agent 都要单独适配数据库、API 和认证方式；MCP 的价值是把这些能力变成可发现、可调用的标准接口。

但连接成功只证明 Agent 能看到工具，不代表它理解指标、拥有正确权限，或者会提出合理查询。一个可用的 MCP 工作流，必须同时处理工具语义、数据契约、权限、成本和结果复核。

先理解四个角色

可以用一个简单模型理解 MCP：

MCP 统一的是“如何发现和调用”，真正的数据口径、权限和业务规则仍由服务端负责。它不会替代数据契约，也不会把一个模糊问题自动变成可靠分析。

  • Host 是用户实际使用的 AI 应用，例如桌面客户端、IDE 或 Agent 平台。
  • Client 在 Host 内维护与 MCP Server 的连接。
  • Server 向 Agent 暴露经过定义的数据资源和工具。
  • Tool 是 Agent 可以调用的具体能力，例如描述数据集或查询指标。

用最小权限建立连接

在 AsKlear Dashboard 创建 API Key，并使用 Dashboard 生成的 MCP 地址与配置。密钥应该保存在客户端的凭证或环境变量配置中，不写入源码、截图或公开提示词。

连接生产数据时遵循几个原则：

AsKlear 当前的核心场景是数据查询。把边界保持在可审核的只读工具内，比追求“全自动”更重要。

  • 一个 Key 只获得完成任务所需的数据集和能力。
  • 查询与写入使用不同风险等级；能只读时不要开放写入。
  • 高成本或高影响操作应保留确认步骤。
  • 撤销 Key 后，所有使用该 Key 的 Agent 都应立即失去访问权限。

让 Agent 先读契约

连接完成后，Agent 应该先知道服务端提供了哪些工具，以及 `jd` 数据集支持哪些对象、维度和指标。

数据契约是事实来源。它应该告诉 Agent：GMV、units 和 ASP 如何定义，可以按什么维度分组，时间如何表达，以及哪些筛选值需要先对齐。

如果 Agent 在遇到未知字段时直接猜测参数，MCP 只会更快地执行错误。正确路径是读取或恢复契约，再构造受支持的查询。

用“对象 + 指标 + 时间”提出任务

最稳定的 Agent 查询包含三个基本元素：明确对象、必要指标和完整时间范围。

例如：“查询这个京东商品链接最近三个完整月的月度销量，并说明每个月使用的时间范围。”这个问题有精确对象、单一指标和清楚的分组方式，Agent 通常可以直接执行。

相比之下，“分析一下这个商品”会迫使 Agent 自行选择指标、时间和比较对象。工具调用可能成功，但答案不一定支持用户真正要做的决定。

一次可靠的调用链

对于京东月度销量问题，可以采用以下顺序：

这套流程的目标不是减少到绝对最少的工具调用，而是在少量调用中保持答案可验证、成本可解释。

  • 使用精确商品 ID 或标准链接；品牌、店铺和类目先对齐字典值。
  • 只请求问题需要的指标和最近完整月份。
  • 需要费用确认时，先查看上限并获得用户同意。
  • 执行一次查询，保留实际筛选、时间、分组和指标。
  • 检查空结果、异常值和口径说明，再生成自然语言结论。
  • 追问时复用已经对齐的对象和时间，不重复扩大范围。

把权限和规则留在系统里

高赞的企业 Agent 实践反复强调：模型负责理解意图，业务系统负责确定规则。用户没有权限查看的数据，不应因为 Agent 接入 MCP 就变得可见。

同样，预算上限、字段权限、查询限制和审计记录应该由服务端执行，而不是依赖提示词提醒模型“请谨慎”。

对于可能产生费用或副作用的操作，应采用“先查询、后写入；先预览、后确认”的顺序。MCP 提供标准连接，但治理仍然需要明确的授权、确认和记录。

怎样判断接入是否真的有效

不要只测试工具是否出现在列表中。用几个真实问题检查：

一个合格的 MCP 接入，不是让 Agent“什么都能调”，而是让它在明确边界内稳定完成真实任务。

  • Agent 是否用正确指标回答，而没有擅自增加无关字段？
  • 精确链接是否可以一次定位到商品？
  • 时间是否使用完整月份？
  • 结果是否保留查询范围和指标口径？
  • 空结果或不支持的字段是否得到清楚解释？
  • 同一个追问是否复用前文范围，而不是重新猜测？