Question: Secure local MCP / agent integration path for ArcGIS Pro and ArcPy

Hi ArcGIS API for Python / GeoAI team 👋

I have been working on an open-source project around ArcGIS Pro, ArcPy, and MCP-based agent workflows, and wanted to share it here mainly to ask for architectural guidance rather than to promote the project.

Repo: https://github.com/muend/arcgis-mcp-bridge

The project is called `arcgis-mcp-bridge`. It is a local-first MCP server that exposes ArcGIS Pro / ArcPy geoprocessing tools to MCP-compatible LLM clients such as Claude Desktop, Cursor, or other local agent runtimes.

The core design goal is not just “LLM calls ArcPy”. The main concern is how to expose ArcPy in a way that keeps the GIS runtime isolated, testable, and bounded by explicit safety controls.

Current structure:

- **Layer A: MCP server**
- handles MCP / stdio JSON-RPC
- exposes tool definitions
- validates requests with Pydantic contracts
- applies PathGuard filesystem checks
- enforces confirmation gates for destructive tools
- does **not** import ArcPy

- **Layer B: ArcPy worker**
- runs in a separate subprocess
- uses the configured ArcGIS Pro / ArcPy-capable Python interpreter
- imports ArcPy only inside the worker boundary
- executes the actual geoprocessing operation
- returns structured results or structured errors

The reason for this separation is that ArcPy is powerful, licensed, native-code dependent, Windows-bound, and difficult to test inside normal CI environments. I did not want the MCP host process to directly import ArcPy or become coupled to the licensed GIS runtime.

The project currently includes:

- 100 declarative ArcGIS Pro / ArcPy tool definitions
- 10 GIS verticals: data management, geometry analysis, projection, raster operations, map/layer management, export/layout, editing/topology, network analysis, spatial statistics, and a sketch-to-GIS vision pipeline
- PathGuard filesystem sandboxing for read/write paths
- explicit `confirm: true` gates for destructive operations
- mocked ArcPy tests so the server-side contracts, registry, path guards, and worker error boundaries can be tested without ArcGIS Pro
- PyPI distribution for local installation

This is not a hosted GIS service. Real geoprocessing still requires a local Windows machine with ArcGIS Pro and a licensed ArcPy runtime. Hosted MCP directories are only useful for discovery, installation metadata, and health-check style introspection.

I know this repository is focused on the ArcGIS API for Python / Web GIS ecosystem rather than ArcPy or the ArcGIS Pro SDK. I am posting here because the GeoAI / agentic GIS direction overlaps, and I would value the team’s perspective on how community work in this area should be structured.

A few open questions:

1. Is MCP / agent / tool-calling integration with ArcGIS something the team is actively thinking about?
2. For local ArcGIS Pro / ArcPy workflows, does a two-process boundary like this seem like the right direction, or would you recommend a different integration model?
3. Are there safety requirements the community should treat as baseline when exposing GIS tools to LLM agents?
4. Should community projects prefer ArcPy subprocess isolation, ArcGIS Pro SDK add-ins, ArcGIS API for Python / Web GIS tools, or some combination depending on the workflow?
5. Is there a preferred venue for technical feedback on this kind of integration: GitHub issues, Esri Community, or another channel?

I am not affiliated with Esri. ArcGIS, ArcGIS Pro, and ArcPy are Esri trademarks. This is an independent community integration.

Happy to move this to Esri Community if that is a better place for the discussion, and I would appreciate any feedback on the architecture, safety model, or alignment with Esri’s GeoAI direction.

Thanks.

Beginnen Sie mit dem verlinkten Repository arcgis-mcp-bridge und der Grenze zwischen seinem MCP server und dem ArcPy worker; überprüfen Sie die Mocked-ArcPy-Tests, die Registry, die PathGuard-Prüfungen und die Fehlergrenzen des Workers. Das Issue fordert architektonische und sicherheitsbezogene Anleitung an, anstatt eine Codeänderung vorzugeben, daher ist keine konkrete Abschlussbedingung definiert.

Vom Indexierungsmodell aus dem Issue-Text verfasst.