ArcGIS Pro MCP Bridge
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Most tools target a distinct resource/action, but several status/inspection tools overlap (ping vs get_project_info vs get_active_map_name) and run_geoprocessing vs execute_python both offer broad arcpy execution. The descriptions help disambiguate, but an agent could easily pick the wrong one in those cases.
Naming Consistency4/5Tool names generally follow a clear verb_noun pattern, with consistent use of list_ for enumerations, get_ for single values/status, and create_/set_/update_ for mutations. The main outliers are the bare ping and prepositional forms like zoom_to_layer and select_by_attribute, so the set remains predictable overall.
Tool Count2/531 tools is on the heavy side for an MCP bridge, exceeding the 25+ threshold for 'too many' in the calibration. The broad ArcGIS Pro scope explains some of the count, but run_geoprocessing and execute_python are generic escape hatches that make several specialized wrappers feel redundant.
Completeness4/5The tool set covers core ArcGIS Pro workflows well: project status, layer management, attribute inspection/selection/update, workspace exploration, layout creation/export, and publishing. Minor gaps like map/layout deletion, feature editing, and symbology changes lack dedicated tools, but run_geoprocessing/execute_python provide workarounds.
Average 4.2/5 across 31 of 31 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
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 only says it 'runs' a tool and explains the input format; it does not disclose whether the operation can modify data, what side effects may occur, whether results are returned, or how errors are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-sentence summary, an Args list, and a single illustrative example. Every sentence contributes useful information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The invocation mechanics are sufficiently documented, and an output schema exists to cover return values. However, with no annotations and no behavioral or usage context, the description is not complete enough for an agent to anticipate side effects or confidently decide between this tool and execute_python.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining both parameters. It defines 'tool' as a dotted name with multiple examples, and 'params' as a list of positional parameters with a concrete example. This gives an agent enough information to construct valid calls despite the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear action and resource: 'Run any ArcPy geoprocessing tool by its dotted name.' It is specific about the invocation style and gives concrete tool-name examples. However, it does not explicitly distinguish this tool from the sibling execute_python, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description shows how to invoke the tool with an example, but it gives no guidance on when to use run_geoprocessing versus alternatives such as execute_python. It also does not mention prerequisites, workspace requirements, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds some useful context: the new map appears under Maps in the Catalog pane and must be opened manually by double-clicking. However, it does not disclose side effects on the current project, behavior on name conflicts, or whether the map becomes active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the purpose comes first, followed by a useful usage note and the parameter list. Every sentence earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is mostly complete. It states the action, the target project context, and where the result can be found. It falls slightly short on explicit prerequisites and edge-case behavior, but those are minor for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the input schema. It only restates the name parameter and its default, which duplicate the schema's title and default value. No additional meaning is added, such as naming rules, allowed values, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new map in the current ArcGIS Pro project.' This clearly identifies what the tool does and differentiates it from siblings such as create_layout or get_active_map_name. No ambiguity exists about the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The only extra instruction is 'After creation, open it by double-clicking...' which is a post-creation step, not a decision rule for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys a read-only 'List' operation and mentions glob filtering, but it does not detail whether subdirectories are included, how results are sorted, or how errors are handled. For a simple listing tool, this is moderate coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient: a one-sentence summary followed by concise parameter documentation. The examples are concrete and add value without redundancy. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema, the description is nearly complete. It covers the tool's purpose and all parameter semantics. The main gap is the lack of routing guidance among sibling list tools, but that is better captured under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section fully compensates by documenting both parameters. 'path' is described as a full directory path with a concrete example, and 'pattern' is explained as a glob pattern with examples and the default '*'. This is complete and far beyond what the schema alone provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List files in a directory, optionally filtered by pattern,' giving a specific verb and resource. It clearly describes filesystem-level listing, which distinguishes it from sibling tools like list_feature_classes or list_rasters, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as list_feature_classes, list_rasters, or list_tables. The description implies use for raw directory inspection but does not state exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the key side-effect dimension via selection_type (NEW_SELECTION, ADD_TO_SELECTION, REMOVE_FROM_SELECTION, SUBSET_SELECTION) and the default, and it warns that layer must be an exact Contents-pane name. However, it does not state whether the current selection is replaced, what happens on invalid SQL, or any output/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a one-sentence summary followed by a compact Args list. There is no redundant prose, and the most important usage constraint (exact layer name) appears directly in the parameter docs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no schema-level descriptions, the description covers all inputs and the core behavior, and an output schema exists to define return values. Minor gaps remain, such as not explicitly stating that NEW_SELECTION replaces the existing selection, but overall the agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document all parameters, and it does: layer (exact name requirement), where_clause (SQL with two concrete examples), and selection_type (allowed values plus default). This fully compensates for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific action ('Select features') and resource ('a layer') plus the mechanism ('SQL WHERE clause'), so an agent knows what the tool does. It does not explicitly distinguish itself from sibling tools like get_layer_features or clear_selection, though the selection_type argument makes the selection-state intent clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance or comparison to alternatives. The description only explains parameters; it never says to prefer this over clear_selection, get_layer_features, or update_features, and it does not state prerequisites beyond exact layer naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of behavioral disclosure. It does state the core effect—changing a layer's visibility—and the meaning of visible. However, it does not mention error behavior, what happens if the layer name is invalid, or whether the operation is a true toggle vs. an explicit set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and well-structured, with the purpose stated first and parameter details following in a clear list. Every sentence contributes useful information; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter visibility setter, the description provides the essential invocation details: exact layer name and visible flag semantics. It does not specify behavior for missing layers or errors, but the operation is straightforward and an output schema exists, so this is mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining both parameters: 'layer' must be the exact name shown in the Contents pane, and 'visible' maps True to show and False to hide. This adds meaningful semantics beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (toggle/set) and resource (layer visibility in the Contents pane), and the Args clarify the exact effect. It does not explicitly differentiate from sibling tools, but no sibling performs the same visibility operation, so confusion is minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, and no exclusionary conditions. Usage is only implied by the purpose statement; clearer context about prerequisites or alternatives would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It conveys that the tool performs a removal from the active map, but it does not state whether the operation is reversible, whether it affects underlying data or source files, or what happens when the layer name is not found. For a destructive operation, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two lines long with no filler, front-loads the core purpose, and then documents the single parameter in a clean Args block. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter removal tool, the description covers the essential invocation details: what is removed, from where, and how to identify it. An output schema exists, so return-value documentation is not the description's responsibility; only minor behavioral details like error cases are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema only defines 'name' as a required string. The description compensates by specifying that the value must be the exact layer name as shown in the Contents pane, adding matching semantics that are essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a clear resource ('layer from the active map'), and specifies the lookup method ('by name'). This distinguishes it from siblings that add, zoom, or toggle layers, so an agent can tell exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context—removing a layer from the active map by exact name—but it does not explicitly mention when to choose this over alternatives such as set_layer_visibility (hiding) or clear_selection. There is no exclusion guidance or comparative routing, so usage is only implied, not fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It tells the agent that the project is saved, but does not mention that this overwrites the existing project file, may require write permissions, or what side effects occur. This is minimal transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It front-loads the action and object efficiently, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with an output schema, the description provides the essential invocation context: what is acted upon and what happens. Additional context such as overwrite behavior would be useful, but its absence does not prevent correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so schema coverage is trivially complete at 100%. The description adds no parameter information, but none is needed; this matches the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and the resource ('the current ArcGIS Pro project'), making the tool's purpose unambiguous. No sibling tool performs a save operation, so it is easily distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the natural trigger—persisting changes to the current project—but provides no explicit when-to-use or when-not-to-use guidance. There are no competing save-related siblings, so the lack of alternatives is not penalized heavily, but explicit usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
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 only states the action and the parameter; it does not mention failure modes, behavior when no active map exists, whether an existing layer with the same name is replaced, or any 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence adds value. The Args section is minimal but useful and directly tied to the only parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the essential invocation details and correctly targets the active map. However, it omits edge-case context such as what happens if no active map exists, whether the file must already be accessible locally, and how errors are reported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides meaningful parameter guidance: 'path' is a full path to the raster file, with an explicit Windows-style example. This compensates for the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add', the resource 'raster layer', and the target context 'active map'. It also mentions accepted formats (GeoTIFF, IMG), and the sibling add_vector_layer makes the raster-vs-vector distinction obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this tool is for adding raster layers to the active map, which gives useful context for selection. It does not explicitly name alternatives or state when not to use it, but the sibling names make the intended scope reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the primary side effect: adding a layer to the active map. But it does not mention prerequisites like requiring an existing active map, error behavior for invalid paths, or whether the operation is destructive to existing layers. This is adequate but has clear gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the main purpose, and includes a clearly formatted Args section. Every sentence adds useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single well-documented parameter, an output schema exists, and the operation is simple. The description covers the essential purpose and path semantics. It only lightly assumes the agent understands 'active map' semantics, but this is not a serious gap for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a 'Path' string with no description, while the tool description meaningfully explains that path is a full path to the data source and gives concrete examples. This adds real value beyond the schema for the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add'), the resource ('vector layer'), and the destination ('active map'), and lists concrete formats (shapefile, feature class, GeoJSON). This distinguishes it from siblings like add_raster_layer without needing to inspect either tool's schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The vector-specific formats imply when this should be used, and the sibling list includes add_raster_layer, so an agent can infer the raster/vector distinction. However, the description does not explicitly state when to use this tool over alternatives or mention any exclusions, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose useful behavior: layer name must be exact, limit controls row count, and empty fields returns all non-geometry fields. However, it does not explicitly confirm read-only semantics or describe failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose statement followed by concise parameter explanations. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three parameters are documented with clear semantics, an output schema exists so return values need not be described, and the tool is simple enough that this description is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains the exact layer name requirement, the meaning and default of limit, and the behavior of fields including the empty-list case, adding substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Preview' with the resource 'rows from a layer's attribute table', making the tool's purpose immediately clear. It is semantically distinct from siblings like list_fields, count_features, and update_features, so an agent can tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool over alternatives such as count_features, list_fields, or select_by_attribute. The description explains what the tool does but not when it should be preferred or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the operation is a read-only listing and scopes it to the current project, but it does not mention return order, potential emptiness behavior, or any error conditions. The output schema may cover return structure, but some behavioral context is still missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the main action ('List all layouts') and then specifies the scope and output content, making it easy for an agent to quickly parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description is largely complete: it names the resource, scope, and displayed properties. It could be more complete by adding a note about the current project context and perhaps clarifying that no changes are made, but the essential information for invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered and there are no parameter semantics to document. The baseline of 4 applies, and the description accurately indicates what information will be returned for each listed layout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a specific resource ('all layouts'), and the scope ('in the current ArcGIS Pro project'), along with the information included ('page size and units'). This distinguishes it from sibling tools like create_layout and export_layout, which operate on layouts differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implicitly clear: call this when you need to enumerate layouts in the active project. However, there is no explicit guidance about when not to use it or any direct comparison to alternatives, though no sibling tool appears to be a competing list-layouts operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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 explaining behavior. It clearly states that the tool removes the active selection on the named layer, but it does not mention edge-case behavior such as no selection, invalid layer name, or whether the operation is undoable. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the main operation is stated first, followed by a focused parameter explanation. Every sentence earns its place, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers purpose and parameter semantics clearly. It falls slightly short of complete because it omits edge-case behavior and any explicit alternative-routing guidance, but an output schema exists, reducing the burden to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines layer as a required string, providing minimal semantic meaning. The description enriches this significantly by specifying that layer must be the exact name as shown in the Contents pane, which is valuable practical guidance for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Clear') and a specific resource ('any active selection on a layer'), so the tool's purpose is immediately clear. It also adds the condition that this is the operation for removing an existing selection, which differentiates it from sibling tools like select_by_attribute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary usage: use this when an active selection on a layer needs to be cleared. However, it does not explicitly contrast it with related tools such as select_by_attribute, nor does it state what happens if no selection is active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the count operation, which implies a read-only query, but it does not explicitly confirm no side effects, error behavior for invalid layer names, or how the count is computed. The core behavior is transparent, but additional context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: it states the action first, then the one parameter. Every line earns its place and the format is easy for an agent to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter count tool with an output schema, the description covers the essential invocation details. It could be slightly richer by explicitly stating that it returns a numeric total or that the operation does not modify the layer, but these are minor given the simple scope and presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by documenting the only parameter. 'Exact layer name as shown in the Contents pane' adds crucial real-world meaning that the bare 'Layer' title in the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Count') and resource ('features (rows) in a layer'), making the tool's purpose unambiguous. It is clearly distinguishable from siblings like list_layers or get_layer_features, which list or retrieve rather than return a count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for getting a total feature count, but it does not explicitly state when to use it over alternatives or mention situations where another tool would be preferred. There is no exclusion or comparison guidance, so the agent must infer usage from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must communicate behavior. It adds useful detail about workspace fallback ('Uses current workspace if empty') and filter semantics, but it doesn't disclose whether subfolders are searched, whether the operation is strictly read-only, or any permissions needed. This is adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a compact parameter list. Every line has a purpose; no filler, no repetition of the schema beyond necessary semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool with an output schema, the description covers the core invocation details and the available filters. It is slightly incomplete regarding recursive search behavior and explicit guidance on when a raster_type value is necessary, but nothing an agent needs to make a basic call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full parameter documentation. It explains all three parameters: workspace path with empty-value behavior, pattern as a wildcard filter, and raster_type with concrete examples (TIF, IMG, GRID) and default-all meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List raster datasets in a workspace.' This unambiguously identifies what the tool does and clearly differentiates it from sibling listing tools such as list_feature_classes and list_tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose itself implies when to use it—when raster datasets in a workspace are needed—and the parameters clarify scope, but there is no explicit guidance about when not to use it or which sibling to prefer (e.g., list_feature_classes for vector data). Usage context is present only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds useful behavior: it clarifies that an empty workspace falls back to the current workspace. However, it does not state the return shape (covered by output schema), whether results are ordered, or any path/error behavior, so it only partially carries the behavioral disclosure burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's purpose, followed by a minimal args list. Every sentence adds information, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool with an output schema, the description covers the key invocation details and workspace fallback behavior. It could be more complete by explicitly directing agents to list_feature_classes/list_rasters for other data types, but that gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has only titles and defaults (0% coverage). The description compensates by defining workspace as a path defaulting to the current workspace and pattern as a wildcard filter. This adds meaning that the structured schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('standalone tables in a workspace') with concrete examples (GDB tables, DBF files). This distinguishes the tool from sibling listers like list_feature_classes and list_rasters by data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the phrase 'standalone tables' and the examples, but there is no explicit when-to-use or when-not-to-use guidance or any mention of alternatives such as list_feature_classes or list_layers. An agent must infer the selection criteria from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden. It discloses the tool's read-style behavior by framing it as testing the connection and reading status, and it enumerates the returned state. It does not explicitly state that no project modifications occur, but the 'status' and 'current state' language strongly implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and adds a useful usage directive. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status/health-check tool with an output schema, the description is complete: it names the connection action, enumerates the status content, and instructs the agent to call it first. No additional input, prerequisite, or behavioral detail is essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema confirms this with an empty properties object. The baseline for a zero-parameter tool is 4, and the description appropriately adds no parameter details since none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Test the connection to ArcGIS Pro and get the full project status', with a specific verb and resource. It lists the items returned, but it does not explicitly distinguish itself from the sibling get_project_info, which likely overlaps in project-status reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Always call this first to understand the current state before running any other operations.' This directly tells the agent when to use the tool, though it does not mention alternatives 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.
- Behavior3/5
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 does disclose supported formats, default format, and dpi meaning for raster formats. However, it does not mention whether existing files are overwritten, whether the layout must exist, or how errors are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line purpose statement followed by a terse parameter list. Every sentence provides necessary information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, defaults, formats, and even provides an example output path. Minor gaps like overwrite behavior and error handling exist, but for a straightforward export tool this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args block in the description fully documents every parameter: exact layout name, full output path with extension, allowed formats with default, and dpi meaning with default. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence, 'Export a layout to a file', uses a specific verb and resource, and enumerates supported formats. This clearly distinguishes it from sibling tools like create_layout or list_layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for exporting an existing layout to a file, which provides clear context. It does not explicitly mention when not to use it or name alternatives, but the purpose is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the limit behavior ('Max number of unique values to return') and the exact-layer-name requirement, but it does not mention ordering, null handling, or what happens when the field contains more unique values than the limit. This is sufficient but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core action, followed by a practical use case and a compact argument list. Every line earns its place without unnecessary prose or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with an output schema and all parameters documented, so the description is largely complete for an agent to invoke it. The main gaps are edge-case behaviors such as ordering and truncation when unique values exceed the limit, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args block is the only parameter documentation. It meaningfully explains all three parameters: layer must match the Contents pane exactly, field identifies the target field, and limit explains the default and maximum return size. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Get all unique values in a field.' This distinguishes it from sibling tools like list_fields (field names) and get_layer_features (feature records), and the mention of building WHERE clauses for select_by_attribute gives immediate practical context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for exploring data and building WHERE clauses for select_by_attribute' gives a clear when-to-use context and connects it to a specific sibling workflow. It does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The behavior is stated plainly as a view-only zoom/pan operation on the active map, and the exact-name requirement is useful. However, with no annotations, the description does not explicitly address prerequisites, error behavior for unknown layers, or confirm that no data is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences plus an argument line, with the primary action front-loaded. Every sentence adds useful information and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter navigation tool, the description covers what it affects (active map view), the scope (full extent), and the required input format. It is missing only minor behavior notes such as what happens if the layer name is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter meaning. It does: 'Exact layer name as shown in the Contents pane' tells the agent both the source and accuracy required for the 'name' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource pairing: 'Zoom and pan the active map view to show the full extent of a layer.' This clearly identifies the map-navigation purpose and distinguishes it from siblings that add, remove, or manipulate layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's intended situation is evident: use it when the agent needs to navigate the active map view to a layer's full extent. It does not state explicit exclusions or alternatives, but no sibling provides comparable zooming behavior, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the tool's read-only nature implicitly by describing metadata retrieval, lists supported dataset types, and mentions that it can verify file existence. It does not explicitly state error behavior or side effects, but for a describe operation the behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence definition of what it returns, a one-sentence usage recommendation, and a single parameter description. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema already present, the description covers purpose, usage timing, return contents, and parameter semantics. It lacks explicit guidance on alternatives or error conditions, but overall it provides enough context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'path' as a required string with no description. The tool description compensates by explaining that path is a 'Full path to the dataset' and enumerating supported formats: shapefile, raster, feature class, GDB, etc. This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Describe a dataset', and enumerates exactly what is returned: coordinate system, geometry type, extent, and data type. It clearly distinguishes itself from sibling tools by being path-based metadata inspection rather than layer manipulation, feature counting, or listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Use this to verify a file exists and check its projection before geoprocessing.' This provides clear context for when to invoke the tool, though it does not explicitly mention alternative tools 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the key runtime behavior: an empty map_name falls back to the active map, and it lists all layers rather than a filtered subset. It does not describe invalid-map-name behavior, but the simple list operation and existence of an output schema mitigate this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with parameter details clearly split out. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list operation with an output schema already present, the description covers the essential context: what is listed and how the single parameter behaves. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the bare schema: it explains that map_name is optional, that it selects a specific map, and that leaving it empty uses the active map. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('List all layers') and the resource scope ('active map or specific map by name'). It clearly differentiates from sibling list tools like list_fields or list_feature_classes by targeting map layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the appropriate context by mentioning the active map and optional named map, but it does not explicitly state when to prefer this over sibling layer/feature-class listing tools. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' clearly indicates a read-only operation, and 'currently shown in ArcGIS Pro' scopes it to the live session. It does not cover edge cases like 'no active map', but the simple getter nature and existing output schema reduce the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately communicates the verb and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a zero-parameter tool with an output schema present, so the description is complete enough for invocation. It names the target object (active map) and the application context (ArcGIS Pro), which is all an agent needs to decide to call it and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so no parameter-specific documentation is needed. The zero-parameter baseline of 4 applies; the description correctly introduces no irrelevant parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a precise resource ('the name of the active map currently shown in ArcGIS Pro'), and clear scope. This distinguishes it from sibling tools like create_map or get_project_info without requiring the agent to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when to use this tool: when the active/currently displayed map name is needed. It does not explicitly name alternatives or give when-not conditions, but with zero parameters and no directly overlapping sibling, the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly communicates a read-only information retrieval operation via 'Get information', and it discloses what data will be returned. It does not discuss error behavior (e.g., when no project is open) or explicitly state 'does not modify anything', but for a simple getter the behavior is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource before listing the specific outputs. Every part of the sentence adds useful information; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only project-info tool, the description is complete: it identifies the target context ('currently open' project) and names the three categories of returned information. An output schema exists, so detailed return shapes are handled there, and no additional prerequisites, side effects, or complex behavior need explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. The baseline of 4 applies because the description correctly omits parameter details; the schema already fully covers this dimension at 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get information') and a specific resource ('the currently open ArcGIS Pro project'), and explicitly enumerates the returned data: file path, geodatabase, and list of maps. This distinguishes it from sibling tools like get_workspace, get_active_map_name, and list_layers, which each target narrower resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: call this when you need project-level information about the currently open ArcGIS Pro project, including its path, geodatabase, or maps. It does not explicitly mention when-not-to-use or name alternative tools, but the phrase 'currently open ArcGIS Pro project' and the enumerated outputs imply the correct scope without confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, but 'Get' transparently signals a non-mutating read operation. The mention of 'current' clarifies it reflects the state of arcpy.env.workspace at call time; no destructive behavior is suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the operation and the target resource with no filler. Every word earns its place, and the absence of title or additional fields does not hurt comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description is complete: it names the operation and the resource, and an output schema exists to cover return-value details. There are no complex inputs, side effects, or prerequisites that need elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document beyond the resource being accessed; the baseline of 4 applies. The description still identifies the exact setting being read, which is the only relevant semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a concrete resource ('the current arcpy.env.workspace setting'), so an agent knows exactly what operation this performs. It also reads as the counterpart to the sibling set_workspace, distinguishing it clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current ... setting' makes clear this is for reading the existing workspace value, not changing it, so the usage context is evident. It does not explicitly say 'use set_workspace to modify', but the sibling name and the word 'current' imply it without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds meaningful behavior: using the current workspace when the workspace argument is empty, applying a wildcard pattern, and filtering by feature_type. It does not explicitly say 'read-only' or describe failure behavior, but listing is inherently non-mutating and the key scoping behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a one-sentence purpose statement followed by brief parameter clarifications. Every line adds value, especially given the sparse schema. It is front-loaded with the core purpose and uses a clean Args structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary. The description covers workspace types, defaults, and filtering, which is sufficient for a straightforward listing tool. Minor gaps like error behavior when no current workspace is set are not addressed, but these are low-stakes for a read-only listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully. It explains all three parameters: workspace path and its empty-string default behavior, pattern with a concrete wildcard example ('road*'), and feature_type with geometry examples. This is exactly the semantic layer the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation: 'List feature classes in a workspace (folder, GDB, or feature dataset).' This clearly distinguishes it from sibling tools like list_tables, list_rasters, and list_layers by naming the specific resource type being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool operates on feature classes within a workspace, and the description explicitly enumerates valid workspace kinds. It does not explicitly mention alternatives or when not to use it, but the resource-type distinction from siblings makes the usage context reasonably evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool mutates the global arcpy.env.workspace and explains the practical consequence for future geoprocessing calls. It omits edge cases like invalid path validation or persistence scope, but the core behavioral effect is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured as two sentences: the first states the operation and its effect, the second documents the single argument with format examples. There is no filler or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and an output schema, the description adequately covers the what, why, and how of the workspace parameter. It doesn't elaborate on session persistence or validation behavior, but these are minor for a simple setter and the existing context is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the workspace parameter, so the description compensates with an explicit 'Args' section. It specifies 'Full path to folder or GDB' and gives concrete examples, adding crucial meaning beyond the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set arcpy.env.workspace', and immediately clarifies its purpose as the default location for inputs/outputs when no full path is provided. This clearly differentiates it from its sibling get_workspace and precisely identifies the object being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The conditional phrase 'when no full path is provided to geoprocessing tools' gives a clear and contextual usage scenario. It does not explicitly name alternatives or exclusions, but for a simple setter the intended use before geoprocessing operations is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool creates a layout in the project and that a map frame is already included, which are meaningful side effects beyond the tool name. It also clarifies the 'empty map_name uses active map' behavior. It could mention whether the project needs to be saved separately, but for a creation tool with an output schema, the disclosed behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear one-sentence purpose, adds a single high-value workflow note about export_layout, then lists all arguments compactly. There is no filler, redundant restatement, or unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six optional parameters and an output schema, this description is complete: it explains the tool's role, all parameter semantics with defaults, allowed unit values, and the natural next step of exporting. Since an output schema is present, omitting return-value details is acceptable. No critical information needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully, and it does. Every parameter is given semantic meaning: name is the layout name, map_name selects the map and falls back to the active map, width/height define page size, units lists all allowed values, and margin is explained as the frame margin from the page edge in page units. This goes far beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a new layout in the project with a map frame already added.' This clearly distinguishes it from siblings like create_map (which creates a map, not a layout) and export_layout (which exports rather than creates). The added detail about the map frame prevents confusion with other layout-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context by instructing the agent to 'call export_layout()' after creation. This tells the agent how this tool fits into a larger sequence and implicitly routes export tasks to export_layout. It does not explicitly mention when not to use it versus create_map or list_layouts, but the workflow guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It explains the execution environment (available variables), how to return data via the result variable, and how stdout is captured, which is substantial. It does not mention potential side effects or limitations, but the arbitrary-code nature is openly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a one-line purpose, a brief usage directive, a compact list of available variables, and a short example. Every sentence contributes functional information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a general-purpose code execution tool, the description covers all essential operational details: input format, environment, output mechanism, and a concrete example. The presence of an output schema further reduces the need to spell out return structures, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only names the 'code' parameter with no description, so the description adds essential meaning. It defines the parameter as executable arcpy/Python code, lists the pre-defined variables, explains the result variable convention, and gives a complete usage example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary Python/arcpy code within the ArcGIS Pro bridge, with a specific verb and resource. It also distinguishes itself from sibling tools by framing this as a fallback for operations not covered by more specialized tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for complex arcpy.mp operations not covered by other tools, which sets a clear boundary. It does not name specific alternative tools, but the exclusion is unambiguous, and the provided example reinforces practical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It clearly conveys a read-only listing operation and specifies the metadata returned. It could be more explicit about non-modification, but the verb 'List' sufficiently indicates a non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose statement, a usage hint, and a parameter explanation. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, a clear usage note, and an output schema present, the description covers everything needed to invoke the tool correctly. No critical details are missing given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates: it defines 'dataset' as 'Full path to dataset, or layer name as shown in Contents pane,' adding practical meaning beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all fields in a dataset' and states exactly what is returned (field type, length, alias). This clearly distinguishes it from sibling tools like list_layers or list_feature_classes, which operate on different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'before building WHERE clauses or running attribute operations.' It provides clear context, though it does not name alternative tools or state explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the update is a bulk operation applied uniformly to matching rows, and it explicitly warns about the destructive implication of an empty where_clause ('be deliberate about this'). It stops short of mentioning irreversibility, permission requirements, or field existence checks, but the core behavioral profile and main risk are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient. The main behavior statement, sibling distinction, and caution are front-loaded, followed by a compact Args section that maps directly to parameters. No redundant or filler sentences; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required params, nested object updates, no annotations), the description is largely complete: it covers purpose, parameter semantics, the key safety caveat, and the main alternative. An output schema exists, so return value details are not mandatory. Minor omissions like field existence validation or exact behavior when an update fails would improve completeness, but an agent can invoke this tool correctly from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates with a dedicated Args block. Each parameter gets meaningful semantic detail: layer requires an exact name as shown in the Contents pane, where_clause gets a SQL example and an empty-string convention, and updates gets a concrete dictionary example. This adds substantial value beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Update attribute values on features matching a WHERE clause.' It immediately clarifies the bulk nature ('Sets the same field value(s) on every matching row') and distinguishes itself from execute_python for per-row updates. This clearly separates it from sibling tools like execute_python and select_by_attribute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit and actionable. It states when to use the tool (bulk update over a WHERE clause) and when not to use it ('For per-row computed values ... use execute_python with an UpdateCursor instead'). It also warns about the empty where_clause case, advising caution. This meets the when/when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses destructive/overwrite behavior, portal account side effects, reuse of the existing Pro sign-in with no separate login, the REST implementation path, and a realistic 30-60s latency expectation. This is strong behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a user-confirmation warning and behavioral caveats up front, followed by a clear Args block. Every sentence adds value: the confirmation requirement, safety warning, technical implementation note, latency expectation, and parameter semantics all earn their place. No fluff or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, six parameters, and no annotation safety signals, the description is complete. It covers prerequisites (active portal, existing Pro sign-in), side effects, timing, defaults, and parameter constraints. The presence of an output schema means return-value details are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter. It gives concrete guidance: layer must match the Contents pane name, service_name must be unique, tags are comma-separated, public controls visibility with default false, and overwrite controls replacement with default false. This adds meaning the schema alone completely lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Publish a layer as a hosted feature service to ArcGIS Online / Enterprise.' It clearly states the target portal context and the action, and it is obviously distinct from sibling tools that add/remove/layer/select features rather than publish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to confirm with the user before calling, because the tool creates or overwrites portal content. It also notes that the operation can be slow, preventing false failure interpretation. It does not explicitly name alternative tools, but no sibling performs publishing, so the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lutfiArahaman/MCP_ALAMI1'
If you have feedback or need assistance with the MCP directory API, please join our Discord server