Esri / Esri/arcgis-python-api

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

Aperta
#2,525 1 commento 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
Python
Stelle
2.2k
Fork
1.2k
Merge medio
2h 40m
PR unite (30g)
2

Descrizione

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.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Start with the linked arcgis-mcp-bridge repository and its MCP server/ArcPy worker boundary; review the mocked ArcPy tests, registry, PathGuard checks, and worker error boundaries. The issue requests architectural and safety guidance rather than specifying a code change, so a concrete done condition is not defined.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
python
Ambito
backend-api-design, security
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Da chiarire
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.