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.

[HaydenWelch]

I'll give it a fork and poke around, already cloned it and read though some of the basic structure. I like that you kept imports lazy. Might be worth revisiting that when lazy imports are added to Python too.

I think it could be useful to create a general runner that just directly binds to arcpy, then add the sandboxing/audit layer on top. That way you could switch between the two as needed, or allow users to easily create a sandboxed script that uses a standard interface.

It's not always possible, but you could also limit LLMs to a copy of the data using a file database copy of whatever they're targeting. That way there's no chance of them causing any issues with the original data.

[muend]

Thanks again — this is exactly the kind of feedback I was hoping for.

I agree that the runner layer could be separated more explicitly from the MCP interface. Right now the MCP server is the main entry point, but the underlying value is really the ArcPy execution boundary: keeping task orchestration outside the licensed ArcPy runtime while executing GIS operations in a controlled worker process.

A general ArcPy runner with optional sandbox/audit layers makes a lot of sense. That would allow different modes:

1. direct runner mode for trusted automation,
2. sandboxed/audited runner mode for safer workflows,
3. MCP mode for LLM/client integration.

The copy-based workflow is also a strong idea. For LLM-facing use, limiting execution to a copied file geodatabase or scratch workspace would reduce the risk significantly. PathGuard and confirmation gates help, but a copied workspace would add a much stronger data-safety boundary because the original project data would never be mutated directly.

I’ll likely add these ideas to the roadmap: a clearer runner abstraction, optional sandbox/audit policy layers, worker recovery behavior, and a safe workspace/copy-on-run mode.

Thanks for taking the time to clone and look through the structure — I’d be very interested in any further thoughts as you poke around.