通用 MCP 能让 Agent 调工具，却没有规定一个地理服务应该提供哪些操作、输入和结果。geospatial-mcp 将这件事写成开放、厂商中立的 Draft 1.0 规范：工具名称、JSON Schema、资源 URI、计划与交接语义，以及可机器检查的一致性模型都进入同一个词汇表。它适合用于设计跨 GIS 平台的 Agent 边界，而不是把某个厂商实现当成通用协议。

可核查事实

  • geospatial-mcp 将自身标为 Draft，SPEC_VERSION 为 1.0。
  • 规范定义工具输入和资源载荷的 JSON Schema draft 2020-12。
  • v1 覆盖 Analyze、Publish Data、Build App 三个工作流族；Automate/Deploy 被延后。
  • base profile 是只读底座，包含 plan/validate/execute 分析表面。
  • analysis profile 增加 buffer、overlay、统计、重投影、join 和导出六个地理处理动词。
  • mutation profile 只提供受治理、认证、按编辑类型授权且事务化的 edit_features。
  • README 明确排除自主 Agent 编辑地理记录。
  • 一致性检查可报告 MAPPED、FULL 或 FAIL；Honua server 的 bundled manifest 在 base profile 被报告为 FULL。

核心机制

geospatial-mcp将自身标为Draft，SPEC_VERSION为1.0。规范定义工具输入和资源载荷的JSON Schema draft 2020-12。它把“能连接”转成“能理解”：调用方可发现资源、计划并执行分析、组合地图和应用，再按一致的资源生命周期处理结果。

v1覆盖Analyze、Publish Data、Build App三个工作流族；Automate/Deploy被延后。base profile 是只读底座，analysis 增加六个直接地理处理动词。把能力按 profile 声明，可以让客户端在执行前发现服务器究竟支持什么，而不是根据工具名字猜测。

GIS 场景

mutation profile只提供受治理、认证、按编辑类型授权且事务化的edit_features。README明确排除自主Agent编辑地理记录。对生产 GIS，这意味着 Agent 能计划和提出编辑建议，却不能因一句自然语言直接修改权威要素；编辑应有数据域、操作类型、审批人与事务结果。

一致性检查可报告 MAPPED、FULL 或 FAIL。MAPPED 证明发布的工具和资源都映射到标准词汇；FULL 还要求声明 profile 中已实现的工具族被实际发布。团队可以把 manifest 检查放进服务上线流程，并在真实任务中另测权限、性能和空间结果。

技术路径

  1. 将现有 MCP 工具映射到规范词汇与 profile。
  2. 先以 base profile 提供只读检索、计划和分析。
  3. 用 manifest 检查阻止未声明或命名漂移的工具上线。
  4. 将分析与编辑分离；编辑仅在 mutation profile、授权和事务审计下开放。
  5. 用真实 AOI、数据权限和失败路径验证，而不是只通过静态 schema。

检查清单

  • 工具和资源是否都有标准映射？
  • 服务声明的 profile 是否与实际表面一致？
  • 编辑是否有身份、范围、审批和事务记录？
  • 失败和交接能否回到资源 URI 与计划？
  • 静态一致性之外是否测试了真实空间结果？

风险边界

Draft 1.0 没有兼容性保证；schema 通过也不代表分析正确、数据被授权或运行时行为可移植。规范把协议边界写清，不能替代 CRS、数据质量、性能与人工责任的验证。

资料依据

本文依据 geospatial-mcp 官方仓库 的 README、规范索引和一致性说明撰写；事实来自一手仓库，实施建议为工程解读。

结论

跨平台地理 Agent 的基础不是更多工具，而是可发现、可声明、可检查的工具契约。先统一词汇和 profile，再扩展自动化能力。