业务问题：桌面 GIS 的“能做”不等于 AI 应直接获得全部写权限
ArcGIS-Pro-MCP 的 README 将它定义为运行在 ArcGIS Pro 内的 MCP add-in：AI 客户端连接后，操作的是眼前已经打开的项目，而不是导出的副本。它提供项目、图层、属性、选择集、符号化、布局、栅格和编辑等常见能力。这个便利也放大了一个治理问题：同一句自然语言请求，可能只是读取地图信息，也可能保存 .aprx、改写要素或执行任意脚本。
因此，部署的起点不该是“模型能否连上”，而应是把读取、受控操作和脚本逃逸口分开授权、分开审计。
资料依据：项目把执行面分成三层
README 列出 112 个由 C# 实现的命名工具，其中 109 个在 ArcGIS Pro 进程内执行，项目称单次约 9 ms；它们覆盖普通日常地图工作。第二层是 run_geoprocessing_tool，可按名称和命名参数调用约 2,000 个地理处理工具。第三层 execute_arcpy_code 将 Python 直接交给运行中应用的 arcpy。
这三层不能被视为同一种权限。前两层只依赖 add-in；任意 ArcPy 则需可选 Python bridge。对日常制图，优先使用具名工具和参数化地理处理，能让日志、输入和输出更容易复现；只有在前两层没有对应能力时，才应进入任意脚本路径。
本机连接是边界，不是审计机制
README 给出的 MCP 地址是 http://127.0.0.1:6520/mcp；6510 用于 legacy TCP bridge，6511 可供 Python fallback 使用，三者均绑定 127.0.0.1。这能避免远程机器直接访问服务，但不能自动判断本机客户端的请求是否合理。关闭 ArcGIS Pro 后连接断开，说明会话依附于正在打开的桌面应用，而项目写入仍需要单独控制。
项目还说明，点击客户端接入前会询问用户、显示将修改的配置文件并先备份。这个过程适合纳入安装验收：记录哪个客户端被接入、配置写到哪里、备份在哪里，以及连接断开后是否无法继续执行。
业务场景：把“批量更新字段”拆为可审核步骤
例如有人提出“找出人口最高的行政区，把结果写进新字段并导出地图”。第一步只读：读取字段、选择条件、统计口径和当前图层的编辑状态。第二步受控：展示准备调用的地理处理工具、命名参数、输出 geodatabase 与是否覆盖既有字段。第三步才允许写入并导出布局。若需求涉及自定义 ArcPy，先在项目副本运行，记录代码、输入图层、环境参数和输出路径，再由项目负责人决定是否合并。
这样做既利用命名工具的速度，也不会让一句模糊的自然语言直接变成不可逆的项目改动。
技术实施路径
- 只在 ArcGIS Pro 3.7 或更高版本的测试项目中安装 add-in，确认 MCP 地址仅监听 localhost。
- 将 112 个命名工具按只读、可逆写入和高影响写入建立允许清单。
- 对地理处理调用记录工具名称、命名参数、环境设置、输入数据版本和输出位置。
- 默认关闭或隔离 Python bridge；只有经过代码审查的任务可调用任意 ArcPy。
- 每次客户端注册都保存配置备份位置，并在关闭 Pro 后测试连接已失效。
- 在
.aprx副本完成结果检查后，再保存正式项目。
风险边界
README 对工具数量、端口和执行路径的说明是项目自身的能力声明，不能替代生产环境安全审计。localhost 不能防止本机恶意进程，命名参数也不能自动发现错误的 CRS、字段含义或输出覆盖。尤其是 execute_arcpy_code，其灵活性应被视为高权限接口，而不是普通对话功能。
结论
ArcGIS Pro 的 MCP 接入应从三层权限模型开始：优先使用可见、可记录的命名工具；再使用参数化地理处理；最后才让经过审查的 ArcPy 进入隔离副本。把本机连接、项目副本和执行日志一起验收，桌面 GIS 自动化才会可控。
关键词：GIS 是地理信息系统；ArcGIS Pro 是桌面 GIS；MCP 连接应保留 localhost 边界；ArcPy 与地理处理需要可追溯的参数和输出记录。