arcgis-portal-mcp: Connect AI Assistants to Your ArcGIS Portal with the Model Context Protocol

Question

The Problem

Every GIS team has this experience: your ArcGIS Portal holds thousands of feature services, web maps, and hosted layers. Your colleagues need answers: "How many parcels are in this district?" "What layers are in this web map?" "Who last modified this service?", and the only way to get them is to open a browser, navigate to the portal, click through item details, and manually query layers.

Meanwhile, AI assistants like Claude, Cursor, and VS Code Copilot can answer complex questions in seconds, but they have no way to reach your portal data.

What if your AI assistant could query your portal directly?

What is MCP?

Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools and data sources. Think of it as a universal adapter: the AI sends a request in a standard format, and the MCP server translates it into the right API calls for the target system.

There are MCP servers for GitHub, Slack, databases, and file systems. But until now, there was nothing production-grade for the ArcGIS ecosystem.

Introducing arcgis-portal-mcp

arcgis-portal-mcp is an open-source MCP server that gives AI assistants full access to ArcGIS Portal and ArcGIS Online. It provides 32 tools across three capability areas:

Read Operations (Phase 1)

* Search for items by keyword, type, or owner
* Inspect item metadata, tags, and descriptions
* List layers in a feature service with geometry types and feature counts
* Query features with attribute filters, spatial filters, and pagination
* List users and groups
* Check portal health and system status

Write Operations (Phase 2)

* Add, update, and delete features in hosted feature layers
* Update item properties (title, description, tags, sharing)
* Create groups and invite users
* Share or unshare items with specific audiences

Publishing & Admin (Phase 3)

* Upload files (CSV, Shapefile, GeoJSON) and publish as hosted feature services
* Create empty feature services with custom schemas
* Execute synchronous and asynchronous geoprocessing tasks
* View licenses, usage statistics, and portal system information
* Batch operations for bulk delete, share, and update

A Real-World Example

Here's what this looks like in practice. Once connected, you can have a conversation like this:

You: "Search for all feature services in our portal related to infrastructure"

AI Assistant: [calls search_content with item_type="Feature Service" and keyword "infrastructure"]

You: "How many features are in the water network layer?"

AI Assistant: [calls list_layers to identify the layer, then query_features with a count]

You: "Show me the 10 most recently modified parcels"

AI Assistant: [calls query_features with order_by="EditDate", limit=10, where="1=1"]

You: "Run the buffer analysis on the contaminated sites layer with a 200m distance"

AI Assistant: [calls execute_gp_task with the GP service URL and parameters]

No browser. No copy-pasting URLs. No manual query building.

Design Decisions

Two choices set this apart from a wrapper around the ArcGIS Python package:

1. Raw REST API, no ArcGIS package dependency

The server communicates directly with the ArcGIS REST API using requests. This means:

* No complex dependency chain to install
* Works reliably on Windows
* Full control over error handling and edge cases

2. Enterprise Portal + ArcGIS Online:  same tools

The ArcGIS REST API is largely consistent across Enterprise Portal and ArcGIS Online. This server exploits that consistency: the same 32 tools work against both platforms with zero configuration changes.

For Enterprise Portal with 2FA, the client_credentials OAuth2 flow handles authentication without a browser. For ArcGIS Online or portals without 2FA, token-based auth is the fastest path.

Getting Started

# Install from GitHub
pip install git+https://github.com/Asem-D/arcgis-portal-mcp.git

Create a .env file in your working directory:

portal_url=https://gis.yourorg.com/portal
username=your-username
password=your-password

Add to your MCP client configuration (Claude Desktop, Cursor, etc.):

{
"mcpServers": {
"arcgis-portal": {
"command": "python",
"args": ["-m", "arcgis_portal_mcp.server"],
"cwd": "/path/to/arcgis-portal-mcp"
}
}
}

The server reads .env on startup and connects automatically. No manual connect_portal call needed.

What's Next

This is the foundation. The architecture is designed so that additional tools, deep admin operations, service management, and analytics can be added incrementally. The MCP standard is evolving, and as it does, this server can evolve with it.

The long-term vision: your ArcGIS Portal becomes an AI-queryable system, where any MCP-compatible assistant can interact with your spatial data through natural language.

Try It

The project is open-source under the MIT license:

* GitHub: github.com/Asem-D/arcgis-portal-mcp
* Installation: pip install git+https://github.com/Asem-D/arcgis-portal-mcp.git
* Tests: 5 passing unit tests covering client initialization, connection handling, and tool/resource registration

I'd love to hear from the community:

* What's the first task you'd want your AI assistant to handle on your portal?
* Are there tools or workflows you'd like to see added?
* How are you currently using AI assistants with ArcGIS?

Feedback, feature requests, and contributions are welcome on the GitHub repository.

Disclaimer: This is an independent open-source project. It is not affiliated with, endorsed by, or sponsored by Esri Inc. "ArcGIS" is a registered trademark of Esri.

Asem_Daaboul · Answer

Thank you for the thorough feedback, and for flagging the security considerations. You raise valid points.

The TLS point is well taken. Certificate verification should be configurable rather than globally disabled, and that's something I plan to address. The scoped allowlist idea is the strongest of the three. In practice, the real risk in production is an agent operating with valid credentials but no organizational boundary. An allowlist for permitted URLs, owners, and groups would directly constrain that blast radius.

On destructive operation gates, I see it differently. The server should execute what the client instructs. The confirmation responsibility belongs to the MCP client layer (Claude, Cursor, etc.), not the server itself. Adding server-side gates would break automation workflows and introduce friction for legitimate batch operations. The allowlist approach is the more structural solution: limit what the agent can touch in the first place, rather than asking it to confirm each time.

ArcGIS MCP Bridge looks like a well-scoped complement. Portal/AGOL administration versus local ArcGIS Pro execution are genuinely different layers, and the integration path you describe (process locally, publish through Portal) is the natural next step. The PathGuard boundaries approach for local filesystem access is a thoughtful design choice for that context.

The integration path between both layers is worth exploring as both projects mature...

muend · Answer

This is a strong and useful direction, especially for ArcGIS Enterprise and ArcGIS Online workflows. I like the decision to use the raw REST API instead of depending on the ArcGIS Python SDK; it keeps the server lightweight and makes Portal administration, hosted feature editing, publishing, and GP service execution available across platforms.

From a security and production-readiness perspective, I would consider making TLS certificate verification configurable rather than disabling it globally for self-signed deployments, and adding explicit confirmation or policy gates around destructive tools such as item deletion, batch updates, feature deletion, and administrative operations. A scoped allowlist for permitted Portal URLs, item owners, groups, or service endpoints could also reduce the risk of an agent operating outside the intended organization boundary.

I am developing a related project, but at a different ArcGIS layer: ArcGIS MCP Bridge connects MCP clients to a local, licensed ArcGIS Pro/ArcPy runtime. It focuses on .aprx projects, file geodatabases, raster processing, layouts, topology, network analysis, and spatial statistics, using isolated ArcPy worker processes, filesystem PathGuard boundaries, and explicit confirmation for destructive operations:

arcgis-mcp-bridge

The two projects seem complementary rather than direct alternatives: arcgis-portal-mcp is well positioned for Portal/AGOL content and administration, while arcgis-mcp-bridge targets local ArcGIS Pro execution and desktop geoprocessing. A future integration between both layers could support workflows that process data locally in ArcGIS Pro and then publish, update, or manage the resulting services through Portal.

Asem_Daaboul · Answer

Hi John,

Thank you so much for pointing this out! I genuinely wasn't aware of the official Esri MCP project in the Early Adopter Community; it seems it hasn't quite surfaced in standard web searches yet, so I really appreciate you pointing me in the right direction.

I spent some time reviewing the documentation at the links you provided, and I deeply admire the work the team is doing. The architectural approach, particularly the ability to install the MCP server directly alongside the portal itself, is a fantastic idea that makes perfect sense for enterprise deployments and seamless integration.

It is exciting to see the alignment in our approaches. There is already a great overlap in our toolsets, particularly around core capabilities like querying feature layers, searching portal content, and extracting item metadata. It validates just how critical these specific functions are for the future of AI-driven GIS workflows.

While Esri’s official beta is clearly shaping up to be a robust solution (especially regarding location services), I believe arcgis-portal-mcp currently helps fill a specific gap for lightweight, dependency-free portal administration. Because it communicates directly with the raw REST API rather than relying on external packages, it offers developers a fast path for executing batch operations, managing users and groups, and handling administrative write operations across both Enterprise and AGOL with minimal configuration overhead.

Ultimately, we are all working toward the exact same goal: serving the GIS community better and making our spatial systems more accessible to emerging technologies. I am looking forward to participating in the beta, testing the official tools, and seeing how this ecosystem evolves.

Thanks again for connecting and sharing these resources!

Best regards,
Assem