Traditional GIS work assumes a trained analyst working inside a desktop application. That assumption is fine when your organization has skilled GIS staff sitting next to the requester — but for most humanitarian and NGO operations, it isn't the norm. The result is a familiar bottleneck: field teams and program officers who need a quick spatial answer, and a single overloaded GIS focal point who becomes the gatekeeper for every map, every query, every update.
MCP-mediated LLM access to ArcGIS Online opens a new lane. A non-specialist can now ask a plain-English question — "which of our health facilities are inside the current flood-affected polygon?" — and get an answer without opening any GIS software. This is not a replacement for ArcGIS Pro or QGIS. It is a productive complement, especially for the read-heavy, quick-turn queries that dominate humanitarian information management.
This manual walks through the setup end to end, shows what is and is not possible today, gives you a starter library of prompts drawn from real sessions, and is honest about the limitations — including the data-protection considerations that any humanitarian organization has to weigh before adopting this pattern.
What "connecting an LLM to ArcGIS Online" actually means
The connection relies on three components chained together. Understanding this chain matters because it shapes what's possible, what's secure, and what fails.
Claude is the large language model — it parses your natural-language question, decides which tool to call, and interprets the result for you. Pipedream is a hosted MCP (Model Context Protocol) broker — it maintains OAuth tokens for hundreds of services and translates Claude's structured tool calls into authenticated API requests. ArcGIS Online is Esri's cloud platform where your hosted Feature Services actually live.
MCP (Model Context Protocol) is an open standard from Anthropic that defines how LLMs discover and call external services in a structured, permissioned way. Rather than every developer building custom integrations, MCP lets a single standard work across many models and many services. Pipedream is one of several MCP hubs offering ArcGIS Online as a connector; the same architectural pattern would apply through other brokers.
In practice, a "connection" means you authorize Pipedream to talk to ArcGIS Online once, via OAuth. Pipedream stores an access token. From that point on, when Claude calls a tool, Pipedream executes it against your account using that token. Your ArcGIS Online username and password never pass through the chat. This is important: the security boundary is enforced by OAuth, not by the LLM.
Note
Whatever ArcGIS Online account you connect defines what Claude can see and edit. Connect a personal Individual account and Claude sees your personal items. Connect an Organization account with elevated privileges and Claude inherits those privileges. Choose your connected identity deliberately.What can (and cannot) be done today
Being explicit about scope prevents disappointment. The current ArcGIS Online MCP connector exposes a specific set of read and write operations. Everything outside that set requires a different tool.
✓ Available operations
- List Feature Services in your account, organization, or public catalog
- List layers inside a Feature Service, with geometry type and layer type
- List fields on a layer, with data type, alias, and editability flag
- Search features by column where a field equals a value (equality only)
- Spatial intersect by OBJECTID — find features in target layers that intersect a known source feature
- Spatial intersect by geometry — pass a geometry directly
- Spatial intersect by SQL WHERE — filter the source feature then run the intersect
- Update a single attribute on a single feature by OBJECTID
✗ Not available today
- Publishing new services or uploading source files
- Bulk edits — multi-row inserts, updates, or deletes
- Geoprocessing — buffers, spatial joins as tables, cost surfaces, network analysis
- Cartographic output — the LLM returns data, not rendered map images
- Range and comparison queries on a single layer as a first-class operation (workaround via the WHERE-clause spatial variant)
- Multi-account switching within one session
- Local geodatabase access — data must already be on ArcGIS Online
The pattern to internalize: this is a read-heavy, single-target interface. It shines for exploratory questions, targeted lookups, and small-scale updates. It is not built for batch pipelines or map production.
Why do it this way — the case against alternatives
Every capability listed above is achievable through other means. What LLM-mediated access changes is the cost of access — who can do it, how fast, and with what tooling installed. The honest comparison looks like this:
| Alternative | Where this pattern wins | Where the alternative wins |
|---|---|---|
| ArcGIS Pro (desktop) | Zero training, no license per user, immediate answers | Cartography, geoprocessing, offline work, full analytical stack |
| ArcGIS Online web UI | Multi-step queries in one sentence, cross-service joins in the same session | Visual map editing, sharing configuration, dashboard authoring |
| Python arcgis API | No code, no auth boilerplate, LLM introspects the schema for you | Reproducibility, batch operations, version control, complex pipelines |
| Direct REST calls | No parameter memorization, natural-language field references | Rate control, precise error handling, integration into apps |
| Power BI ArcGIS integration | Exploratory questions across ArcGIS, Slack, Drive, and Gmail in one session | Persistent dashboards, scheduled refresh, business-user access |
The value proposition for humanitarian operations is specific: a field team member who needs a spatial answer this minute can get one without asking a GIS colleague, opening any software, or writing any code. That is a genuine unlock for organizations where the ratio of requesters to GIS analysts is high — which is most humanitarian settings.
Setup guide
Setup is a four-step sequence. Budget about thirty minutes for a first-time run, most of which is authorization and account setup rather than technical work.
A. ArcGIS Online prerequisites
You need an ArcGIS Online account with at least one hosted Feature Service for the connector to have something to work with. An empty account will authenticate but return zero results — not helpful for a first test.
-
Confirm you have an ArcGIS Online account
Individual is enough for personal experimentation. Organization is required for shared work and collaboration. Sign in at arcgis.com.
-
Publish at least one hosted Feature Service
Upload a shapefile, CSV with coordinates, GeoJSON, or file geodatabase via Content → New item → From your computer. Uploading is not enough — you must then click Publish on the item page to convert it into a queryable Feature Service. If you only see the source file type in Content, the publish step is still pending.
-
Confirm the published item type
In Content, the item type column should read Feature Service or Feature Layer (hosted). Anything else won't be visible to the connector.
Credit consumption
Publishing a hosted Feature Layer consumes ArcGIS Online storage credits. Individual accounts come with a limited pool. Small test layers will barely dent it; large or frequent publishes will.B. Pipedream setup
-
Create a Pipedream account
Sign up at pipedream.com. A free tier is sufficient for personal experimentation and light usage.
-
Locate the ArcGIS Online connector
In the Pipedream dashboard, search the connector catalog for "ArcGIS Online" and select it.
-
Authorize via OAuth
Pipedream will redirect you to ArcGIS Online's sign-in page. Enter your ArcGIS Online username and password there — not in Pipedream, and never in Claude. After successful sign-in, ArcGIS Online will ask you to grant Pipedream permission to access your account. Confirm.
-
Verify the connection
Back in Pipedream, the ArcGIS Online connector should show as connected and healthy. Note the connection name — you may need to reference it later.
C. Claude setup
Claude connects to Pipedream through its Custom connector feature (currently in beta). This is a one-time setup — after this, every Claude conversation can invoke the ArcGIS Online tools you authorized in Pipedream, along with any other services you have connected there.
-
Open Claude settings and go to Connectors
In Claude's sidebar, click Settings → Connectors. This is where all your third-party integrations live.
-
Click "Add" and choose Custom connector
From the Add menu in the top right, select Custom connector. A dialog will open where you can enter the connector's details.
-
Name the connector and paste the Pipedream MCP endpoint
Give the connector any name you'll recognize — "Pipedream" is a good default. In the URL field, paste this exact value: https://mcp.pipedream.net/v2. This is Pipedream's unified MCP endpoint. It exposes every connector you have authorized inside Pipedream — ArcGIS Online plus anything else — as a single stack of tools to Claude.
-
Leave OAuth fields blank and click Add
The advanced OAuth Client ID and Secret fields are optional — leave them blank. Pipedream handles per-service OAuth internally using the tokens it stored during setup step B, so Claude does not need its own credentials. Click Add. Claude will verify the endpoint and mark the connector as active.
-
Test with a benign first query
Open a new Claude conversation and ask: "Using the Pipedream ArcGIS connector, list Feature Services accessible to my account." A successful response — even one that returns zero services — confirms the entire chain is working end to end.
Useful prompts for humanitarian IM and NGO spatial analysis
Prompts drive the entire experience. The right prompt gets the answer in one call; a vague prompt burns turns on clarifications. This section walks from confirmed real-world prompts (things I have actually run in Claude) through humanitarian-workflow adaptations to broader patterns worth developing over time.
Start small — prompts have a token cost
Not all prompts below were tested end to end. Each card carries a status badge: ✓ Tested ran successfully in a real session; ◌ Template is a pattern to adapt and verify against your own services; △ Advanced is a direction to develop, and typically token-intensive. Multi-step and cross-service prompts can consume a large share of a session's budget, especially when the model has to retry, diagnose, or clarify. Work up the ladder: run a one-call prompt (list services, list fields) first, confirm the target service and field names exist, then move to filters and spatial joins. A vague or over-ambitious opening prompt can burn most of a session on clarification loops without delivering anything. In one of our own test sessions, a single out-of-scope request — asking for a rendered map, which the connector cannot produce — consumed nearly half the session's budget on diagnostics before the limitation was confirmed.A. Confirmed working prompts
These are drawn from real Claude + Pipedream + ArcGIS Online sessions. They ran successfully end to end.
B. Adapted for humanitarian workflows
These templates translate the pattern to real humanitarian information management questions. Substitute your own service, layer, and field names.
C. Patterns worth developing
These are prompt directions rather than concrete prompts — capabilities to build fluency in over weeks of use.
How to write prompts that work first time
- Match the prompt to the tool's actual capabilities. Asking the connector to "develop a map" will fail expensively — it returns data, not rendered maps. Ask for the data, then visualize it downstream (or ask Claude to build a visualization from a public feed directly, bypassing the connector entirely).
- Name the service explicitly by title or item ID. Avoid pronouns and vague references.
- Name the field explicitly. If you're not sure of the field name, ask Claude to list fields first.
- Put string values in quotes. This matches the underlying SQL escaping and reduces ambiguity.
- Ask for a limited set of output fields to keep responses focused.
- Verify writes by re-reading. Never trust a "done" confirmation without checking the state.
Limitations, cautions, and open questions
Adopting this pattern seriously means being honest about what it is and isn't. The list below covers the technical, operational, data-protection, and cost boundaries — plus what's likely to improve over time.
Technical limits
- Feature Services must be hosted on ArcGIS Online, not stored locally in a Pro project or file geodatabase.
- No true range or comparison queries on a single layer through the equality-only tool. The WHERE-clause variant of the spatial intersect is a partial workaround, but only when a spatial component makes sense.
- Write operations are limited to a single attribute on a single row. Bulk edits are out of scope.
- No geoprocessing (buffers, joins, cost surfaces, network analysis) and no cartographic output.
- Result sets are modest in size. This is not a bulk-export interface.
- Requests that exceed the connector's scope (e.g., "render a map of last month's earthquakes") don't fail fast — the model may spend many turns attempting workarounds before concluding the task is out of scope, consuming a substantial share of a session's budget in the process. Scope your requests to the operations listed in Section 2.
Operational and organizational
- OAuth binds one Pipedream connection to one ArcGIS Online account. Multi-account switching within a session is not supported.
- Chat sessions are not reproducible scripts. Version control, audit trails, and reproducibility require you to save prompts and outputs separately, ideally in a shared notebook or repository.
- LLMs are non-deterministic. The same prompt can route slightly differently across sessions or model versions. Verify important results by reading them back or asking a second way.
- The connector inherits whatever privileges the connected account has. Connect a limited account for read-mostly workflows; keep write-capable accounts for narrower use.
Data protection — the section that matters most
Read this carefully before connecting production data
Data flowing through the connector traverses Pipedream's infrastructure between Claude and ArcGIS Online. Before connecting an account that holds sensitive humanitarian information, your organization must complete its own data-protection review of the entire chain.- Review Pipedream's data handling, retention, and sub-processor policies before authorizing an account that can reach sensitive layers.
- Review Anthropic's data usage terms for the Claude tier you're on. Enterprise, Team, and Free tiers have materially different data-retention and training-use terms.
- For sensitive humanitarian data — PII, protection cases, IDP registries with individual identifiers, HeRAMS entries linked to persons, GBV case data — do not adopt this pattern until your protection and data governance leads have cleared the full processing chain against organizational standards and any relevant data-sharing agreements with UNHCR, ICRC, host-government counterparts, or donor requirements.
- The strongest fit today is anonymized, aggregate, or publicly-shared spatial data: administrative boundaries, publicly-shared facility catalogs, satellite-derived hazard extents, aggregated indicators. This is where the workflow value is highest and the protection risk is lowest.
- Consider a two-account model: one ArcGIS Online identity for LLM-mediated access with only non-sensitive services shared to it, and another identity for sensitive production data with no MCP connection at all.
Cost
- ArcGIS Online plans consume storage and transaction credits when you publish and query. Individual accounts have finite pools; heavy use will exhaust them.
- Claude usage falls under whichever plan you're on. Tool-heavy sessions with many round-trips cost more than pure text sessions.
- Pipedream free tier is generous for personal use but has execution limits. Team and higher tiers apply for organizational adoption.
What may improve over time
- Broader ArcGIS operation coverage — bulk edits, publishing, geoprocessing — as the MCP catalog matures.
- Better range and comparison query primitives, reducing the need for workarounds.
- Dedicated humanitarian-sector MCP servers. HDX is already an active area, and organization-specific servers (UNHCR, OCHA) are plausible next steps.
- Improved auditability — session logs and prompt versioning that make LLM-mediated workflows reproducible enough for regulated environments.
Try it. Share back.
If you set this up in your own environment — or hit a wall doing so — I'd like to hear about it. The prompt library grows fastest when practitioners contribute what works in their operational context.