Open-source MCP bridge for ArcGIS Pro / ArcPy workflows — feedback wanted

[muend]

Hi everyone,

I’m sharing an independent open-source project I’ve been working on: arcgis-mcp-bridge.

It is a local-first MCP server that exposes ArcGIS Pro’s ArcPy runtime to MCP-compatible hosts over stdio JSON-RPC. The goal is to make ArcPy workflows usable through a controlled local bridge without importing ArcPy directly into the AI host process.

The project uses a two-process architecture:

1. A lightweight MCP server layer handles protocol, validation, and tool routing.
2. A separate licensed ArcGIS Pro Python worker process handles ArcPy geoprocessing execution.

Current scope:

- 100 declarative geoprocessing tools across 10 GIS verticals
- ArcPy worker isolation
- PathGuard filesystem sandboxing for local GIS data boundaries
- explicit confirmation gates for destructive operations
- mocked ArcPy tests so CI can run without an ArcGIS license
- optional Sketch-to-GIS / OpenCV pipeline for extracting hand-drawn boundaries into a geodatabase

This is not an official Esri project and not an official Anthropic project. It is an independent open-source bridge for ArcGIS Pro, ArcPy automation, and MCP-based GIS workflows.

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

PyPI:
https://pypi.org/project/arcgis-mcp-bridge/

MCP Registry name:
io.github.muend/arcgis-mcp-bridge

I would really appreciate feedback from ArcGIS Pro, ArcPy, Python, and geoprocessing users:

1. Does this match any real workflow you have?
2. Which ArcPy tools should be prioritized next?
3. What would make this safer or easier to use in a GIS team?
4. Are there ArcGIS Pro compatibility issues I should test first?

Thanks.

[muend]

I also wrote a longer technical explanation of the architecture, worker-process isolation, PathGuard boundary, and testing approach here:

https://dev.to/muend/building-a-secure-mcp-bridge-for-arcgis-pro-and-arcpy-511g

I’d still appreciate feedback from ArcGIS Pro / ArcPy users, especially around which geoprocessing workflows should be prioritized and what safety boundaries would be necessary for real project data.

[HaydenWelch]

Seems interesting, The RPC server/client for controlling ArcPro would probably be more immediately useful as a way to reliably control a workflow than as an LLM interface. Since most of the time the code that is managing the workflow is in the same interpreter as arcpy.

If you were to develop this further, I'd definitely expand on that idea and make this more of a general runner that lets you separate your task logic from the actual GIS logic (especially if the worker had the ability to try and revive a crashed arcpy process).

I'm not big on using LLMs, so I've instead tried to write a more human focused library that lets us write our (usually very complex) workflows out in something closer to pure python. This library is absolutely not safe to give to an LLM since it digs pretty deep into the arcpy machinery to make common operations faster and lets you do some pretty "illegal" stuff to avoid slow function calls.

I'm definitely going to try and take a deeper look at your library, even if I won't use it for its intended purpose  😉

[muend]

Thanks, this is very useful feedback.

I agree that the worker/RPC boundary may be useful beyond the LLM interface. The MCP layer is one entry point, but the underlying design is really about separating task orchestration from ArcPy execution and keeping ArcPy inside a controlled worker process.

The crash-recovery point is especially interesting. The current model is spawn-per-call, so each job already has a hard process boundary, but a future warm worker or worker-pool mode would definitely need health checks, restart/revive behavior, timeout handling, and probably structured job logs.

I also agree that many advanced ArcPy workflows are not safe to expose directly to an LLM. My goal is not to give an agent a generic Python doorway, but to expose named, typed, auditable operations with explicit filesystem and destructive-operation boundaries.

I’d be very interested in your perspective if you do take a deeper look, especially around which parts would be useful as a general ArcPy runner rather than only as an MCP/LLM bridge.