ARCclaude is an MCP server that gives AI assistants complete programmatic access to ArcGIS Pro and the ArcPy ecosystem, enabling natural language-driven GIS workflows.
Execute arbitrary Python/ArcPy code: Run any Python or ArcPy code in a persistent, REPL-like session where variables persist between calls — supporting geoprocessing, cursors, raster algebra, map automation, and more.
Run geoprocessing tools: Execute any of ArcGIS Pro's ~1800+ geoprocessing tools by name with positional or named parameters, returning outputs and messages.
Search and describe geoprocessing tools: Search all available tools (including extension toolboxes) by keyword, and retrieve full syntax/documentation before running them.
Create vector datasets from GeoJSON: Generate shapefiles or geodatabase feature classes directly from GeoJSON FeatureCollections, with automatic field creation and geometry type inference.
Export vector data as GeoJSON: Read any vector dataset (shapefile, feature class, layer) as GeoJSON with optional SQL filtering and row limits.
Inspect datasets: Get detailed profiles of any dataset including type, spatial reference, extent, fields, and row count.
Inventory workspaces: List all contents (feature classes, rasters, tables, datasets) of a geodatabase or folder.
Inspect ArcGIS Pro projects: Examine .aprx project files to see maps, layers, data sources, layouts, and the default geodatabase.
Live cowork mode: Execute Python code inside a currently open ArcGIS Pro application — enabling live map changes, layer additions, symbology updates, and more via the CURRENT project reference.
Session management: Check the ArcPy session's license level, workspace, and active variables, or restart the worker process to clear state and release locks.
Provides tools for running geoprocessing tools, inspecting and editing GIS data, managing projects, and automating analysis workflows through ArcGIS Pro's ArcPy engine.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ARCclaude Buffer schools by 500m and intersect with parcels"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An open-source MCP server that gives AI assistants complete access to the ArcGIS Pro ecosystem.
ARCclaude connects Large Language Models — Claude, GPT, Gemini, local models, or anything that speaks MCP — to ArcGIS Pro through ArcPy. It is not a chatbot that answers GIS questions: it's a copilot that does the work — running geoprocessing tools, writing and debugging ArcPy, inspecting projects and data, automating maps, and building complete analysis pipelines from natural language.
"Buffer every school in the city by 500 m, clip to the district boundary, and tell me how many parcels intersect" — and it actually happens, in your local ArcGIS Pro install, with full messages and outputs reported back.
Claude / GPT / any MCP client
│ MCP over stdio
▼
ARCclaude server (lightweight Python, managed by uv)
│ JSON-lines over pipes
▼
ArcPy worker — persistent session on ArcGIS Pro's own Python
▼
ArcGIS Pro (all licensed tools & extensions)There is no chat window inside ArcGIS Pro, and you never "open" ARCclaude. The relationship is flipped:
You talk to your AI app (Claude Desktop, Claude Code, Cursor, …) in plain English: "Create a shapefile of the 5 largest lakes in Ontario with name and area fields."
The AI drives ArcGIS Pro's engine through ARCclaude, in the background — Pro doesn't even need to be running.
You open the results in Pro like any other data: Map → Add Data → your new shapefile/geodatabase is just there, fields and all.
Pro can be open at the same time; just avoid pointing both Pro and the AI at the same geodatabase simultaneously (file locks). An in-Pro chat panel is on the roadmap (Phase 3).
Two design decisions make this robust:
Esri's Python environment is never modified. The worker script uses only the standard library + arcpy, so nothing is ever installed into arcgispro-py3. No env cloning, no admin rights, upgrade-safe.
The arcpy session is persistent. The slow arcpy import (~20–60 s license checkout) is paid once; after that every call is fast, and variables persist across calls like a REPL — the AI can build up state over a long workflow.
Related MCP server: arcpro-mcp
Windows with ArcGIS Pro 3.x installed and licensed
uv (installs its own Python — you don't need one)
You do not need this repo, git, or any coding. Paste one line into PowerShell:
irm https://raw.githubusercontent.com/thaparSAAB14/ARCclaude/main/install.ps1 | iexIt checks ArcGIS Pro, installs what's needed, and auto-connects ARCclaude to Claude Desktop and Claude Code. Then open Claude Desktop (or Claude Code) and just talk: "make a shapefile of the 3 biggest parks near me." That's the whole product — Claude is the interface; ARCclaude works invisibly underneath. Re-running the same line updates you to the latest version.
Note: Claude must run on the same PC as ArcGIS Pro (Claude Desktop or Claude Code). The claude.ai website in a browser cannot reach software on your machine — a hosted/remote mode is on the roadmap.
git clone https://github.com/thaparSAAB14/ARCclaude.git
cd ARCclaude
uv syncNew to this? The complete setup guide walks through everything from a blank machine, including client configs and troubleshooting.
The repo ships a project-scoped .mcp.json, so opening this folder in Claude Code just works. To register it globally instead:
claude mcp add arcclaude --scope user -- uv --directory C:\path\to\arcclaude run arcclaudeAdd to %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"arcclaude": {
"command": "uv",
"args": ["--directory", "C:\\path\\to\\arcclaude", "run", "arcclaude"]
}
}
}Any other MCP-capable client (Cursor, Windsurf, open-source agents, GPT/Gemini via MCP adapters) configures the same way: uv --directory <repo> run arcclaude over stdio.
Tool | What it does |
| Run any Python/ArcPy code in the persistent session (REPL semantics) |
| Cowork mode: run code inside the user's OPEN ArcGIS Pro app — live map changes, |
| Search all ~1800 geoprocessing tools, incl. extension toolboxes |
| Syntax + full documentation for any GP tool |
| Execute a GP tool by name with parameters; returns outputs + messages |
| Make vector data from GeoJSON — shapefiles or geodatabase feature classes, fields auto-created, geometry type inferred |
| Read any vector dataset back as GeoJSON (SQL |
| Convert a whole .aprx to a QGIS project (.qgz) — layers, CRS, symbology carried across, free (details) |
| Dataset profile: type, CRS, extent, fields, row count |
| Inventory a geodatabase or folder |
| Maps, layers, sources, layouts of an |
| License level, workspace, live session variables |
| Kill and restart the ArcPy session (clears state, releases locks) |
Because discovery is dynamic (arcpy.ListTools), newly installed extensions and custom toolboxes are exposed automatically — no code changes needed.
ARCclaude also ships a standalone agentic CLI (bring your own API key — Anthropic, OpenAI, Gemini-compat, Groq, or a free local model via Ollama):
uv run arcclaude login # one-time: pick provider, paste key
uv run arcclaude chat # Codex-style AI GIS terminalWorks in any Windows terminal, including ArcGIS Pro's own Python Command Prompt.
An open project is locked to outside processes, so ARCclaude ships a Live Link:
run uv run arcclaude live, paste the printed one-liner into Pro's Python
window (View ribbon → Python), and the AI can now drive the session you're
looking at — add layers to the current map, restyle, zoom, save — via the
pro_live_execute tool.
Cowork rules (experimental feature): while active, Pro's Python window is
busy — don't type more commands into it, and don't close Pro to end it.
Stop from any terminal with uv run arcclaude live stop; it also auto-exits
after 10 minutes with no commands. See PRODUCT.md for the
architecture — the Phase-3 add-in replaces this with proper in-app threading.
arcpy_execute runs arbitrary Python code on your machine with your permissions. That is the point — it's what makes the copilot universal — but understand it:
Run it only with MCP clients that show you tool calls and let you approve them (Claude Code and Claude Desktop both do).
The worker inherits your ArcGIS license and file access; it can edit and delete data you can.
Never expose the server over a network transport without adding authentication.
Environment variable | Purpose | Default |
| Explicit path to | auto-discover (registry → known paths) |
| Seconds to wait for arcpy import |
|
| Default per-request timeout (seconds) |
|
Full index: docs/README.md. The essentials:
Setup guide — complete walkthrough: install, client configs, troubleshooting
Security & privacy — data flow, offline mode, network surface (read this, IT folks)
Comparison — vs. Esri's Pro Assistant, community MCP servers, and Kue
Vision — the full scope this project is building toward
Architecture — design decisions and worker protocol
Roadmap — phased plan from this MVP to the full vision
Alpha (v0.5.0). The core execution engine works end-to-end. The surface area of the vision — Pro SDK add-in for live session control, ArcGIS Online/Enterprise, open-data connectors — is roadmap. Issues and PRs welcome.
Apache-2.0. ArcGIS, ArcPy and ArcGIS Pro are trademarks of Esri. This is an independent community project, not affiliated with or endorsed by Esri.
Execute Python code in the persistent ArcPy session.
arcpy is already imported. Variables persist between calls, so you can
build up state across multiple invocations. If the last statement is a
bare expression its repr is returned (like a REPL). stdout is captured.
Use this for anything ArcPy can do: geoprocessing, arcpy.da cursors, arcpy.mp map automation, raster algebra, arcpy.Describe, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: code execution, persistent variables between calls, stdout capture, and return of the last expression's repr. It does not mention potential risks like destructive operations or error handling, but given the absence of annotations, it covers the core behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a brief introductory sentence followed by bullet-like points. Every sentence adds value, with no redundancy. Information is front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution, persistent state), the description covers the return value and stdout capture. An output schema exists but is not shown; the description explains how output is returned. Minor missing details include handling of timeouts and potential side effects, but overall it is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the 'code' parameter by explaining how to get output (last expression repr) and that stdout is captured. However, it offers no additional semantic for 'timeout_seconds', and the input schema has 0% description coverage, so the description only partially compensates. A note on timeout behavior would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes Python code in a persistent ArcPy session, specifying the action and resource. It distinguishes from siblings like 'run_gp_tool' by emphasizing general-purpose usage for any ArcPy task, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides good guidance on when to use the tool: for any ArcPy operation, especially when state persistence is needed. It lists specific use cases like geoprocessing and automation. However, it does not explicitly mention when not to use it or suggest alternatives (e.g., 'run_gp_tool' for simple tool execution), which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create vector data (shapefile or geodatabase feature class) from GeoJSON.
This is the fastest way to MAKE data from scratch: emit a GeoJSON
FeatureCollection and pick an output path. output_path decides the
format: C:\data\roads.shp creates a shapefile, C:\data\my.gdb\roads
a file-geodatabase feature class. Attribute fields are created from the
feature properties automatically. Coordinates must be WGS84 lon/lat (the
GeoJSON spec); use run_gp_tool 'Project_management' afterwards if you
need another CRS. Existing outputs are overwritten. The geometry type is
inferred from the data; set geometry_type (POINT, MULTIPOINT, POLYLINE,
POLYGON) only when the collection mixes types and you must pick one.
Returns a description of the created dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| geojson | Yes | ||
| output_path | Yes | ||
| geometry_type | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: overwriting existing outputs, automatic attribute field creation, geometry type inference, required WGS84 coordinate system, and return value. With no annotations, the description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Organized with front-loaded purpose, each sentence adds value. The description is appropriately sized for the tool's complexity, with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 parameters, output schema availability, and no annotations, the description covers input/output, parameter usage, behavioral details, and return value. Complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning to three of four parameters: 'geojson' (implied GeoJSON string), 'output_path' (format inference), and 'geometry_type' (when to set). However, 'timeout_seconds' is not explained, though it's a common default parameter. Almost fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool creates vector data from GeoJSON, specifies output format options (shapefile vs geodatabase feature class), and distinguishes itself from sibling tools like 'export_features' by emphasizing creation from scratch with GeoJSON input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('fastest way to MAKE data from scratch'), explains output format selection via 'output_path', and gives context for CRS transformation using a sibling tool. Also clarifies when to set 'geometry_type' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe a dataset: type, spatial reference, extent, fields, row count.
Works on feature classes, shapefiles, rasters, tables, workspaces — anything arcpy.Describe understands.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool produces a description (type, spatial reference, etc.) and works on many dataset types. However, it does not explicitly state that the tool is read-only, has no side effects, or mention performance implications. For a descriptive tool, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences with no wasted words. It front-loads the key output attributes and then expands on supported input types. Very efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema (which covers return structure), the description is largely complete. It explains what the tool does, what inputs it accepts, and what outputs are described. Minor gaps include error handling and behavior for unsupported types, but these are not critical for a basic descriptive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The tool description mentions that it works on various dataset types, indirectly clarifying the 'path' parameter as a dataset path. However, it does not explain valid formats, absolute vs relative paths, or provide examples. The parameter remains underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Describe a dataset' and lists specific attributes (type, spatial reference, extent, fields, row count), making the tool's purpose unambiguous. It also specifies the input types (feature classes, shapefiles, rasters, etc.), distinguishing it from the sibling tool 'describe_gp_tool' which likely describes geoprocessing tools instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where other tools (e.g., 'describe_gp_tool' or 'inspect_project') would be more appropriate. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the syntax and full documentation for a geoprocessing tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool retrieves documentation, implying a read-only operation, but does not explicitly confirm safety, non-destructiveness, or any side effects. Important traits like authentication needs or rate limits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no superfluous words. It directly conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description is not required to detail return values. However, the description is minimal and does not explain the scope of 'full documentation' or how the output is structured. It is adequate but could be more complete, especially given the single required parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter ('tool') with 0% schema description coverage. The description does not explain what the parameter represents (e.g., tool name) or provide any value constraints. This leaves the agent with no semantic guidance for populating the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves syntax and full documentation for a geoprocessing tool. It uses a specific verb ('Get') and resource ('syntax and full documentation'), and it distinguishes itself from sibling tools like 'run_gp_tool' (execution) and 'search_gp_tools' (searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use scenarios, or contrast with sibling tools like 'run_gp_tool' or 'search_gp_tools'. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read vector data (shapefile, feature class, layer) as GeoJSON.
The inverse of create_features — lets you inspect actual geometries and
attributes. Optional where is a SQL where-clause to filter rows
(e.g. "POP > 10000"); limit caps returned features (response says if
truncated). Output coordinates are WGS84.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| where | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses read-only behavior, explains the 'where' clause and 'limit' truncation indication, and notes output coordinates are WGS84. This adds useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus inline parameter clarifications, front-loading the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (4) and the presence of an output schema, the description covers the core purpose, key parameters, and behavioral quirks. It could mention the 'path' parameter format but is adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description adds meaning for 'where' (SQL clause with example) and 'limit' (caps features, truncation indication). However, 'path' and 'timeout_seconds' are not explained, so not all parameters benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads vector data (shapefile, feature class, layer) and outputs GeoJSON. It uses the verb 'read' and specifies the resource, distinguishing it from sibling tools like create_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies it as the inverse of create_features, implying usage for inspecting geometries and attributes. It provides context but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect an ArcGIS Pro project (.aprx): maps, layers, data sources, layouts and default geodatabase.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It describes what the tool inspects but does not state that it is read-only, whether it requires specific permissions, or any side effects. The description is incomplete for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded with the verb and resource. It efficiently summarizes the tool's purpose without extraneous words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one path parameter) and existence of an output schema, the description is mostly adequate. However, it lacks usage guidelines and any context on when to choose this tool over siblings, which reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by specifying that path should point to an .aprx file. However, it does not explain other constraints like format, required extension, or absolute vs relative path, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects an ArcGIS Pro project (.aprx) and lists the components it covers (maps, layers, data sources, layouts, default geodatabase), making the purpose specific and distinct from sibling tools like describe_data or describe_gp_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for inspecting a project but does not mention prerequisites, exclusions, or compare with similar tools like describe_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory a workspace (geodatabase or folder): feature classes, rasters, tables and datasets it contains.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It describes the function as inventorying but does not disclose whether it is read-only, requires authentication, or has side effects. The term 'inventory' suggests read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Clearly communicates the tool's core function. However, it could be restructured to include parameter context or usage tips without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and has an output schema, so description doesn't need to explain return values. However, it lacks usage guidelines and behavioral transparency. Acceptable for a basic tool but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The description mentions 'workspace (geodatabase or folder)' which hints at the 'path' parameter meaning, but does not explain it directly or provide format/constraints. No additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'inventory' and resource 'workspace (geodatabase or folder)', and lists the types of contents (feature classes, rasters, tables, datasets). It distinguishes from siblings like 'describe_data' by focusing on listing contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inventorying workspace contents but provides no explicit guidance on when to use this tool versus alternatives like 'describe_data' or 'inspect_project'. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute Python INSIDE the currently open ArcGIS Pro application.
Unlike arcpy_execute (headless background session), this runs in the live
Pro session the user is looking at: arcpy.mp.ArcGISProject("CURRENT")
works, added layers appear immediately, the open project can be saved.
Requires the user to have cowork mode running — if no listener responds,
the error includes the exact one-liner they must paste into Pro's Python
window. Variables persist between calls (separate namespace from
arcpy_execute). Caution: prefer data/layer/symbology operations; avoid
rapid or repeated view/camera manipulation, which can destabilize Pro.
Pass action as a short human label ("Applying symbology") - it shows in
the user's add-in activity log. House rules: don't create new .aprx files,
maps, layouts or layers unless the user asked; after changing a map or
layout, call its .openView() so the change appears instantly.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| action | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it runs in a live session, requires cowork mode, variables persist between calls, and warns about destabilizing Pro. It also explains error handling (exact one-liner pasting). This is comprehensive for a non-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear sections. It front-loads the main purpose and then provides necessary details. Every sentence adds value, though it could be slightly more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, output schema exists), the description covers most aspects: purpose, usage guidelines, behavioral traits, and parameter semantics. It lacks explicit description of the timeout parameter and return values, but overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'action' parameter usefully (human label for activity log) and implies 'code' is Python code. However, 'timeout_seconds' is not explicitly described. Despite this, the description adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states that the tool executes Python inside the currently open ArcGIS Pro application, differentiating it from arcpy_execute. It explicitly mentions key capabilities like accessing arcpy.mp.ArcGISProject('CURRENT') and immediate layer appearance, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with the sibling tool arcpy_execute (headless vs live), provides caution about avoiding rapid view/camera manipulation, and includes house rules (e.g., don't create new .aprx files unless asked). This offers clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the ArcPy worker process. Clears all session variables and releases any locks/licenses. Use after a hang, crash, or to free state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description details key behaviors: clearing session variables and releasing locks/licenses. Could mention if it terminates running processes or if it's asynchronous, but overall good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. First sentence states action, second adds usage and effects. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no annotations), the description covers purpose, usage, and primary side effects. Could mention output schema briefly, but overall complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially. Description adds no parameter info as none needed, which is appropriate for a 0-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restarts the ArcPy worker process, with specific actions: clears session variables and releases locks/licenses. This distinguishes it from siblings like session_status or run_gp_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after a hang, crash, or to free state. Lacks exclusions or alternatives, but the context is clear given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a geoprocessing tool by name and return its outputs and messages.
tool accepts either the flat name ('Buffer_analysis') or module form
('analysis.Buffer'). Positional parameters go in args, named parameters
in kwargs. Use describe_gp_tool first if unsure of the signature.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| tool | Yes | ||
| kwargs | No | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions returning outputs and messages but does not state whether the tool can modify data, require permissions, or behave destructively. The timeout parameter is mentioned but not its implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers tool naming and parameter usage, and references describe_gp_tool for signature. However, given the complexity of running arbitrary geoprocessing tools, it lacks cautionary info about side effects, prerequisites, or failure behavior. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds essential meaning: explains that tool accepts flat or module names, args for positional parameters, kwargs for named ones. However, it does not describe the timeout_seconds parameter beyond its existence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a geoprocessing tool by name and returns outputs and messages, using specific verb+resource. It distinguishes from sibling describe_gp_tool by advising to use that first for signature uncertainty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to use describe_gp_tool if unsure of the signature, and explains naming conventions. It does not explicitly differentiate from sibling arcpy_execute or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all available geoprocessing tools (including extension toolboxes).
Space-separated terms are ANDed, matched against tool names like 'Buffer_analysis'. Empty query lists everything (up to limit).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses search behavior: terms ANDed, matched against tool names, empty query lists everything up to limit. No annotations provided, so description carries burden; lacks mention of any side effects but search is harmless.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear structure: purpose then usage details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and presence of output schema, description covers essential usage: how to query and what happens with empty query. Fully adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Without schema descriptions (0% coverage), description implies query and limit parameters but does not explicitly define them or their defaults/ranges. Adds some value beyond schema names but not fully compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches all available geoprocessing tools including extension toolboxes, distinguishing it from siblings like run_gp_tool and describe_gp_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on query syntax (space-separated ANDed terms), name matching example, and empty query behavior, but does not explicitly compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the ArcPy session: license level, workspace, live variables. Starts the session if it isn't running yet (first start is slow).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effect that starting the session may be slow, which is key behavioral info. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, and description outlines return contents. Adequately complete for a status check tool with 0 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is trivially 100%. Description adds value by detailing what components are checked (license, workspace, variables).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Check' and resource 'ArcPy session' with concrete aspects (license level, workspace, live variables). Differentiates from siblings like restart_session and arcpy_execute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for checking session state before executing other tools, but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct, with clear descriptions differentiating similar ones like arcpy_execute (headless) and pro_live_execute (live Pro session). Potential confusion between run_gp_tool and arcpy_execute for running tools, but descriptions clarify the structured vs. open-ended usage.
Naming pattern is inconsistent: some tools follow verb_noun (create_features, describe_data), others start with product name (arcpy_execute, pro_live_execute), and one is noun_noun (session_status). The use of underscores and abbreviations (gp) also varies.
With 12 tools covering code execution, data creation/description, project inspection, session management, and tool searching, the count is well-scoped for an ArcPy/ArcGIS Pro server. No tools feel redundant or missing for core functionality.
The surface covers essential operations: code execution, data import/export, metadata inspection, project browsing, and tool running. Minor gaps exist (e.g., no direct update/delete features tool, no raster management), but these are achievable via arcpy_execute, making the set nearly complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
Gives your AI assistant persistent memory and intelligence about your work patterns.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Connects AI assistants to QCDatabase.AI for everyday construction quality-control work.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/thaparSAAB14/ARCclaude'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
