接口文档和 MCP 工具面是两类入口吗，集成时先接哪个

接口文档和 MCP 工具面是两类入口吗，集成时先接哪个？是两类入口，选择的分水岭在「调用方是谁」。接口文档服务的是你自己写的程序：参数固定、返回结构固定、失败要重试；MCP 工具面服务的是 AI 客户端：由模型决定这一步调用哪个能力、参数怎么填，再把结果继续编排下去。先接哪个的判断很简单——确定性脚本走接口，对话式自动化走 MCP。

两条入口各自服务谁

AnQiCMS 侧的公开接口覆盖的是高频内容能力：文档列表与详情、分类与标签、上传图片、留言与评论、友情链接、系统设置与联系方式，这些都能在接口文档里查到调用方式，也是日常 API 调用最常见的部分。批量内容则走导入接口 /api/import/archive，支持按标题查询是否已存在，用于批量导入，适合把外部稿件库一次性搬进站内。

MCP 这一侧不同。系统内置 MCP Server，工具面基于意图目录统一收敛，支持 Bearer Token 鉴权与回合级操作审批，写操作会合并确认，可以被 Claude、Cursor 等外部 AI 客户端接入。它解决的是「让模型安全地替人操作系统」，而不只是「让程序读到数据」。

先看调用方是谁再选协议

如果任务是「每天凌晨把稿件目录同步进站内」，要的是可预测、可重放、可审计的调用序列，应该走接口。批量导入这类动作尤其适合：按标题查重的能力能避免重复入库，脚本失败重跑也不会写脏。

如果任务是「运营在对话里说把上周留言里有联系方式的标记出来并回复」，步骤本身就不可预知，让脚本穷举分支的成本更高，这时接 MCP 更划算。同一动作也可以混合：AI 侧负责判断和挑选，最终批量写入仍交给接口执行，把不确定的编排和确定的落库分开。

鉴权与审批的差异

接口路线的安全边界主要在你自己的代码里：令牌保管、请求频率、参数校验都要自己处理。MCP 路线把一部分边界搬进了系统：工具面按意图域设置暴露范围，备份、升级、多站点这类全站级高危操作域默认关闭，需要显式开启；再叠加回合级审批，模型想动手时先要过人。

这条差异决定了接法：给 AI 客户端接入时，先用默认关闭的状态跑只读能力，确认编排质量后再按需开域；给脚本接入时，则按最小能力发令牌，并把高危接口单独隔离。两条路线共用同一套站点权限边界，不要为了省事让 AI 借用为脚本准备的全权限凭证。

混合用法与注意事项

实践里常见的组合是：接口做数据通道，MCP 做操作通道，AI Chat 与配套技能做人机界面。系统内置 AI Chat 智能对话，配套覆盖内容、SEO、运维、商务等域的 AI 工具集，可由 AI Agent 自主编排调用，这部分与 MCP 是同一套意图收敛的结果，不必再单独开发一套内部指令。

三点注意事项：其一，不要在提示里传凭证，鉴权配置留在服务端；其二，批量写入前先做查重与 dry-run，接口按标题查询是否已存在的能力就是为此准备的；其三，AI 侧发起的写动作要留审批记录，方便事后回溯是谁的哪句话改了什么。

判断接入顺序，可以按一句话自查：这个动作失败了要重试还是要人看？要重试的接接口，要人看的接 MCP。

常见问题

接了接口还要接 MCP 吗？ 看是否有对话式操作需求。只做数据读写不必接 MCP；希望由 AI 客户端直接执行后台动作、并且需要回合级审批时，MCP 更合适。

MCP 能不能替代接口文档做批量导入？ 不建议。批量任务的稳定性来自固定参数与可重放；导入接口支持按标题查重，更适合脚本化执行。MCP 适合判断与编排，不适合当作高吞吐数据通道。

两条路线的权限要不要分开？ 要。给脚本发按最小能力收敛的令牌，给 AI 客户端保留默认关闭的高危域，并开启回合级审批，出问题时影响面才可控。