MCP 工具标注“只读”，就能放心接入吗？

不能只凭“只读”标签决定是否接入。MCP 工具注解是对行为的提示，不是权限隔离或可信认证。接入智能体前，应分别核对服务来源、凭据权限、可读取的数据与客户端规则；是否免逐次确认，也应基于这些实际边界评估。本文依据官方文档整理，未做服务安全实测。

先分清：行为提示与权限控制

MCP 的 ToolAnnotations 定义了 readOnlyHint，用于提示工具是否修改其环境。但同一规范也明确：注解只是提示，不能保证忠实描述工具行为；来自不可信服务的注解不应成为工具使用决策的依据。[1]

因此，工具名带有“查询”、说明写着“只读”，都不能代替对实现和权限的检查。Tools 规范也区分工具名称、说明、参数结构和注解；这些信息有助于理解工具，却不是服务可信度的自动认证。[4] 编辑建议：先确认谁运营服务、连接到哪里、用谁的账号，再看工具说明。

不修改数据，也要确认能读到什么

“不修改”回答的是行为问题，不能直接回答“这些资料能否交给这个服务”。例如，企业原本只想查询一个测试目录，就应核对凭据是否还能访问其他项目，以及返回内容会进入哪些获准的处理环节。这是权限设计时需要检查的问题，不是对某个服务外传数据的断言。

MCP 安全实践建议采用渐进的最小权限范围：从必要权限开始，在需要更高权限时再处理相应授权，并提醒不能只凭令牌声称的范围代替服务端授权逻辑。[2] 编辑建议：把工具调用许可和账号实际可访问的数据分成两张清单，避免把“只开放一个工具”误当成“只开放一份资料”。 具体授权机制还需结合传输方式、服务实现与企业配置确认。

客户端能调用，不等于服务端只授予了这些权限

Claude Code 文档将允许、询问和拒绝列为权限规则，并说明规则由 Claude Code 执行；提示词或项目说明影响模型尝试做什么，但不会改变工具实际获准做什么。[3] 这是一种具体客户端的实现，不能推广为所有 MCP 客户端的相同行为。

该文档也区分单个 MCP 工具与整台服务的匹配规则。[3] 团队设置自动执行范围时，应核对实际客户端配置覆盖了哪些工具；需要确认的敏感动作可以保留人工判断。是否免逐次确认由具体任务与权限策略决定，不由“只读”二字单独决定。

接入前，做一份可以交接的检查记录

用虚构资料和测试账号记录四项：服务来源与版本、获准工具、账号可读范围、撤销入口。安排正常范围内的查询，再安排一个明确不应访问的测试对象；核对客户端提示、服务端拒绝结果与日志。不要拿真实客户资料尝试未知服务，也不要把一次查询成功当成权限正确。

再撤销测试授权，检查后续访问是否确实被阻止，并确认哪些日志可供追查、谁负责停用和恢复。若工具定义、凭据范围或服务版本变化，重新评估原来的放行范围。上述步骤是编辑提出的验收方法，不是完整安全审计；已有受控环境可以按风险安排检查深度。

适用条件与限制

依据截至2026年10月25日可访问的官方资料整理。MCP 注解定义参考2025-11-25规范；客户端能力与企业配置可能不同。本文未审计具体服务器、检查流量或验证任何产品的权限实现，不保证通过这些步骤即可消除所有风险。