The server lets an AI assistant operate an open ArcGIS Pro project in-place — reading, editing, analyzing, mapping, and exporting your actual ArcGIS data and layouts.
Session & project: ping, inspect ArcGIS/Pro details, save project, list/create/activate maps and map properties, get environments.
Layers & data: list/add/remove/rename/duplicate layers, set visibility/transparency/scale ranges/definition queries, reorder/group, zoom, set basemap, fix broken sources, join tables.
Attributes & editing: read/count features, unique values, statistics, summarize; insert/update/delete rows, save/discard edits, calculate fields.
Selections: select by SQL or location, get/set/clear selections, zoom to selection.
Schema creation: add/delete/alter fields, create feature classes/tables/geodatabases, truncate/delete datasets, export features.
Geoprocessing: run any ArcGIS geoprocessing tool by name with named parameters, list/describe tools, run custom toolbox tools, check extensions, retrieve messages.
Symbology & labels: set simple/unique-value/graduated renderers, color ramps, labels, copy symbology, save .lyrx files.
Map views & bookmarks: get/set camera, export map view as PNG, create/apply/delete bookmarks.
Layouts & printing: create/delete layouts, add map frames/text/legends/scale bars/north arrows/pictures, position elements, export to PDF/PNG/JPEG/SVG/TIFF, preview layouts, export map series.
Raster analysis: get raster info, set raster symbology, raster calculator, sample values, zonal statistics.
Data discovery: list geodatabase/folder contents, describe datasets, search data by name, manage folder connections.
Escape hatch: execute arbitrary arcpy Python code, run batched commands, and manage the Python bridge dispatcher.
Controls a live ArcGIS Pro session, allowing AI assistants to manage layers, run geoprocessing tools, adjust symbology, export maps, and execute arcpy code.
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., "@ArcGIS Pro MCP List all layers in the current map"
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 ArcGIS Pro add-in that lets you say what you want.
It implements the Model Context Protocol inside ArcGIS Pro itself, so an AI assistant — Claude, Codex, Antigravity, or any other MCP client — can work on the project already open in front of you. Your data, your maps, your layouts. Not a copy, not an export.
Install the add-in, click the button for the assistant you use, done. No config files to find, no JSON to hand-edit, no Python to install.
In any language your assistant speaks. Your assistant does the
understanding; this add-in never matches on English keywords. Non-English text
travels intact in both directions, so a query can name a place in Thai and get
Thai back — PROV_NAMT LIKE '%เชียง%' returns เชียงใหม่ and เชียงราย.
"Style the provinces by area, pastel red through green"
"Which province has the highest population? Put the answer in a new field"
"Export the current map view as a PNG and show me""ระบายสีจังหวัดตามขนาดพื้นที่ ไล่จากแดงพาสเทลไปเขียว"
"จังหวัดไหนมีประชากรมากที่สุด ใส่คำตอบไว้ในคอลัมน์ใหม่"
"ส่งออกมุมมองแผนที่ปัจจุบันเป็น PNG แล้วเอามาให้ดู"The aim is the whole of ArcGIS Pro, not a convenient corner of it. A request falls through three layers, and takes the fastest one that can answer it:
1 | 112 named tools, written in C# | Layers, attributes, selections, symbology, layouts, rasters, editing — the work of an ordinary day. 109 of them execute inside ArcGIS Pro's own process, in about 9 ms each. |
2 | Every geoprocessing tool |
|
3 | Arbitrary arcpy |
|
Layers 1 and 2 need nothing but the add-in. Layer 3 runs through an optional Python bridge inside ArcGIS Pro's own Python — install it when you want the escape hatch, skip it and the first two still work. A command the add-in does not implement is forwarded there automatically; if it is not running, the error says so and how to start it, rather than failing obscurely.
The practical effect is that there is no such thing as "the tool for that is missing". If it can be done in ArcGIS Pro, it can be asked for in a sentence.
Every frame above was rendered by the add-in itself, running the request in
the caption. Rebuild it with python scripts/make_demo_gif.py.
Get it from the latest release and pick one of the two files.
Download
ArcGISProMCP.esriAddinX
and double-click it. ArcGIS Pro's own installer takes it from there. Restart
Pro and the MCP tab appears.
Install-ArcGISProMCP.cmd
is one self-contained file — the add-in is inside it, so there is nothing else
to download.
Double-click it, or run it from a prompt. It is a .cmd, not a .ps1, so
Windows' script execution policy never gets in the way.
Use this one when Pro loads the add-in but the MCP tab never appears: some machines have add-in security turned on, and the add-in alone cannot say so. The installer checks, tells you which of the two states it found, and offers the fix. Run it a second time and it offers to uninstall.
Requires ArcGIS Pro 3.3+. Nothing else — no Python, no SDK, no admin rights.
The same two files are also committed to
dist/, which is
the build the current source produces. Between releases it can be ahead of the
latest release — a fix that is committed but not yet tagged will be there first.
They are committed rather than left as build output because GitHub Actions has no ArcGIS Pro to build against: a build only exists if someone with Pro installed produces it. Committing it keeps a download beside the source that made it.
Take the release unless you have a reason to want something newer than it.
Run the installer again and answer yes, or:
Install-ArcGISProMCP.cmd -UninstallIt removes every copy it finds, including the one ArcGIS Pro's own installer
unpacks into a folder named after the add-in id. The .esriAddinX cannot
uninstall anything — double-clicking it only ever installs. The other way is
ArcGIS Pro itself: Project ▸ Add-In Manager ▸ Delete this Add-In.
Related MCP server: arcpro-mcp
Open the MCP tab in ArcGIS Pro and click your assistant — the three most used are on the ribbon, the rest are under More clients.
Icon | Meaning |
✓ green | that client already has the server — click to remove it |
⊕ grey | click to add it |
greyed out | that client is not installed |
It asks before changing anything, tells you which file it will write, and backs that file up first.
Supported: Claude Code, Codex, Antigravity, VS Code, Cursor, Cline, Gemini CLI, Claude Desktop.
Most clients connect over HTTP:
claude mcp add --transport http arcgis http://127.0.0.1:6520/mcp{ "mcpServers": { "arcgis": { "type": "http", "url": "http://127.0.0.1:6520/mcp" } } }Antigravity wants serverUrl instead of url and no type.
Codex and Claude Desktop launch a server rather than connecting to one, so they need the Python relay. It is not on PyPI yet; install it from this repository:
pip install git+https://github.com/Knight60/ArcGIS-Pro-MCPThat puts arcgis-pro-mcp.exe on your PATH, which is what those two clients
should be pointed at. The ribbon buttons do this for you and will say so if the
relay is missing.
The bridge lives inside ArcGIS Pro, so Pro has to be open. Close it and the client's connection goes red.
One button starts and stops, the way a play button does: the icon shows what the next click will do, so it doubles as the state readout. Green ▶ means stopped, red ⏹ means running.
Status shows a green broadcast while listening and a contained grey dot when not, with the port as its caption. Click it for the full report: requests served, which clients are connected, and the last error.
112 tools. Anything not listed is still reachable through run_geoprocessing_tool or execute_arcpy_code.
Tool | What it does |
| Check that the ArcGIS Pro bridge is reachable and see which project it is attached to |
| List every command the connected bridge supports, grouped by area |
| Self-check the connection: ArcGIS Pro version, licence, open project, active map, open map view and write access |
| ArcGIS Pro version, licence level, available extensions and the current project path |
| Project paths, default geodatabase and toolbox, maps, layouts, folder and database connections |
| Save the ArcGIS Pro project (.aprx), or save a copy elsewhere |
| List all maps and scenes with coordinate system and layer counts |
| Create a new map or scene in the project |
| Delete a map from the project |
| Open/activate a map's view in the ArcGIS Pro UI |
| Rename a map or change its coordinate system |
| The combined extent of all data layers in a map |
| Read the current arcpy geoprocessing environment settings |
| Set arcpy geoprocessing environment settings such as workspace, outputCoordinateSystem, extent, mask, cellSize, overwriteOutput or parallelProcessingFactor |
Tool | What it does |
| List the layers (with draw order and group nesting) and standalone tables in a map |
| Full detail for one layer: data source, coordinate system, extent, fields, feature count, renderer and label state |
| Add data to a map from a path or service URL: feature class, shapefile, raster, table, .lyrx layer file or web service |
| Add a web service layer (Feature/Map/Image service, WMS, WMTS, vector tile) by URL |
| Remove a layer or standalone table from a map |
| Rename a layer in the table of contents |
| Copy a layer within the map so it can be symbolised differently |
| Show or hide one layer, several layers, or every layer in the map |
| Set layer transparency (0 = opaque, 100 = fully transparent) |
| Limit the scale range a layer draws at |
| Set a layer's definition query (SQL where clause) |
| Reorder a layer relative to another, or move it into a group layer |
| Create a group layer, optionally moving existing layers into it |
| Zoom the map view to a layer's extent |
| Set the basemap: Topographic, Imagery, Imagery Hybrid, Streets, Navigation, Light Gray Canvas, Dark Gray Canvas, Terrain, Oceans, OpenStreetMap, National Geographic Style Map |
| List layers across all maps whose data source is missing |
| Repoint a layer at a new workspace or dataset to fix a broken source |
| Join a table to a layer on a common field |
| Remove a join from a layer |
Tool | What it does |
| Read attribute rows from a layer, table or dataset path, with an optional where clause, field subset, ordering and WKT geometry |
| Count features, optionally matching a where clause |
| Distinct values of a field with the count of rows for each |
| min / max / mean / median / sum / standard deviation of a numeric field |
| Group rows by one or more fields and aggregate -- the fast way to answer 'how many / how much per category' without geoprocessing |
| Insert new rows into a layer or table |
| Update attributes and/or geometry of rows matching a where clause |
| Delete rows matching a where clause |
| Commit pending edits |
| Throw away pending edits |
| Calculate field values across a layer, e.g |
Tool | What it does |
| Select features by SQL where clause |
| Select features by spatial relationship to another layer |
| Report what is currently selected, per layer, with ObjectIDs and optionally the attribute rows |
| Select specific features by ObjectID |
| Clear the selection on one layer, or on every layer in the map |
| Zoom the map view to the currently selected features |
Tool | What it does |
| List a layer's fields with type, alias, length and domain |
| Add a field to a layer or table |
| Add several fields in one call |
| Delete one or more fields |
| Rename a field or change its alias/length |
| Create an empty feature class, by default in the project's default geodatabase, and add it to the map |
| Create an empty standalone table |
| Create a new file geodatabase |
| Delete every row from a table or feature class, keeping the schema |
| Delete a dataset from disk or a geodatabase |
| Export a layer -- honouring its current selection and definition query -- to a new dataset |
Tool | What it does |
| Run any arcpy geoprocessing tool -- the universal escape hatch for analysis |
| Search the available geoprocessing tools by name |
| List the arcpy toolbox modules and any toolboxes in the project |
| Get a tool's parameters, data types, defaults and usage text before running it |
| Run a tool from a custom .pyt / .atbx / .tbx toolbox on disk |
| Check, and optionally check out, an ArcGIS extension licence |
| Messages from the most recent geoprocessing operation |
Tool | What it does |
| Change a layer's symbology: a single symbol, unique values by category, or a classified/continuous colour scheme by numeric field |
| Inspect a layer's current renderer, class breaks, unique values and label settings |
| List the colour ramps available in the project |
| Turn labels on or off and set the expression, font and halo |
| Copy symbology from a .lyrx file or another layer |
| Save a layer with its symbology to a .lyrx file for reuse |
Tool | What it does |
| Current camera position: centre, scale, rotation and visible extent |
| Move the map view: set an extent, a centre point, a scale and/or a rotation |
| Render the map view to PNG and return the image so it can be looked at -- the way to visually check a map |
| List the spatial bookmarks defined on a map |
| Save the current view, or a given extent, as a named bookmark |
| Zoom the map view to a bookmark |
| Delete a bookmark from a map |
Tool | What it does |
| List the print layouts with page size and element counts |
| Inspect a layout: page setup and every element with position and size |
| Create a new layout page, by default with a map frame filling it |
| Delete a layout from the project |
| Add a map frame to a layout at a page position |
| Point a layout's map frame at a layer, an extent or a scale |
| Add a text element such as a title or credits to a layout |
| Add a legend tied to a layout's map frame |
| Add a scale bar tied to a layout's map frame |
| Add a north arrow tied to a layout's map frame |
| Place an image such as a logo on a layout |
| Move, resize, rename, hide or change the text of any layout element |
| Remove an element from a layout |
| Export a layout to PDF / PNG / JPEG / SVG / TIFF |
| Render a layout to a temporary image and return it, without writing a file -- use it to visually check a layout while building it |
| Export a layout's map series (map book) to a multi-page PDF |
Tool | What it does |
| Raster detail: bands, size, cell size, pixel type, statistics and CRS |
| Set a raster layer's colorizer and colour ramp |
| Map algebra |
| Read raster cell values at map coordinates or at a point layer's features |
| Summarise raster values inside zone polygons and return the table |
Tool | What it does |
| List the datasets inside a geodatabase or folder |
| List GIS files and subfolders on disk |
| Describe any dataset by path -- type, geometry, CRS, extent, fields and row count -- without adding it to a map |
| Find datasets by name across the project's geodatabase, home folder and folder connections |
| Folder connections, database connections and toolboxes registered in the project |
| Register a folder with the project so its data is easy to browse |
Tool | What it does |
| Run Python inside ArcGIS Pro |
| Whether the main-thread dispatcher is installed |
| Remove the main-thread dispatcher |
| Run several commands in one round trip -- much faster for multi-step workflows |
⚠️ = changes or deletes real data 🖼️ = returns an image the AI can look at
No MCP tab after restarting Pro. Add-in security is the usual cause.
Run Install-ArcGISProMCP.cmd; it will say so and offer the two ways round it.
The setting itself is in ArcGIS Pro under Project ▸ Add-In Manager ▸
Options:
The middle setting is the one this add-in is signed for. The bottom one loads anything. What each choice means.
The client shows the server in red. ArcGIS Pro is closed, or the bridge is stopped. Open Pro and check the toggle on the MCP tab shows ⏹ (running).
A command says a layer does not exist. Layers inside a group need their
full name, "Group\Layer", for anything that runs through geoprocessing.
An edit did not appear. ArcGIS Pro holds edits open so they can be undone,
which also keeps the data locked. Call save_edits.
These tools change the project you have open and the data under it. Tools marked ⚠️ above modify or delete real data.
The bridge binds to 127.0.0.1 only — nothing on the network can reach it —
but anything that can run code on your machine can drive ArcGIS Pro through it
while Pro is open. execute_arcpy_code runs arbitrary Python inside Pro.
Prefer non-destructive steps, use save_project deliberately, and let the
assistant confirm before bulk edits.
An ArcGIS Pro add-in written in C#, running inside Pro's own process:
AI client ──MCP over HTTP :6520/mcp ─┐
│
AI client ──MCP stdio──► arcgis-pro-mcp ──TCP :6510──┐
│ │
▼ ▼
┌─ C# add-in (inside the ArcGIS Pro process) ─┐
│ → QueuedTask.Run (Main CIM Thread) │
│ anything it does not implement ─┐ │
└───────────────────────────────────┼─────────┘
▼ :6511
Python bridge (execute_arcpy_code)Being in-process is the whole point. ArcGIS Pro will only let its own Main CIM
Thread touch the open project, and an outside process cannot get onto it. An
earlier all-Python version had to hand work to Pro's Python thread and wait,
which took around 28 seconds per call. The add-in uses QueuedTask.Run
directly: 9 ms.
Three of the 112 tools stay on the Python side, and belong there:
execute_arcpy_code, because a compiled add-in cannot run code composed at
call time, and get_pump_status / stop_pump, which report on the Python
bridge's own dispatcher.
More detail in docs/.
You do not need to — the release is a single download. If you want to change something, see BUILD.md.
.\scripts\build.ps1Everything used to produce a release is in this repository: the build, the signing, the icon drawing, and the installer that gets packed into one file.
Built by Pisut Nakmuenwai (@Knight60).
Dual licensed.
AGPL-3.0 — free, and free to keep. Use it for your own work, paid or unpaid, on as many machines as you like. Modify it. Build on it. The one condition is reciprocal: if you pass on a work built from this one, or run it as a service other people use, those people get its source under the same terms.
Commercial — for shipping it inside a product you do not publish the source of, hosting it in a closed service, or redistributing it under your own name.
Doing GIS work with it and delivering the maps and analysis is ordinary use, not distribution. Most people never need the second licence; the details say where the line falls, and asking is free.
Releases up to v1.0 were MIT and stay MIT — that grant cannot be withdrawn. The dual licence applies from v1.1. NOTICE carries the copyright and an AGPL Section 7 permission for linking with the ArcGIS Pro SDK.
Built and maintained in the open, with no company behind it.
If it saves you time, sponsoring it helps keep it working. Most of the ongoing effort is not new features but keeping up with ArcGIS Pro: every release can move the framework it targets and shift the parameter order of its two thousand geoprocessing tools, and each one means regenerating that table and testing the whole surface again.
Starring the repository costs nothing and helps other people find it. So does telling me what broke — a clear issue is worth a great deal.
This software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall the author or copyright holder be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from or in connection with the software or its use. The full terms are in LICENSE.
Two properties of this software deserve stating plainly rather than being left to the licence, because they are what it is for rather than defects in it:
It executes commands against a live ArcGIS Pro session, including operations that permanently alter or delete datasets, project files, and geodatabase contents. The tools marked ⚠️ in the table above are the ones that do so.
Those commands are issued by an AI assistant, whose output is not
deterministic and is not reviewed before it runs. execute_arcpy_code
executes arbitrary Python inside ArcGIS Pro with the privileges of the
signed-in user.
You remain responsible for your data and for the consequences of any operation performed through this software. Back up anything you cannot afford to lose, work on copies where practical, and verify results before relying on them. Use against production data, or against data you cannot restore, is entirely at your own risk.
This project is an independent work. It is not affiliated with, endorsed by, sponsored by, or supported by Esri, and it is not a supported ArcGIS product. ArcGIS and ArcGIS Pro are trademarks of Esri. Your use of ArcGIS Pro remains governed by your own licence agreement with Esri, and nothing here modifies it.
Add a field to a layer. field_type: TEXT, LONG, SHORT, DOUBLE, FLOAT, DATE, GUID, BLOB.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| field_name | Yes | ||
| field_type | No | TEXT | |
| layer_name | Yes | ||
| field_alias | No | ||
| field_length | No |
| 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 supply safety and behavioral context. It only states 'Add a field' without disclosing permissions, failure modes, or whether the operation is reversible. For a mutation tool, this is insufficient.
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 short and to the point, with a clear first sentence and a list of types. No unnecessary words, though it could benefit from a structured overview of parameters.
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?
For a tool with 6 parameters and no annotations, the description is too minimal. It omits return values (despite output schema), prerequisites, and behavior on failure. An agent would lack critical context for correct 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?
Schema description coverage is 0%, so the description must compensate. It explains field_type with valid values, but ignores other 5 parameters (map_name, field_name, layer_name, field_alias, field_length), leaving their meaning and usage unclear.
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 action (add a field) and the target (a layer). It lists valid field types, but does not explicitly distinguish from sibling tools like delete_field or calculate_field, which is acceptable given the uniqueness of the action.
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 guidance on when to use this tool versus alternatives (e.g., calculate_field for computed fields). No prerequisites, such as requiring the layer to exist, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add data to a map by path or URL: feature class, shapefile, raster, .lyrx layer file, or web service URL.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| map_name | 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 only states the operation is additive but does not describe error handling (invalid path, existing layer), authorization needs, side effects, or what happens if the map_name is missing. The minimal information leaves the agent underinformed about the tool's behavior.
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, front-loaded sentence that efficiently conveys the core purpose and supported data sources. No unnecessary words, but it sacrifices completeness for brevity.
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 does not need to explain return values, but it fails to cover prerequisites (map must exist, project open) and error cases. For a mutation tool, this incomplete context could lead to invocation failures.
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 mentions that 'path' can be a URL or file path and lists data types, but it does not explain the format, examples, or the purpose of 'map_name' (default behavior, active map assumption). The description adds limited value beyond the parameter names.
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 action ('Add data to a map') and specifies supported data types (feature class, shapefile, raster, .lyrx layer file, web service URL) and sources (path or URL). This distinguishes it from sibling tools like 'remove_layer' or 'create_feature_class'.
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: when you have a path or URL to data to add to a map. It lists supported formats, providing context. However, it does not explicitly state when not to use this tool (e.g., if the map doesn't exist) or mention alternatives like 'create_feature_class' for creating new data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate field values, e.g. expression "!AREA! / 10000". expression_type: PYTHON3, ARCADE, SQL.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| expression | Yes | ||
| field_name | Yes | ||
| layer_name | Yes | ||
| expression_type | No | PYTHON3 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the expression types and gives an example, but does not mention that the operation modifies data (likely destructive), overwrites existing values, or any error conditions. Important behavioral traits like irreversibility 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 very short (one sentence plus an example), which is concise, but it could be better structured. It includes the example and expression types, but does not front-load the main action. The lack of structure reduces clarity.
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 has 5 parameters (3 required), no annotations, and the description is minimal, it is incomplete. The output schema exists but the description does not leverage it. Behavioral context (e.g., destructive nature) is missing. The tool modifies data, requiring more explanation than provided.
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%, meaning the description adds no explanation for parameters. It only mentions 'expression' and 'expression_type' implicitly, but does not explain 'map_name', 'field_name', or 'layer_name'. The schema provides the names, but the description fails to add meaning or context for these parameters.
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 calculates field values using expressions, provides an example of the expression syntax, and lists the supported expression types (PYTHON3, ARCADE, SQL). This effectively communicates the core purpose and distinguishes it from sibling tools like execute_arcpy_code that run arbitrary code.
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 guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, limitations, or when not to use it (e.g., for non-numeric fields or feature classes without a schema). The description lacks context for selecting the appropriate expression type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the selection on one layer, or on all layers if layer_name is omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| layer_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses basic behavior: clears selection, optional layer_name. No annotations exist; no extra context on permissions, side effects, or return values.
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, 14 words, front-loaded with action. 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?
Simple operation with optional parameters; mostly adequate. Minor gap: map_name not explained, and output schema exists but no return value description needed.
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 has 0% description coverage. Description only explains layer_name and its omission behavior; map_name is not mentioned at all. Insufficient for a 2-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?
Clearly states the verb 'clear', resource 'selection on a layer', and scope (one layer or all layers if omitted). Differentiates from sibling tools like select_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?
Tells when to use: clearing selection on one or all layers. Implied when not to use for other operations like selecting features, but no explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new feature class (default: in the project's default geodatabase). geometry_type: POINT, MULTIPOINT, POLYLINE, POLYGON.
| Name | Required | Description | Default |
|---|---|---|---|
| epsg | No | ||
| name | Yes | ||
| map_name | No | ||
| out_path | No | ||
| add_to_map | No | ||
| geometry_type | No | POLYGON |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It mentions the default location and geometry type options but omits critical details like what happens if the name already exists, whether overwrite is allowed, required permissions, or side effects. This is insufficient for a 6-parameter creation 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 very short (26 words), which is efficient but at the cost of missing necessary information. It is front-loaded with the key action and default, but lacks structure for parameter details or usage guidance. It could be slightly longer to include critical parameter hints without being verbose.
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 has 6 parameters, no output schema documentation, and no annotations, the description is severely incomplete. It covers only the geometry type and default location, leaving out behavior for name conflicts, coordinate system, map association, and output path. An output schema exists but is unhelpful without description.
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 explain parameters. It only provides semantics for geometry_type (listing valid values). Other parameters like epsg, map_name, out_path, and add_to_map are unexplained, leaving the agent to guess their meaning or format. This adds minimal value beyond the bare 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?
The description clearly states the tool creates a new feature class, specifies the default location as the project's default geodatabase, and lists the valid geometry types (POINT, MULTIPOINT, POLYLINE, POLYGON). This is specific and distinguishes it from sibling tools like add_field or create_map, which have different purposes.
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, such as when to create a feature class vs. use run_geoprocessing_tool or add_layer. There are no explicit when-to-use or when-not-to-use conditions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new map in the project. map_type: MAP or SCENE.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| map_type | No | MAP |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the basic action, omitting details like whether the map is added to the current project, duplicate handling, or any special requirements.
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 concise with two sentences, no redundancy. However, it could be slightly more informative without being verbose.
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 presence of an output schema and a create operation, the description should explain return values, side effects, or integration with the project. It lacks these details, making it insufficient for a complete understanding.
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%, so the description must compensate. It adds meaning for map_type by specifying 'MAP or SCENE', but name parameter is not elaborated beyond the schema. Partial compensation.
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 verb 'Create' and resource 'new map in the project', and mentions the map_type parameter accepting MAP or SCENE, distinguishing it from sibling tools like list_maps or export_map_view.
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 guidance is provided on when to use this tool versus alternatives, nor any prerequisites or limitations. The description implies creation without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a field from a layer.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| field_name | Yes | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose side effects such as permanent data loss, permissions required, or impact on dependent features.
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?
Extremely concise (6 words) but lacks essential details, making it under-specified rather than efficiently informative.
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 (delete operation with 3 params and an output schema), the description is too sparse. Does not describe return value, behavior, or cancellation effects.
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 should explain each parameter, but it only mentions 'layer' implicitly. No explanation of map_name, field_name, or their roles.
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 uses the specific verb 'Delete' and identifies the resource 'field from a layer', clearly distinguishing from sibling tools like add_field and calculate_field.
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 guidance on when to use this tool versus alternatives or prerequisites. Does not mention that the field must exist or that deletion is irreversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute arbitrary Python code inside ArcGIS Pro (arcpy is pre-imported; use arcpy.mp.ArcGISProject('CURRENT') for the open project). Use print() to return output. Use this when no dedicated tool covers the task.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions arcpy pre-imported and print() for output, but does not address error behavior, side effects, security restrictions, or limits. Incomplete.
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 core functionality and context, no filler. Every sentence adds value.
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?
For a code execution tool with one parameter and an output schema, description covers the essential context: pre-imported arcpy, project access hint, and output method. Could mention error handling but sufficient.
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?
Single parameter 'code' is well-described: it is arbitrary Python code, arcpy is pre-imported, and output is via print(). Schema coverage 0% so description compensates well, though lacks constraints or examples.
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 explicitly states the tool executes arbitrary Python code in ArcGIS Pro with arcpy pre-imported, and distinguishes from siblings by saying 'use this when no dedicated tool covers the task.'
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 to use when no dedicated tool exists, and includes a specific hint about accessing the current project. Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a layout to PDF/PNG/JPEG/SVG (format inferred from the file extension). Relative paths are resolved against the project home folder.
| Name | Required | Description | Default |
|---|---|---|---|
| dpi | No | ||
| layout_name | Yes | ||
| output_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that format is inferred from file extension and relative paths are resolved against project home. However, it omits critical behaviors like overwrite policy, error handling, or whether the operation is destructive.
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. No extraneous words. Efficiently communicates core function and two key details.
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 no annotations and the presence of a sibling tool (export_map_view), the description is adequate for a simple export but lacks completeness on return values, overwrite behavior, and error conditions. Covers essential purpose but leaves gaps.
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%, so the description must compensate. It adds meaning to output_path by stating format is inferred from extension, but does not explain dpi (default 200) or layout_name. Only one parameter partially explained.
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 explicitly states the tool exports a layout to common image formats (PDF/PNG/JPEG/SVG) with format inferred from file extension, clearly identifying the action and resource. It distinguishes from the sibling tool 'export_map_view' by specifying 'layout'.
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 (e.g., export_map_view), no prerequisites, and no conditions for when not to use it. It only mentions relative path resolution but lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export the map view to a PNG image (useful as a visual check of the map).
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| height | No | ||
| map_name | No | ||
| output_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for disclosing behavior. It mentions exporting to PNG but does not address potential side effects, file size, or whether it requires a specific map view state. No annotation contradictions exist.
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 short sentence that communicates the core purpose efficiently. It is front-loaded with key information, but the brevity sacrifices completeness.
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 lacks context for the four parameters, the existence of multiple maps (map_name), and comparison with sibling export_layout. The output schema exists but is not leveraged by the description.
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 no semantic value for any of the 4 parameters (width, height, map_name, output_path). Schema description coverage is 0%, and the description fails to explain these inputs.
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 verb 'export', the resource 'map view', the output format 'PNG image', and the use case 'visual check'. This distinguishes it from sibling tools like export_layout (different export target) and get_layer_info (information retrieval).
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 does not provide explicit guidance on when to use this tool versus alternatives like export_layout or zoom_to_layer. It implies use for visual checks but offers no when-not or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ArcGIS Pro version, license level, and current project path.
| 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, so description carries full burden. It explicitly lists returned info and implies read-only behavior via 'Get'. Could mention no side effects, but adequate.
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 with all essential info, no fluff. Front-loaded verb and resource.
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?
For a zero-parameter read-only tool with an output schema, description is sufficient. Lists all returned items; no missing context.
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, so baseline 4 applies. Description adds value by specifying what the tool returns, though not strictly about parameters.
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 it retrieves specific ArcGIS Pro info (version, license level, project path). It distinguishes from siblings that operate on fields, layers, or execute code.
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 vs alternatives, but the purpose is self-evident: use to get basic environment info. With zero parameters and no side effects, the need for guidance is minimal but not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read features from a layer as attribute rows. Optional SQL where clause and field list. include_geometry adds WKT geometry (can be large).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| where | No | ||
| fields | No | ||
| map_name | No | ||
| layer_name | Yes | ||
| include_geometry | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it's a read operation ('Read') and warns that include_geometry can produce large WKT data. With no annotations, it partially covers behavioral traits but lacks details on error handling, rate limits, or state changes beyond the read nature.
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 concise (two sentences) and front-loaded with the core action. Every word adds value; no fluff or redundant 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 has 6 parameters and an output schema, the description covers the main functionality but omits context for limit (default and behavior) and map_name. It adequately avoids duplicating output schema information.
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 meaning for where (optional SQL clause), fields (optional field list), and include_geometry (adds WKT). However, it does not explain limit, map_name, or layer_name, thus compensating only partially.
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 verb 'Read' and the resource 'features from a layer as attribute rows'. It specifies optional SQL where clause and field list, making the purpose distinct from sibling tools like select_features or get_layers.
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 reading features with optional filtering, but does not explicitly state when to use this tool versus alternatives (e.g., select_features, get_layers). No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get min/max/mean/sum/std of a numeric field (plus count and null count).
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| map_name | No | ||
| layer_name | 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 the full burden. It discloses the specific computed statistics (min, max, mean, etc.), which is the primary behavior. It does not mention side effects, but none are expected; the tool is clearly read-only. The description is transparent about what it returns.
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 sentence that efficiently conveys the core functionality without unnecessary words. It is well front-loaded with the key statistics.
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?
Although the description is brief, the presence of an output schema (not shown) reduces the need to detail return values. The description covers the essential statistics and mentions both count and null count. However, it could be more complete by explicitly stating the field must be numeric and explaining the optional map_name parameter. Overall, it is adequate for a simple statistics 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?
Schema description coverage is 0%, yet the description only adds meaning for the 'field' parameter (implying it must be numeric). The 'layer_name' and 'map_name' parameters are not described at all, leaving their roles unclear. This is insufficient compensation for the lack of schema descriptions.
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 specifies the verb 'Get' and the resource 'min/max/mean/sum/std of a numeric field (plus count and null count)'. It distinguishes from siblings like 'calculate_field' (which modifies) and 'get_unique_values' (which returns distinct values), 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 implies the tool is for numeric fields but does not explicitly state when to use it vs alternatives like 'get_features' or 'get_layer_info'. No guidance on prerequisites or exclusions is provided, though the context is clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get layer details: source, spatial reference, extent, fields, feature count.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as performance implications, required permissions, or side effects. It only lists return attributes.
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 sentence that is direct and front-loaded with the key action and output. It is appropriately concise but could be expanded slightly without becoming verbose.
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 has 2 parameters, 0% schema coverage, no annotations, and an output schema not shown, the description fails to provide sufficient context for correct usage. The list of return attributes helps but is incomplete without parameter guidance.
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%, and the tool description does not explain the meaning or format of the two parameters ('map_name', 'layer_name'). The agent must guess their roles.
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 'Get layer details' and enumerates specific details (source, spatial reference, extent, fields, feature count). This effectively distinguishes it from sibling tools like 'get_features' or 'get_layers'.
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 lacks any guidance on when to use or not use this tool. No mention of alternatives or prerequisites, leaving the agent 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.
List layers and standalone tables in a map (default: active map).
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | 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 carry the full burden. It states that the tool lists items and defaults to the active map, but lacks details on edge cases (e.g., invalid map name, empty map) or any potential side effects. It is adequate for a simple read-only operation.
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, efficient sentence with no wasted words. It is appropriately sized and front-loaded with the core action.
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 (one optional parameter, output schema provided), the description is complete enough. It covers the primary action and default behavior, and the output schema handles return value documentation.
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 schema coverage is 0%, but the description adds value by explaining the default behavior for the optional map_name parameter ('default: active map'). This provides meaning beyond the schema's default of null. However, it does not specify the expected format or any constraints.
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 lists layers and standalone tables in a map, with a default to the active map. It uses a specific verb ('list') and resource ('layers and standalone tables') and distinguishes it from sibling tools like add_layer or remove_layer.
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 viewing layers and tables in a map, but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current project details: path, default geodatabase, maps, layouts.
| 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, and description only states basic read operation without disclosing any behavioral traits like side effects, permissions, or performance characteristics.
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, front-loaded with verb and subject, no filler words. Concise and 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?
For a zero-parameter tool with an output schema, the description sufficiently lists the returned items and context. Complete given low complexity.
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 (0), so baseline 4 applies. Schema coverage is 100% vacuously. Description adds no param details, but none needed.
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 explicitly states 'Get current project details' and lists specific items (path, default geodatabase, maps, layouts). Clearly distinguishes from sibling tools like get_layer_info or get_arcgis_info.
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?
Description implies use for project-level details but provides no explicit guidance on when to choose this tool over siblings. No when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raster layer details: bands, size, cell size, pixel type, statistics.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| layer_name | 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 the full burden. It states the tool retrieves details but does not disclose read-only nature, prerequisites, error behavior, or any side effects. The behavior is implied but not transparent.
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 sentence with no superfluous words. It is front-loaded with the core action and lists specific details efficiently. 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?
The description covers the tool's return value (raster details) adequately given the presence of an output schema. However, it lacks context about parameter roles, scope (only raster layers), and limitations. It is minimally complete but not thorough.
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%, yet the description does not mention or explain any parameters (map_name, layer_name). It adds no semantic meaning beyond what parameter names imply, leaving the agent to infer usage.
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 uses the specific verb 'Get' and identifies the resource as 'raster layer details', listing concrete attributes (bands, size, cell size, pixel type, statistics). This clearly distinguishes it from sibling tools like get_layer_info, which may return general layer info.
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 obtaining raster metadata but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. It does not differentiate from siblings like get_layer_info or get_features.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the distinct values of a field.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| limit | No | ||
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic operation. It omits details such as whether the tool is read-only, the impact of the 'limit' parameter, supported field types, or any edge cases. With no annotations, the description should fully disclose behavior but fails to do so.
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 sentence, which is concise and front-loaded. However, it is overly brief and lacks essential information, making it inadequate. It earns points for conciseness but loses for sacrificing completeness.
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 (4 parameters, no annotations, 0% schema coverage), the description is far from complete. Even with an output schema, critical aspects like parameter usage, default behavior, and limitations are missing. The description does not enable correct tool 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?
With 0% schema description coverage, the description must explain parameters. It only mentions 'field' implicitly. The 'limit', 'map_name', and 'layer_name' parameters are not described. The description adds no meaning beyond what the parameter names themselves imply.
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 action ('Get') and the resource ('distinct values of a field'). It is specific and accurate. However, it does not differentiate this tool from siblings like 'get_field_statistics' or 'get_features', which are related but distinct.
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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it. The agent receives no help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available geoprocessing tools, e.g. wildcard "_analysis" or "Clip".
| Name | Required | Description | Default |
|---|---|---|---|
| wildcard | 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 bears full responsibility for behavioral disclosure. It mentions listing tools but does not state whether the operation is read-only, what permissions are needed, or any potential side effects.
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 sentence with an example, conveying the core functionality efficiently without extraneous words. It is front-loaded with the action and resource.
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 tool has an output schema (not shown), so description of return values is not required. However, the description could be more complete by explicitly stating that it returns a list of tool names, rather than just giving examples.
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 schema gives the 'wildcard' parameter with a default of '*', but no description. The tool description adds meaning by providing examples like '*_analysis' and 'Clip*', which clarify the pattern-matching behavior.
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 verb 'List' and the resource 'available geoprocessing tools', with an illustrative example using wildcards. It effectively distinguishes from siblings like 'run_geoprocessing_tool' by focusing on listing rather than execution.
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 guidance on when to use this tool versus alternatives such as 'get_arcgis_info' or 'list_layouts'. The description lacks context about appropriate scenarios or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List print layouts in the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies read-only behavior (listing) but does not elaborate on effects or requirements beyond the basic purpose. With no annotations, this minimal transparency is adequate for a simple listing 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 a single, complete sentence with no unnecessary words. It efficiently conveys the tool's purpose.
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, the description is mostly complete. The existing output schema covers return details. However, mentioning that it operates on the current project would add context.
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 are no parameters, and schema coverage is 100%. The description does not need to add parameter semantics; baseline score of 4 applies.
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's action ('List') and resource ('print layouts') with scope ('in the project'), effectively distinguishing it from sibling tools like 'export_layout' or 'get_layers'.
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 guidance is provided on when to use this tool versus alternatives, such as 'export_layout' for exporting layouts. The description only states what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all maps in the project with spatial reference and layer counts.
| 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 are provided, so the description carries full burden. It states basic behavior: listing maps with spatial reference and layer counts. However, it does not disclose any potential side effects, permissions, or return format details. The behavior is simple and read-only, so a moderate score is appropriate.
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, concise sentence that clearly communicates the tool's purpose without extraneous information. It is 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 no parameters, the presence of an output schema, and the simple nature of listing maps, the description is sufficient. It could be slightly more complete by stating that the project must be open, but it provides enough context for an agent to understand what the tool does.
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 are no parameters, and schema coverage is 100%. The description adds value by specifying what information the list includes (spatial reference, layer counts), which is not in the schema. This exceeds the baseline of 3 for high coverage.
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 action ('list'), the resource ('maps in the project'), and the additional information provided ('spatial reference and layer counts'). It effectively distinguishes from sibling tools like 'list_layouts' and 'get_layers'.
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 guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., 'get_layers', 'get_project_info'), but the description does not differentiate or provide context for when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the ArcGIS Pro bridge is reachable.
| 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 are provided, so the description carries the full burden of behavioral disclosure. It states 'Check that the ArcGIS Pro bridge is reachable' but does not describe what happens on success or failure, or any side effects. For a health-check tool, additional clarity on the return value or error behavior would be beneficial.
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, front-loaded sentence with no redundant information. It is as concise as possible while conveying the essential purpose.
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 low complexity and the existence of an output schema (not shown but present), the description is largely complete. It lacks only minor context like the fact that it is a no-op test, but this is implied.
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 are no parameters, so schema description coverage is 100%. The description does not need to add parameter information, and the baseline for zero parameters is 4. No additional value is required, but it does not go beyond the baseline.
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 uses the specific verb 'Check' and identifies the resource 'ArcGIS Pro bridge reachability', clearly defining the tool's purpose. This distinguishes it from all sibling tools, which are focused on data manipulation and project management.
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 verifying connectivity but lacks explicit guidance on when to use this tool versus alternatives, or any prerequisites. Since the tool is simple and self-contained, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a layer from a map.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It only states 'Remove a layer' but does not disclose whether the action is destructive, reversible, or what effects it has on related data (e.g., features, symbology). Output schema exists but is not referenced.
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 sentence with no extraneous words, but it is under-specified for the tool's complexity (2 params, no annotations). Conciseness is achieved at the cost of completeness.
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 (2 params, 1 required), the description could still be more complete by specifying that removal is permanent, what the output schema returns, or how to target a specific map. The current text leaves critical gaps.
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%, so the description should clarify parameter semantics. It does not explain that map_name defaults to null (likely the active map) or provide any context for layer_name. The agent receives no added value beyond the schema structure.
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 action ('Remove') and the resource ('layer from a map'), which distinguishes it from sibling tools like add_layer or set_layer_visibility. However, it lacks specificity about which map (e.g., active map or specified map_name) and could be more explicit.
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 guidance is provided on when to use this tool versus alternatives (e.g., set_layer_visibility to hide instead of remove) or any prerequisites (e.g., map must exist). The agent is left to infer usage without help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any arcpy geoprocessing tool. tool_name like "analysis.Buffer" or
"Buffer_analysis". Pass keyword parameters in parameters (preferred) or
positional values in args. Layer names in the active map can be used as
inputs. Example: tool_name="analysis.Buffer", parameters={"in_features":
"roads", "out_feature_class": "roads_buf", "buffer_distance_or_field":
"100 Meters"}.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| tool_name | Yes | ||
| parameters | 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 fully disclose behavior. It mentions acceptable tool name formats, parameter methods, and layer input capabilities, but does not disclose potential side effects, error handling, or whether the tool is read-only. This leaves significant gaps.
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 paragraph of three sentences, front-loading the purpose. It is concise but could benefit from bullet points or clearer separation of parameter usage for improved readability.
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 (runs any geoprocessing tool) and lack of annotations, the description should provide more context. It does not mention return values (though an output schema exists), error handling, or prerequisites. The description feels incomplete for safe and effective use.
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 is essential. It explains `tool_name` format, the `parameters` keyword dict, and `args` positional array, with a concrete example. While not exhaustive, it adds significant meaning beyond the bare 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?
The description clearly states that the tool runs any arcpy geoprocessing tool, with examples of tool name formats and parameter passing. It distinguishes itself from sibling tools by being a generic runner, though it is very broad.
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 its use for running geoprocessing tools but does not specify when to avoid it or mention alternatives like `execute_arcpy_code`. No explicit usage context or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save the current ArcGIS Pro project (.aprx).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'save' without detailing whether it overwrites, prompts for confirmation, or handles unsaved changes.
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, concise sentence that conveys the essential purpose. It is front-loaded with the verb and resource, but could be slightly more structured.
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?
For a simple no-parameter tool, the description is minimally adequate. However, it omits details about the output schema (which exists) and any potential error conditions or required state.
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 tool has zero parameters, so schema coverage is complete. The description does not need to add parameter info, and no additional meaning is required 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?
The description clearly states the action ('Save') and the specific resource ('current ArcGIS Pro project (.aprx)'). It is distinct from sibling tools that manipulate individual project elements.
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 guidance is provided on when to use this tool versus alternatives like 'get_project_info' or 'run_geoprocessing_tool'. The description does not mention prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select features by SQL where clause. method: NEW_SELECTION, ADD_TO_SELECTION, REMOVE_FROM_SELECTION, SUBSET_SELECTION.
| Name | Required | Description | Default |
|---|---|---|---|
| where | Yes | ||
| method | No | NEW_SELECTION | |
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behaviors such as whether selection is per-layer, if previous selection is cleared (method parameter partially covers this), or any side effects. Output schema exists but description does not mention return values.
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 that convey purpose and methods. Efficient and front-loaded, though the list of methods could be formatted or explained more clearly.
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 output schema exists, description does not need to detail return values. However, it lacks context about when selections persist, how they interact with other selection tools, and typical use cases. Adequate but not thorough.
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. It adds meaning to 'where' (SQL clause) and 'method' (lists options), but does not explain 'map_name' or 'layer_name' beyond their names. Baseline 3 is appropriate given partial coverage.
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 it selects features using SQL where clause and lists selection methods (NEW_SELECTION, ADD_TO_SELECTION, REMOVE_FROM_SELECTION, SUBSET_SELECTION). It does not explicitly distinguish from sibling tools like 'clear_selection' or 'set_definition_query', but the purpose is specific enough.
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 guidance on when to use this tool versus alternatives (e.g., set_definition_query, get_features). Does not mention prerequisites or typical selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the basemap, e.g. 'Topographic', 'Imagery', 'Light Gray Canvas', 'Dark Gray Canvas', 'Streets', 'Oceans'.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| basemap_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Set the basemap' which implies mutation but does not mention side effects, error conditions, permissions, or whether settings are persistent. The examples help but overall transparency is low.
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 short and front-loaded, with a single sentence and examples. It is efficiently written, though it could benefit from slight restructuring to highlight parameter usage.
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 two parameters and no annotations, the description is incomplete. It lacks information about return values, error handling, behavior with invalid basemap names, and the role of map_name. 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 description coverage is 0%, so the description must explain parameters. It provides examples for basemap_name but does not mention map_name or its role (e.g., which map to target). This omission leaves the agent uncertain about how to use the optional 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 sets the basemap and provides specific examples of valid values, making the purpose explicit and distinguishable from sibling tools like add_layer.
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 gives no indication of when to use this tool versus alternatives, nor any prerequisites or context. It only states what it does without guidance on selection from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a layer's definition query (SQL where clause). Empty string clears it.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains the core behavior (setting a query and clearing with empty string) but omits details such as whether the operation is destructive, requires permissions, or what happens with an invalid query. The description adds some transparency but is incomplete.
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, concise, and front-loaded with the key action. Every word adds value, with no extraneous 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 has 3 parameters, no annotations, and low schema coverage, the description is too brief. It doesn't address return values, error cases, prerequisites, or how the map_name parameter fits in, making it incomplete for a tool that modifies state.
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%, so the description must compensate. It clarifies that the query parameter is a SQL where clause and empty string clears it, but provides no explanation for map_name or layer_name beyond their names. This leaves significant 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 sets a layer's definition query as a SQL where clause and specifies that an empty string clears it. This provides a specific verb and resource, and distinguishes it from sibling tools like set_layer_visibility or set_layer_renderer.
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 the behavior for clearing (empty string) but gives no guidance on when to use this tool versus alternatives like set_layer_visibility or select_features. No explicit conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change layer symbology. renderer_type: simple (with RGB color like [255, 0, 0]), unique_values (needs field), graduated_colors (needs field; optional color_ramp name like "Viridis" and break_count).
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | ||
| field | No | ||
| map_name | No | ||
| color_ramp | No | ||
| layer_name | Yes | ||
| break_count | No | ||
| outline_color | No | ||
| renderer_type | No | simple |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions RGB color format but does not state whether changes are destructive, reversible, require permissions, or trigger recalculation. It also doesn't describe output or side effects like overwriting existing symbology.
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 with no waste. It front-loads the purpose and then details each renderer type's parameters efficiently. Every sentence 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?
The tool has 8 parameters, 0% schema coverage, and no annotations. The description covers core semantics but omits outline_color and map_name. It doesn't mention prerequisites like layer existence or error conditions. With an output schema present, return values are handled, but gaps remain for a complete understanding.
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 5 out of 8 parameters (renderer_type, color, field, color_ramp, break_count) with examples like RGB arrays and 'Viridis'. It does not explain outline_color or map_name, but these are less critical. Given 0% schema coverage, this is valuable.
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 'Change layer symbology', which is a specific verb-resource pair. It distinguishes from sibling tools like set_layer_visibility and set_definition_query by focusing on symbology. However, it could be more explicit about what 'symbology' encompasses (colors, symbols, etc.).
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 guidance on when to use each renderer type (simple, unique_values, graduated_colors) and their required parameters. However, it does not mention when not to use this tool or compare it to alternatives like zoom_to_layer or select_features. It implies usage context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show or hide a layer.
| Name | Required | Description | Default |
|---|---|---|---|
| visible | Yes | ||
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states the action without disclosing effects on layer state, error handling (e.g., non-existent layer), reversibility, or side effects like refreshing the map.
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 sentence, achieving brevity. However, it is under-specified; conciseness comes at the expense of necessary detail for a tool with three parameters and no schema descriptions.
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 no annotations and zero schema coverage, the description should provide more contextual cues like return value or prerequisites. The existence of an output schema is noted but no details. Incomplete for practical use.
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%, and the description does not add any meaning beyond the parameter names. The role of map_name is unexplained, and visible is trivial. At minimum, the description should clarify behavior for each 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 'Show or hide a layer' uses a specific verb and noun, clearly distinguishing it from siblings like add_layer or set_layer_renderer. However, it does not specify scope (e.g., active or named map), which could be clarified.
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 guidance on when to use this tool vs alternatives. For instance, it does not explain when to use visibility toggle versus remove_layer or set_layer_renderer. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Zoom the map view to a layer's extent.
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | No | ||
| layer_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (zooms to layer extent) but omits details like what happens if the layer is empty or invisible, or whether the map view is modified permanently. No annotations are present, so the description carries the full burden, and it is minimally adequate.
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 succinct sentence with no superfluous words. It is well front-loaded and easy to parse.
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 presence of an output schema (though not visible here), the description does not mention return values. For a simple zoom action, it covers the essential purpose but lacks context on error handling or conditions.
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%, meaning the schema properties lack descriptions. The tool description does not explain the meaning or usage of 'map_name' or 'layer_name' parameters, leaving the agent to infer from names alone.
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 'Zoom the map view to a layer's extent' clearly states the action (zoom) and the target (layer's extent). It distinguishes the tool from siblings like add_layer or remove_layer, which involve different operations.
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 (e.g., zooming to a different object) or when not to use it. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_fieldadd_layercalculate_fieldclear_selectioncreate_feature_classcreate_mapdelete_fieldexecute_arcpy_codeexport_layoutexport_map_viewget_arcgis_infoget_featuresget_field_statisticsget_layer_infoget_layersget_project_infoget_raster_infoget_unique_valueslist_geoprocessing_toolslist_layoutslist_mapspingremove_layerrun_geoprocessing_toolsave_projectselect_featuresset_basemapset_definition_queryset_layer_rendererset_layer_visibilityzoom_to_layerEach tool targets a distinct operation or resource (e.g., add_field vs add_layer, get_features vs get_layer_info, execute_arcpy_code vs run_geoprocessing_tool). The descriptions clearly differentiate purposes, so an agent should rarely confuse them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_field, get_layers, set_basemap). There are no mixed conventions or odd abbreviations, making the set predictable.
With 31 tools, the set covers a broad GIS domain well. While somewhat large, each tool serves a clear purpose and the count is appropriate for a comprehensive geospatial toolkit.
The toolkit covers many operations but lacks direct tools for feature editing (create, update, delete features) and attribute table modifications beyond calculate_field. These gaps require agents to fall back to execute_arcpy_code or run_geoprocessing_tool, which is less direct.
Provides AI assistants with direct access to Mapbox developer APIs and documentation.
GIS tools for AI agents: 65 free tools + 8 paid (hazard/site-scouting/GeoJSON export)
Give your AI agents the tools to build, manage, and run automation workflows.
Ask in plain English, get a rendered, shareable map from live public data. 24 geospatial tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Knight60/ArcGIS-Pro-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
