arcgis-mcp-bridge
Server Quality Checklist
Latest release: v1.0.1
- Disambiguation4/5
Most tools have specific names that clearly indicate their function, like 'clip_raster' vs 'extract_by_mask'. However, with 103 tools, there is some potential for confusion between closely related operations (e.g., 'zonal_statistics' vs 'zonal_statistics_as_table'), though descriptions help clarify.
Naming Consistency5/5All tools follow a consistent verb_noun pattern with snake_case (e.g., 'add_field', 'clip_raster', 'dissolve_features'). There are no deviations, and even longer names like 'calculate_geometry' adhere to the convention.
Tool Count2/5With 103 tools, the server is extremely large for an MCP server. While it covers the breadth of ArcGIS functionality, this number overwhelms the typical MCP scope, making it difficult for an agent to navigate and select the right tool.
Completeness4/5The tool set covers major ArcGIS workflows: data management, vector and raster analysis, network analysis, mapping, layout, and export/import. Minor gaps exist (e.g., no direct feature editing tools), but the set is largely comprehensive for a general GIS server.
Average 4/5 across 96 of 103 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 52 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
With no annotations, the description must fully disclose behavior. It states it uses ArcPy Network Analyst and writes to out_features, but it does not explain side effects (e.g., overwrite behavior, if input data are modified), performance considerations, or what happens if the license is missing. This is insufficient for safe invocation.
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 avoids unnecessary details. Every sentence adds value, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical context for a network analysis tool: prerequisites (beyond license), input data requirements, error scenarios, and differences from similar tools. This leaves gaps that could lead to incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters. The description adds a brief summary of functionality ('supports facilities_to_find and writes solved route features'), but no meaningful extra semantics beyond the schema. Given high schema coverage, a score of 3 is appropriate.
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 it finds nearest facility routes for incident points using ArcPy Network Analyst. It lists example facility types (hospitals, stations, etc.), which adds specificity. However, it does not explicitly distinguish from sibling tools like od_cost_matrix or near_analysis, leaving some ambiguity.
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 mentions the license requirement and suggests use for matching incidents to facilities, providing some context. But it lacks explicit guidance on when not to use this tool or how it compares to alternatives, leaving the agent to infer usage boundaries.
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 must disclose behavioral traits but only states that it 'reads in_features and writes a new output feature class.' It does not mention side effects, required permissions, behavior with empty inputs, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, quick to read, and front-loaded with the primary action. It is appropriately concise but could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema (not described), the description lacks completeness. It does not explain the output schema, error conditions, or how grouping interacts with geometry types.
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?
The description briefly mentions 'in_features', 'out_features', 'geometry_type', and 'grouping behavior' but adds no new meaning beyond the input schema's own descriptions. With schema description coverage at 0%, the description should provide more detailed parameter guidance.
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 'Create bounding geometries around input features' using a specific method (ArcPy MinimumBoundingGeometry). It lists example outputs (convex hulls, envelopes, circles) and distinguishes from sibling tools that perform different operations like simplification or smoothing.
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 says 'Use this to generate convex hulls, envelopes, circles, or other summary shapes for features or groups,' providing clear intended use cases. However, it does not mention when not to use this tool, nor does it suggest alternative sibling tools for different scenarios.
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 provided, so description carries full burden. It mentions writing a standalone output table and using ArcPy, but fails to disclose key behavioral traits like required permissions, overwrite behavior, or side effects beyond the inherent schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, front-loaded with action and resource, followed by use case examples. It is concise without sacrificing clarity, though minor trimming is possible.
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?
Given the rich schema and no output schema, the description covers the tool's core purpose but lacks details on prerequisites (e.g., projection requirements) and output table structure, leaving some gaps for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter in detail (e.g., out_table, zone_fields). The description does not add additional meaning beyond the schema, so baseline score is appropriate.
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 it cross-tabulates intersections between zone and class features using ArcPy TabulateIntersection, with concrete examples. It distinguishes from siblings by mentioning the specific tool and output table, but could explicitly differentiate from similar spatial analysis tools.
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 provides usage scenarios like quantifying land-use area by district or habitat type by planning unit, implying when to use. However, it lacks explicit guidance on when not to use or alternatives, leaving the agent to infer appropriateness.
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?
Without annotations, the description carries the full burden of behavioral disclosure. It mentions that it writes an output raster, requires a license, and can optionally force edge cells to flow outward. However, it does not address whether the input is modified, error handling, performance implications, or the format of the output raster.
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 long, front-loaded with the main action and purpose. Every sentence provides essential information without redundancy or unnecessary detail.
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 tool that writes a file, the description covers the primary output and behavior. However, given the complexity of hydrologic modeling and the presence of many sibling tools, the description could benefit from mentioning the output raster's cell values or format. Additionally, it does not explain how the tool handles edge cells or the interaction with other hydrologic tools.
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?
The schema descriptions are minimal (e.g., 'Absolute path to the existing input raster dataset'), and the tool description only elaborates on two parameters (out_raster and force_flow) indirectly. With a schema description coverage of 0%, the description fails to compensate adequately for the four parameters, leaving in_raster and overwrite without additional context.
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 derives a hydrologic flow-direction raster from an elevation raster using a specific ArcPy function. It lists typical use cases like flow accumulation and watershed delineation, which helps distinguish from sibling tools that perform other hydrologic analyses. However, it does not explicitly contrast with tools like fill_sinks or slope_analysis.
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 specifies when to use the tool (prior to flow accumulation, watershed delineation, etc.) and notes the prerequisite of a Spatial Analyst license. It does not mention when not to use it or provide alternatives, which limits its guidance for selection.
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 full burden. It states the tool reads inputs and writes output without modifying sources, but omits details on overwrite behavior, required permissions, or how search_radius and closest_count affect results.
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 long, front-loads the action, and contains no extraneous words. It efficiently conveys the tool's purpose and key constraint.
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?
With an output schema present, return values are not required in the description. However, the description lacks context on overwrite behavior and search radius implications, leaving some gaps for a tool with complex parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is reported as 0%, the schema itself contains detailed parameter descriptions. The tool description adds no parameter-level meaning beyond the schema, but the schema already provides adequate definitions.
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 creates a standalone proximity table and records nearest neighbors without modifying source datasets. It uses specific verbs and resources, but does not explicitly differentiate from sibling tool 'near_analysis'.
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 provides a use case (recording nearest neighbors, distances, candidate matches) but does not specify when to avoid using this tool, nor does it mention prerequisites or alternatives.
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 full burden. It discloses that the tool detects input shape type, writes a new output without modifying source, and uses ArcPy functions. It lacks details on performance, handling of invalid geometries, or constraints like tolerance being required only for PAEK.
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 with three sentences, no fluff, and front-loads the key verb and resource. Every sentence contributes meaningful information.
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 description covers the main action and outcome but omits details about parameters (algorithm, tolerance, overwrite) and output schema behavior. Given the existence of an output schema, the lack of output description is acceptable, but the parameter omissions reduce completeness.
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% per context, meaning the description adds no parameter-specific info. Although the schema itself has descriptions for all five fields, the description does not compensate for the low coverage. It could mention tolerance or algorithm, but it does not.
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: smoothing polygon or polyline geometry using ArcPy functions. It specifies the method (SmoothPolygon/SmoothLine) and outcome (new feature class). While it doesn't explicitly name sibling tools like simplify_features, the mention of 'cartographic cleanup' and 'more generalized appearance' provides differentiation.
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 advises use for cartographic cleanup of angular boundaries or lines, giving a clear scenario. However, it does not specify when not to use this tool or mention alternatives, leaving room for ambiguity in selection among sibling tools like simplify_features.
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?
Without annotations, the description carries the full burden. It mentions reading the geodatabase path under PathGuard allowed root and returning the created dataset. It omits details on overwrite behavior, error conditions, and permissions. The core action of creating an empty feature class is clear, but missing behavioral traits lower the score.
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?
Three sentences front-load the action and purpose. Every sentence adds value: the first defines the tool, the second gives usage context, the third specifies environment constraints and output. No wasted words.
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 presence of an output schema, the description need not detail return values. It covers purpose, usage, environment constraints (PathGuard), and basic behavior. It could mention that the feature class is empty and note prerequisites, but it is largely complete.
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% per context, so the description must compensate. It only mentions 'geometry type' and 'optional WKID', leaving other parameters like name, out_gdb, and overwrite unexplained. This is insufficient for the five parameters.
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 verb 'Create' and the resource 'empty feature class inside an existing file geodatabase', using ArcPy. It distinguishes from siblings like create_file_gdb and copy_features by specifying it creates a new empty dataset. However, it does not explicitly contrast with alternative tools, which prevents a 5.
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 provides a clear usage context: 'before loading, editing, or analysis'. It does not specify when not to use the tool or mention alternative tools, such as copy_features or create_file_gdb. This limits the guidance to positive cases only.
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 provided, the description bears full responsibility for behavioral disclosure. It mentions reading one input and writing an output, but does not cover important behaviors like overwrite semantics, error conditions, performance implications, or whether the operation is reversible. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that cover purpose, usage, and output. It is front-loaded with the core action and provides essential context without unnecessary details.
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 adequately explains the input/output relationship and usage context. Since the tool has an output schema, the description does not need to detail return values. It covers the essential aspects for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the context signal indicating 0% schema coverage, the input schema actually includes descriptions for all parameters. The description adds minor value by advising on resampling method choice for categorical vs continuous data, but mostly repeats what is already in the schema. Baseline 3 is appropriate.
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: 'Change raster cell size using ArcPy Resample.' It also mentions use cases like alignment before overlay, modeling, etc. While it doesn't explicitly distinguish from siblings, the action is specific enough to stand apart from other raster tools.
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 provides guidance on when to use the tool ('align resolution before overlay, modeling, visualization, or export') and mentions choosing resampling methods based on data type. However, it lacks explicit when-not-to-use instructions or comparisons with alternatives like project_raster.
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 must cover behavioral traits. It correctly states that the tool 'Reads an input table and writes a new output table,' implying it is read-only on the input and creates a new output. However, it does not disclose potential side effects, required permissions, or overwrite behavior beyond what is in the schema (e.g., the overwrite parameter is schema-only). The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a clear purpose: stating the action, providing usage context, and noting input/output. It front-loads the primary purpose. Minor improvements could include bullet points for statistics types, but overall it is well-structured and compact.
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 moderate complexity and the presence of a detailed input schema and an output schema (per context), the description provides sufficient context for the agent to understand the tool's role. It explains the overarching operation and use case. However, it could be more complete by mentioning that the output is a new table with summarized fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not reference any parameters or their meanings, despite the schema having detailed descriptions. With schema description coverage at 0%, the description must compensate but fails to do so. The agent must rely solely on the schema for parameter understanding, which is sufficient but the description adds no value.
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's purpose: 'Calculate summary statistics for numeric or categorical fields using ArcPy Statistics.' It uses a specific verb ('calculate') and resource (summary statistics), and mentions common use cases (aggregating counts, sums, means, etc.). The purpose is unambiguous and distinguishes itself from sibling tools like frequency_analysis by specifying the exact statistical operations.
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 provides a usage context: 'Use this to aggregate... before reporting or joining results back to features.' However, it does not include explicit guidance on when not to use this tool or how it differs from alternatives like frequency_analysis or summarize_within. The usage guidelines are implied but lack clarity on 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?
No annotations provided, so description carries full burden. It discloses read/write behavior and path restrictions ('Reads in_features and writes a new dissolved output feature class inside PathGuard allowed roots'). However, it does not detail behavior of fields beyond dissolve_fields, nor error states or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences conveying purpose, use cases, and a key behavioral note. No fluff, but could be slightly more structured (e.g., separate from purpose).
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?
With output schema present, return value explanation is unnecessary. Description covers core operation, usage examples, and path constraints. Missing nuance on multi_part and overwrite, but those are detailed in the well-documented schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has detailed descriptions for each parameter (coverage 0% means description doesn't add schema info, but schema itself is rich). The description reiterates using dissolve fields but adds little beyond schema. Baseline 3 applies due to high schema coverage.
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 merges adjacent/overlapping features by attribute values using ArcPy Dissolve, with examples ('parcels, zones, roads'). It distinguishes from siblings by naming the specific operation, but doesn't explicitly contrast with merge_features or similar tools.
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?
Provides when to use ('generalize boundaries, aggregate...') but lacks when-not-to-use or alternatives. No explicit exclusion criteria or comparison to sibling tools like merge_features or multipart_to_singlepart.
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 provided, so the description carries the burden. It discloses that the tool creates a new feature class, uses a pipeline, and removes a temporary layer. It does not discuss permissions, reversibility, or performance impacts, which would add transparency.
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?
Three concise sentences: purpose, usage guidance, and outcome. No unnecessary words, front-loaded with key information. Excellent structure.
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?
Covers core function and pipeline but lacks details on return values (output schema exists but not described), relationship enum values, search_distance usage, and edge cases like overwrite behavior. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter context beyond the schema, which already has detailed descriptions for each parameter. The description mentions the pipeline but doesn't explain parameter choices or syntax. Baseline 3 is appropriate since schema coverage appears high.
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 materializes a spatial selection into a new feature class using a specific pipeline. It specifies the use case with spatial relationships like intersect, contain, within, near. However, it does not explicitly distinguish from sibling tools like intersect_features or spatial_join, which also create new outputs.
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 says 'Use this to persist features' giving a clear usage context. But it does not mention when not to use it or provide alternatives like attribute-based selection (select_by_attribute) or non-persistent 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?
No annotations are provided, so description must disclose behavioral traits. It notes license requirement, reads network dataset, writes polygon features, and PathGuard constraints. However, it does not cover error behavior, performance, or side effects like temporary files, leaving 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?
Two sentences, front-loaded with purpose and key constructs. No redundant information; every word contributes.
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?
Covers basic requirements and outputs, but lacks details on travel mode behavior, cutoff handling, and overwrite semantics. Adequate for a straightforward tool but not comprehensive for complex network analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description mentions key inputs (network_dataset, facilities, out_features) but not cutoffs, travel_mode, or overwrite. Although the input schema has descriptions per parameter (context says 'Schema description coverage: 0%', which may be erroneous, but based on given data, description adds moderate value).
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?
Description clearly states the tool solves reachable service area polygons using MakeServiceAreaAnalysisLayer and provides specific use cases (schools, hospitals, etc.). However, it does not explicitly differentiate from sibling tools like closest_facility or route_analysis, leaving some ambiguity.
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?
Description mentions license requirement and process flow, implying when to use. But it lacks explicit when-not-to-use guidance or alternatives, which would help an agent choose among network analysis tools.
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 must carry the behavioral burden. It mentions the Spatial Analyst license requirement but does not disclose side effects like creating a new table, error if table exists without overwrite=true, or any modifications to input data. The 'overwrite' parameter in schema hints at destructiveness but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loaded with the core functionality. It avoids fluff, but could be more efficient by integrating parameter hints or usage scenarios. Still, it is appropriately sized for a moderately complex tool.
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?
Given the tool's complexity and the rich input schema (with individual parameter descriptions), the description provides the essential purpose and license requirement but omits usage guidance relative to siblings and behavioral details like overwrite handling. The presence of an output schema (not shown) relieves the need to explain return values, but the description still lacks completeness in guiding the agent's decision.
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%, meaning the description adds no value beyond the schema's parameter descriptions. The description does not explain any of the six nested parameters (e.g., zone_field, in_value_raster), forcing the agent to rely solely on the schema. Although the schema provides good descriptions, the tool description fails to compensate for the low 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 clearly states the tool calculates zonal statistics and writes results to a table using ArcPy Spatial Analyst ZonalStatisticsAsTable. It provides specific examples of zone datasets (districts, parcels, watersheds) and distinguishes from sibling 'zonal_statistics' by emphasizing output to a standalone table.
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 says 'Use this to summarize raster values by districts, parcels, watersheds, grid cells, or other zone datasets' but does not explicitly compare with similar sibling tools like 'zonal_statistics' or 'summarize_within'. It only notes the license requirement, leaving ambiguity about when to choose this tool over alternatives.
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 discloses license requirements and path constraints, but does not detail behaviors such as whether the input raster is modified, error handling, or performance implications of the extraction operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action and use cases. Each sentence provides distinct value without redundancy. It could be slightly more concise but is well-structured.
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 and the presence of an output schema, the description adequately covers license, path constraints, and typical use. It does not address unsupported input types or coordinate system handling, but is sufficient for an experienced user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for each parameter. The description adds no new parameter-level meaning beyond reiterating PathGuard constraints. With high schema coverage (100% of parameters have descriptions), the baseline is 3.
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 extracts raster cells inside a mask using ArcPy Spatial Analyst ExtractByMask, with specific use cases like clipping elevation, imagery, and land-cover. However, it does not distinguish itself from the sibling tool clip_raster, which may perform a similar function.
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 when to use the tool (to clip raster data to a study area before analysis) and mentions prerequisites (Spatial Analyst license, PathGuard roots). It lacks explicit guidance on when not to use it or comparison to alternatives like clip_raster.
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 disclose behavior. It mentions reading inputs and writing an output feature class, but does not discuss permissions, processing limitations, or the fact that overwrite behavior is controlled via a parameter. Adequate but not comprehensive.
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?
Three sentences, front-loaded with core function, then use cases, then process. No wasted words. Excellent conciseness.
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 the high-level workflow and use cases. With an output schema present (not shown but indicated), the lack of return value details is acceptable. Slightly incomplete regarding output attribute structure, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed parameter descriptions (paths, overwrite, keep_all_polygons). The tool description adds no extra semantic value beyond stating the tool's purpose. Schema coverage is high, so baseline of 3 is appropriate.
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 verb 'summarize' and the resource 'features within polygon areas', with specific examples of use cases. However, it does not explicitly differentiate from sibling tools like intersect_features or dissolve_features, which also operate on polygon boundaries.
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 includes usage examples (administrative zones, grid cells, etc.), implying when to use it, but lacks explicit guidance on when not to use it or alternatives among many spatial sibling tools.
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 discloses that it modifies the layout legend and saves the .aprx project when save=true. It does not cover error conditions, permissions, or side effects, but the core behavior is adequately described.
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 three sentences, each serving a purpose: stating the action, suggesting use case, and noting the save behavior. No wasted words.
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 that an output schema exists (handling return values) and annotations are absent, the description is mostly complete. It lacks explicit prerequisites (e.g., layout must exist), but the main purpose and behavior are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains parameter descriptions, so the description adds minimal semantic value beyond stating the action (add/remove). With high schema coverage, a baseline of 3 is appropriate.
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 adds or removes a layer entry in a layout legend using arcpy.mp methods. It distinguishes from siblings like add_layer_to_map by focusing on legend updates, not map layers. However, it does not explicitly contrast with similar legend tools.
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 says 'Use this to synchronize legends with automated layer changes before exporting maps,' which provides a clear use case. However, it lacks when-not-to-use guidance or explicit alternatives, leaving usage somewhat 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?
The description discloses that the tool reads the layer's data extent, updates the map's defaultCamera, and optionally saves the project. This is transparent about the mutation side effects. With no annotations, the description carries the full burden, and it adequately addresses behavioral traits like persistence condition (save flag). It does not mention error states or permissions, but coverage is good.
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 three sentences long, front-loads the main action, and efficiently conveys purpose, usage context, and behavior. Every sentence contributes meaningfully, with no redundant or extraneous information.
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 has 4 parameters and no annotations, the description covers the main action, side effects, and usage scenario. It does not mention prerequisites like layer existence or map name defaulting behavior, but the schema provides some of that. The presence of an output schema reduces the need to describe return values. Overall, it is fairly complete for a straightforward zoom tool.
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?
The tool description does not explicitly describe the parameters; schema description coverage is 0%, meaning the description adds minimal value beyond the schema. While some parameters are hinted (layer_name, map_name, save), the critical 'aprx_path' is completely absent, making it hard for an agent to infer proper usage without reading the 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 clearly states that the tool sets the map's default camera extent to match a layer's data extent, with specific verbs and resource. It provides concrete use cases (before exporting or reopening). However, it does not explicitly distinguish from the similar sibling 'set_map_extent_from_layer', which slightly reduces clarity.
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 advises using this tool before exporting a map view or reopening the .aprx to focus on a study area. It gives context for use but does not mention when to avoid it or compare with alternatives like 'set_map_extent_from_layer'. No exclusions or condition-based guidance is provided.
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 provided, so description carries full burden. It states the tool mutates the target dataset and requires confirm=true. It does not disclose failure behavior, authorization needs, or reversible nature. The mention of ArcPy Append adds technical context but is insufficient for full transparency.
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?
Three sentences, each serving a purpose: action, use cases, and constraint. No fluff, front-loaded with key information. Efficient and clear.
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?
Description covers purpose and mutation behavior but misses important context: prerequisite that target must exist, schema_type behavior details, error handling, and PathGuard restrictions mentioned only in schema. Output schema exists but is not described. Adequate but with noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all four parameters (inputs, target, confirm, schema_type) with clear explanations. Baseline is 3 per rubric. The tool description adds only the confirm=true requirement, which is already stated in schema. No additional semantics provided.
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?
Description clearly states the tool appends rows to an existing target using ArcPy Append. It specifies the verb 'append' and the resource 'existing target dataset.' While it doesn't explicitly differentiate from siblings like merge_features or copy_features, the action is distinct enough to infer usage.
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?
Description provides explicit use cases: 'load reviewed data, merge field-compatible updates, or add processed batches.' It also notes the requirement for confirm=true. However, it does not state when not to use this tool or provide alternatives among many sibling tools.
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, description carries full burden. It states it reads input and writes output, and emphasizes non-mutating behavior. But it omits details on permissions, rate limits, or what happens to existing data (overwrite is mentioned only in schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded action and clear structuring. No fluff, but could integrate parameter hints more tightly.
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?
Given 3 parameters, no annotations, but output schema exists, the description covers the core purpose and usage context adequately but misses explaining the overwrite parameter and does not detail the output table structure.
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% per context, so description must compensate. It only indirectly mentions 'input features' and 'output table', but does not describe the overwrite parameter or path requirements beyond 'PathGuard allowed roots'.
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?
Description clearly states the tool checks geometry problems using ArcPy CheckGeometry and writes to an output table. It also distinguishes from sibling tools by positioning it as a non-mutating QA/QC step before repair or export.
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?
Explicitly says to use as a non-mutating step before related operations, providing good context. However, it does not exclude scenarios like when to use alternative check tools (e.g., topology_check) 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?
With no annotations, the description carries the burden of behavioral disclosure. It mentions using ArcPy and path constraints (in_features/out_features inside PathGuard allowed roots), but does not explain how the tool handles missing inputs, existing outputs (though the overwrite parameter exists), or other edge cases.
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 very concise, consisting of three sentences that front-load the core functionality and use cases without extraneous detail.
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 description is fairly complete given the tool's simplicity and the detailed schema, but it does not explain the overwrite parameter or the point_location options' effects. Output schema is present but not described, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for all parameters (in_features, out_features, overwrite, point_location), so the baseline is 3. The description adds little beyond the schema, only mentioning in_features and out_features by name without elaboration.
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 converts feature vertices to point features using ArcPy, specifies the types of vertices (endpoints, all vertices, midpoints, dangle points), and lists use cases (QA/QC, network checks, geometry inspection). This distinguishes it from sibling tools like feature_to_point.
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 provides context for when to use the tool (extracting vertices for QA/QC, network checks, etc.), but does not explicitly mention when not to use it or name alternative tools. The guidance is implied rather than explicit.
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 must disclose behavioral traits. It notes that output is written inside PathGuard allowed roots and that input geometry is preserved where applicable, but lacks detail on overwrite behavior (though schema has overwrite param), permission requirements, or side effects like attribute field naming.
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-loading the core purpose and a use case. No redundant information, every word serves a purpose.
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 tool has an output schema (implied), so return values need not be explained. However, the description lacks usage guidelines and sufficient behavioral details for a tool with no annotations, making it less complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as each parameter has a description. The description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
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 performs an Identity overlay to transfer attributes from overlay features to input features while preserving input geometry. It uses specific verb 'overlay' and resource 'features', and distinguishes itself from other overlay tools like intersect or union.
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 mentions using it to transfer attributes onto another feature layer, but provides no guidance on when to avoid it or suggests alternatives such as intersect or spatial join. Usage context is implied but not explicit.
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 provided, so description bears full burden. Only states it reads inputs and writes output; lacks information on side effects, overwrite behavior, required permissions, or computational intensity. The mention of ArcPy implies a processing function but is insufficient for safe invocation.
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 concise sentences that front-load the core purpose and action. No redundant phrases; each sentence contributes meaningful information.
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?
Covers basic operation and output location requirement. With an output schema present, return values are documented. Missing prerequisites (spatial reference alignment), overwrite behavior, and error conditions. Adequate but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions fully cover each parameter, so description adds no extra meaning. Baseline 3 is appropriate since schema provides good parameter documentation; description does not compensate for 0% coverage in its own text.
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?
Uses specific verbs 'merge multiple raster datasets' and provides concrete examples (tiles, scenes, DEM sheets, image bands). Distinct from sibling tools like merge_features or clip_raster by focusing on raster mosaicking.
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?
Clearly states use case (combining tiles/scenes) and prerequisite (two or more input rasters). Lacks explicit when-not-to-use or alternative tool mentions, but context from sibling list suffices for differentiation.
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 must disclose behavior. It mentions modification of the layout and optional save, but lacks details on error handling (e.g., missing element), licensing (arcpy.mp), or the effect when save=false (modification still occurs). This is adequate but not thorough.
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 extremely concise, using three sentences to convey purpose, use cases, and save behavior. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 5 parameters, the description is too brief. It omits how layout selection works, behavior on missing elements, and prerequisites like project file state. The output schema exists but is not shown; still, the description should be more complete for safe usage.
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?
The input schema has parameter descriptions, but context signals indicate 0% coverage (likely meaning no useful descriptions). The tool description adds context for use cases but does not explain parameter meanings beyond what the schema provides. For a tool with 5 parameters, this is insufficient.
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 'Update' and the resource 'text content of a named layout text element', and lists specific use cases (titles, dates, etc.), making the purpose unmistakable. It is distinct from sibling tools, none of which update text elements.
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 tells when to use ('automate titles, dates, subtitles... before export') and mentions the optional save behavior. However, it does not explicitly state when not to use or provide alternatives, though no direct sibling exists.
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?
Given no annotations, the description reveals that it mutates the schema and validates field names/types/aliases/lengths. However, it lacks details on error handling, transaction atomicity, or prerequisites like dataset existence.
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 efficient sentences with no redundant information, front-loaded with the core action and use cases.
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?
With an output schema present, return values need not be explained. However, the description omits limits (e.g., max 100 fields) and fails to clarify whether the operation is atomic or partially applied.
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. It fails to mention the 'dataset' and 'fields' parameters or their constraints, leaving agents to infer from the schema alone.
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 multiple fields' and the resource 'existing feature class or table', distinguishing it from the sibling tool 'add_field' by emphasizing the batch operation.
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 recommends use for 'before imports, calculations, joins, or QA/QC', providing clear context. It doesn't explicitly state when not to use it, but the batch vs single field distinction is 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?
Without annotations, the description describes that it reads input feature paths and writes a new output inside PathGuard roots, but lacks details on error handling, schema compatibility requirements, or performance. It provides basic behavioral context but is not exhaustive.
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 three sentences, front-loaded with purpose, and contains no redundant information. Every sentence adds value.
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?
Given the output schema exists, the description covers the core functionality but omits details on compatibility conditions, error scenarios, or side effects. It is complete for a basic understanding but lacks depth.
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?
With 0% schema description coverage, the description must compensate for parameter meaning, but it only mentions 'reads input paths and writes output' without elaborating on parameters like overwrite, in_features, or out_features. The schema itself has descriptions, but the tool's description does not add value beyond that.
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 combines multiple compatible feature classes or layers into one output using ArcPy Merge. It specifies the use case of assembling same-schema datasets from multiple sources, tiles, districts, or batches, distinguishing it from siblings like append_features or copy_features.
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 context on when to use the tool ('assemble same-schema datasets from multiple sources'), but does not mention when not to use it or explicitly name alternative tools, though the context implies it is for merging compatible inputs.
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 full burden. It mentions 'reads polygon features and writes out_raster' but does not disclose side effects, required permissions, or any constraints beyond what the input schema already provides.
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?
Description is three short sentences, front-loaded with purpose, no filler. Every sentence adds value.
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?
With an output schema present, the description need not explain return values. It covers the basic functionality and use cases. Could mention prerequisites (e.g., ArcPy license) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for each parameter (e.g., cell_size, overwrite). The tool description mentions 'value_field, cell_assignment, and cell_size' but adds no new semantic information beyond what the schema already provides.
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?
Description clearly states 'Convert polygon features to a raster dataset' with specific verb and resource, and distinguishes from sibling tools by naming the ArcPy tool and specifying use cases like 'suitability modeling' and 'raster overlay'.
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?
Description explicitly says 'Use this when vector zones, classes, parcels, or planning units need to become raster cells...' providing clear usage context. Does not mention when not to use, but the sibling list implies alternatives for other raster operations.
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 provided, so description carries full burden. States mutation in .aprx when save=true and no alteration of source dataset. Missing details on errors (e.g., layer not found), permissions, or side effects. Adequate but not fully 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?
Three efficient sentences, front-loaded with action, use case, and behavioral note. No wasted words. Ideal length for quick understanding.
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?
Covers purpose, use case, behavioral impact, but omits map selection detail, required layer existence, and error conditions. Output schema exists but is not shown; description doesn't discuss return values. Acceptable but leaves gaps for an agent.
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?
Description adds minimal parameter info beyond input schema. Does not mention 'save', 'map_name', 'visible' fields or their nuances. Schema descriptions are detailed, but the tool description does not supplement or clarify. Coverage is 0% from description.
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?
Clear verb 'show or hide' and specific resource 'named layer in an ArcGIS Pro map'. Distinguishes from siblings like set_layer_symbology and remove_layer_from_map by focusing on visibility. Includes use case for layout/map export.
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?
Explicitly says 'Use this before layout or map export' and mutates only visibility, not source data. Lacks explicit when-not-to-use but context implies alternatives (e.g., removal, symbology). Decent guidance.
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. It discloses the license requirement (Spatial Analyst), output type (slope raster), and output measurement options (degrees, percent rise) with z_factor usage. It does not explicitly state that the input raster is unchanged, but the word 'derive' implies a read-only operation. The description could mention idempotency or side effects, but the behavioral disclosure is mostly 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 is very concise, consisting of three short sentences. It front-loads the core function ('derive slope') and efficiently adds usage context and behavioral notes. Every sentence adds value without redundancy or unnecessary detail.
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 (a GIS spatial analysis tool with five parameters) and the presence of an output schema, the description provides necessary context: the core functionality, typical use cases, and license requirement. It does not explain return values (the output schema likely handles that) or all prerequisites (e.g., that in_raster must be a single-band elevation). However, the description is largely complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (in_raster, out_raster, z_factor, overwrite, output_measurement) including defaults and constraints. The description repeats some schema information (e.g., degrees/percent rise, z_factor) but adds the context of using ArcPy Spatial Analyst. Since schema coverage is effectively 100%, the description adds minimal extra meaning, resulting in a baseline score of 3.
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?
Description clearly states the tool derives slope from an elevation raster using ArcPy Spatial Analyst, specifying the resource (elevation raster), action (derive slope), and output format (slope raster in degrees or percent rise). It provides context for use in terrain, hydrology, etc., which helps the agent understand its domain. However, it does not explicitly distinguish this tool from siblings like aspect_analysis or hillshade, which limits precision.
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 lists application areas (terrain, hydrology, accessibility, hazard, site suitability) implying when to use. It also mentions the requirement for a Spatial Analyst license. However, it provides no guidance on when not to use this tool or alternatives (e.g., for non-raster slope calculations). This lack of exclusions and alternative references reduces the score.
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 bears full burden. It mentions the requirement for a Spatial Analyst license, which is a key behavioral trait. However, it does not disclose side effects like file creation, permission needs, or error conditions. The description is adequate but not rich.
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 redundancy. It front-loads the core action and then adds usage guidance and a dependency. 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 presence of an output schema and detailed parameter descriptions, the description is mostly complete. It misses clarifying that the output raster is created at the specified path and that overwrite needs true for existing outputs, but these are clear from the schema. The description covers the main purpose and key constraint (license).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for all parameters, so the schema_description_coverage is effectively high. The description mentions 'MEAN, SUM, MIN, MAX, or similar value', which aligns with the statistics_type parameter but adds no new information. The description does not compensate for any missing schema details.
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 it calculates one raster statistic per zone and writes the result as a raster. It specifies the verb 'calculate' and the resource 'one raster statistic per zone'. It implicitly differentiates from the sibling 'zonal_statistics_as_table' by emphasizing raster output, but does not explicitly name the alternative.
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 guidance: 'Use this when each zone should receive a MEAN, SUM, MIN, MAX, or similar value'. It does not explicitly say when not to use or list alternatives, but the context is sufficient for typical usage.
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 must disclose behavioral traits. It states the license requirement and that it writes a new raster, which adds value. However, it does not detail side effects, performance, or what happens with existing outputs beyond what the schema's overwrite parameter implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, starting with the core action. It lists use cases efficiently. Minor room for improvement in structuring but overall well-sized.
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 presence of an output schema, the description adequately covers the tool's purpose, dependencies (license), and use cases. It could mention output format (e.g., integer raster in degrees), but the output schema likely handles that. Completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (in_raster, out_raster, z_factor, overwrite), achieving high schema coverage. The tool description does not add parameter-specific information, so the baseline score of 3 is appropriate.
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 derives downslope aspect direction from an elevation raster using ArcPy Spatial Analyst Aspect. It lists specific use cases (terrain interpretation, solar exposure, ecological modeling, hydrology, site suitability), distinguishing it from siblings like slope_analysis.
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 explicit usage contexts (terrain interpretation, solar exposure, etc.) but does not mention when not to use or compare to alternatives. While helpful, it lacks explicit 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?
No annotations provided, so description carries full burden. Mentions reading input and writing output inside PathGuard roots, but does not disclose potential side effects like overwriting, permissions needed, or how existing data is handled. The overwrite parameter is mentioned in schema but not in description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. Efficiently covers primary use and constraints. Could be slightly more structured but is concise and informative.
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?
Covers main functionality, inputs, output constraints, and use cases. Does not detail error handling or edge cases, but sufficient for an agent to understand when to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides detailed parameter descriptions. The tool description adds context about the three clipping methods (rectangle, extent, polygon) which relate to parameters, but does not explain each parameter individually. PathGuard constraint is mentioned, which adds value beyond 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?
Description clearly states action 'Clip', resource 'raster', and specifies three methods: rectangle, template extent, polygon. It differentiates from siblings like extract_by_mask by mentioning it uses ArcPy management Clip and does not require Spatial Analyst.
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?
Provides explicit context for use: 'crop imagery, DEMs, or classified rasters to a study area without requiring Spatial Analyst.' Does not explicitly state when not to use or contrast with alternatives, but gives clear guidance.
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 bears full responsibility for behavioral disclosure. It states the tool reads input datasets and writes a new output without mutating the originals, which is critical. However, it does not explain the role of the search_distance parameter, overwrite behavior, error handling, or details about the output schema, leaving gaps in transparency.
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 extremely concise, using two clear sentences to convey the purpose, use cases, and non-destructive behavior. Every sentence serves a purpose, and the key action is front-loaded. There is zero fluff.
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?
Given the tool's complexity (two input datasets, search tolerance, output creation) and the presence of an output schema, the description omits important context such as the structure of the change dataset, expected output attributes, and prerequisite conditions (e.g., matching geometries). It provides just enough to understand the basic operation but not full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all five parameters (update_features, base_features, out_features, search_distance, overwrite). The tool description only mentions the three main datasets generically and does not elaborate on search_distance or overwrite beyond what the schema states. Since schema coverage is high, the description adds minimal extra value, meriting a baseline score of 3.
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 detects spatial or attribute changes between two feature datasets, using the specific ArcPy function DetectFeatureChanges. It provides concrete use cases (QA/QC, version comparison, update review) and distinguishes itself from sibling tools that handle different spatial 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 explicitly recommends the tool for QA/QC, version comparison, update review, and identifying changed features within a search tolerance, giving clear context for when to use it. However, it does not mention when not to use it or point to alternative tools, which would make the guidance more complete.
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 mentions reading the .aprx project and writing out_png, but does not disclose whether the tool modifies the project file, requires specific permissions, or has any side effects. However, the tool is export-only and non-destructive, so the description 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first explains what the tool does, second explains when to use it. It is concise and front-loaded, but slightly more structure (e.g., bullet points or separate sections) could improve readability for agents.
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?
With 7 parameters (1 required) and an output schema present, the description covers the main purpose and use case. It could mention PathGuard constraints or overwrite behavior, but those are detailed in the schema. Overall, it is sufficiently complete for an export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters have descriptions in the input schema). According to the rules, baseline is 3. The description adds context like 'using the map defaultView' and mention of 'quick snapshots' but does not provide additional parameter-specific information beyond 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 clearly states the verb 'export', the resource 'map view as PNG image', and specifies it uses the default view without requiring a layout. It distinguishes from layout-based exports by explicitly comparing to formal 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 explicitly states when to use the tool: 'for quick map snapshots, previews, or automated image generation when a formal layout is unnecessary.' This implies the alternative (use layout export) when a formal layout is needed. It does not name sibling tools like export_layout_png explicitly, but the context is 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, description must carry full behavioral burden. It discloses that the tool reads input and writes shapefile components into an existing output folder within PathGuard allowed roots. However, it does not mention overwrite behavior, error handling, or performance implications.
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?
Three sentences: core function, usage guidance, and behavioral context. No redundant information. Well-structured and 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?
Given the tool's simplicity and presence of output schema (not shown but indicated in context), the description covers purpose, usage, and basic behavior. Could mention output file naming or limitations for completeness.
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%, but the schema itself provides parameter descriptions. The main description does not add meaning beyond the schema; it merely references 'in_features' and 'output_folder' without additional context.
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 'export', resource 'feature class', and target format 'shapefile', using the ArcPy function. It distinguishes from siblings like 'export_to_geojson' and 'export_map_as_image'.
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?
Explicitly says 'Use this when data must be shared with legacy GIS tools or systems that require shapefiles', providing clear context. Does not explicitly state when not to use, but sibling tools imply alternatives.
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?
Since no annotations are provided, the description bears full responsibility for behavioral disclosure. It explicitly states that the tool appends data (non-destructive) and requires confirm=true. The pipeline steps provide context on what happens internally. However, it lacks information on error handling or success/failure conditions.
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 exceptionally concise: three sentences plus a note, no redundant information. It front-loads the core pipeline and critical constraint (confirm=true). Every sentence adds value.
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 complex pipeline tool, the description outlines the main steps and important constraints (confirm, environment). However, it omits details like coordinate system handling, failure behavior, and the required format of the base_layout. Given the presence of an output schema (which may cover return values), the description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on individual parameters; all parameter semantics are handled by the input schema, which has high coverage (each parameter has a description). Thus, the description adds no extra meaning beyond the schema, earning the baseline score of 3.
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 provides a clear and specific verb-resource pair: 'extract sketch to GIS'. It outlines a multi-step pipeline (alignment, extraction, georeferencing, appending) that distinguishes it from all sibling tools, none of which handle sketch-to-GIS workflows.
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 states that the tool 'APPENDS rows — requires confirm=true', giving a clear condition for use. It also mentions environment dependencies. However, it does not provide guidance on when to avoid this tool or suggest alternatives, which would improve decision-making.
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. It states that the tool reads in_features and writes a new output, implying no modification of input, but lacks details on permissions, error handling, or constraints beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a clear structure: action, use cases, process. It is concise and front-loaded with the core purpose, though it could be slightly more compact.
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 input schema richness and assumed output schema, the description covers the essential purpose and typical usages. It does not explain output details, but the output schema is separate. For a tool with multiple parameters, the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all parameters (e.g., in_features, out_features, overwrite, point_location), covering format and constraints. The tool description adds little beyond restating the basic process, so a baseline score is appropriate given high schema 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 clearly states the tool creates representative point features from polygons or lines, specifying the method (ArcPy FeatureToPoint) and common use cases (centroids, inside points for labeling, joins, sampling). This distinguishes it from sibling tools like feature_vertices_to_points.
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 explains when to use the tool (for centroids or inside points, labeling, joins, sampling) but does not explicitly exclude cases or mention alternatives. The context is clear, and sibling tool names are available for differentiation.
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 notes the use of ArcPy Spatial Analyst and license requirement, but does not detail behaviors like input validation, performance, or what happens on overwrite. The parameter descriptions in the schema cover some aspects, but the tool description lacks deeper behavioral context.
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 long, with the first sentence stating the core purpose and the second adding use cases and the license requirement. No extraneous words.
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 presence of an output schema, return values are covered. The description explains what the tool does, when to use it, and a prerequisite (license). It omits details like prerequisite input conditions or potential errors, but overall it is sufficiently informative for a raster tool with well-documented parameters.
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%, yet the description adds no new meaning beyond listing 'controlled sun azimuth, altitude, shadow modeling, and z_factor.' All parameter details are already in the schema, so the description provides minimal added value for parameter understanding.
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 starts with 'Create shaded relief from an elevation raster using ArcPy Spatial Analyst Hillshade,' which is a specific verb+resource. It clearly states the tool's output and distinguishes it from siblings like slope_analysis or aspect_analysis by focusing on hillshade.
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 specifies use cases: 'terrain visualization, map backdrops, and DEM QA/QC' and mentions the required license. However, it does not explicitly exclude other uses or contrast with alternatives.
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 discloses path restrictions and core behavior, but lacks details on side effects, permissions, or error conditions.
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 redundant information. It front-loads the main purpose and is tightly written.
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 complex geoprocessing tool, the description omits prerequisites (e.g., matching geometry types, projections) and behavior details (e.g., output type). The output schema may compensate, but more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has comprehensive descriptions for all four parameters, so the description adds no extra parameter meaning beyond 'ArcPy Intersect' context.
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 it overlays feature layers using ArcPy Intersect, writes shared geometry to a new output, and is distinct from sibling tools like union or symmetrical_difference.
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?
It provides a use case for finding common geometry, but does not explicitly mention when not to use it or contrast with alternatives like union_features or identity_features.
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 convey behavioral traits. It mentions the license requirement and that output writes inside PathGuard roots, but does not disclose error handling, temporary file creation, or performance implications. The description adds some context beyond the schema but is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose. The list of use cases is slightly verbose but adds clarity. It could be trimmed without losing value, but overall it is efficient.
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 complexity of kernel density and the existence of an output schema, the description covers license constraints, input types, and allowed output paths. It misses prerequisites like Spatial Analyst extension activation, but is largely adequate for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Context indicates schema description coverage is 0%, so the description should compensate. It lists supported parameters (population_field, cell_size, search_radius) and mentions out_raster, but does not explain their roles or behavior (e.g., how search_radius affects smoothness). The description adds minimal meaning beyond parameter names.
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?
Description clearly states the tool estimates a continuous density raster from point/polyline features using Spatial Analyst. It lists specific use cases like hotspot surfaces and crime density, which distinguishes it from sibling tools like contour_lines or hot spot analysis that have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear use cases and notes the requirement for a Spatial Analyst license. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, which would be beneficial for an agent deciding between kernel_density and similar tools like hotspot_analysis.
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. It discloses the license requirement, that it writes output to out_features within PathGuard allowed roots, and that it supports travel_mode and cutoff. Missing are details about overwrite behavior, potential side effects on input data, and the exact nature of the output lines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, followed by use cases and then additional details. Each sentence serves a purpose, though it could be slightly more concise by combining the use case and detail sentences. Overall, it is well-structured and not overly verbose.
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 with 7 parameters and the existence of an output schema, the description covers the essential purpose, prerequisite, and output behavior. It mentions PathGuard for output but not for other paths; however, the schema covers those. The description is sufficiently complete for an agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all parameters, so baseline is 3. The tool description adds little beyond the schema, simply restating that travel_mode and cutoff are supported and that output goes to out_features. It does not add new meaning for individual parameters.
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 'Solve origin-destination travel cost lines' with a specific verb and resource, and provides multiple use case examples like measuring travel time between demand points and destinations. It clearly distinguishes its purpose from sibling network analysis tools like closest_facility or route_analysis.
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 'Use this to measure travel time or distance between demand points and destinations', giving clear guidance on when to use the tool. It also mentions the license requirement. However, it does not discuss when not to use it or suggest alternative tools among siblings.
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 provided, so description carries behavioral disclosure. It states expressions are restricted to declared variable names, no inline paths or Python execution, and validated map-algebra syntax. However, it does not discuss error handling, output behavior, or the overwrite parameter's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load the primary purpose, follow with use cases, and end with constraints and license requirement. No unnecessary words, though the list of use cases could be comma-separated more cleanly.
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 presence of an output schema and detailed input schema, the description covers the essential context: tool type, use cases, license requirement, and syntax restrictions. It adequately distinguishes from sibling tools and sets user expectations for a safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for each parameter (rasters, variable_names, expression, out_raster, overwrite). The description adds no new parameter-specific information beyond reiterating variable_names usage, so it meets the baseline expectation without additional value.
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?
Description clearly states the tool runs Spatial Analyst map algebra using ArcPy RasterCalculator, with specific use cases like NDVI, suitability models, and binary masks. It distinguishes from sibling raster tools like clip_raster or project_raster by focusing on algebraic expressions.
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?
Provides explicit use cases (NDVI, suitability models, etc.) and a prerequisite (Spatial Analyst license). Does not explicitly contrast with alternatives, but the context of map algebra is clear enough for an agent to apply 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?
No annotations provided, so the description carries the full burden. It discloses that the tool updates the .aprx project conditionally ('when save=true') and uses a specific API. However, it does not mention potential side effects, such as overwriting previous scale values, or any prerequisites like ensuring the layout and map frame exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, front-loading the primary action and use case. Every sentence adds value, though the third sentence could be merged with the first to improve efficiency.
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 complexity of the tool (multiple parameters for layout, map frame, and save behavior), the description adequately sets the context for a layout export workflow. It does not explicitly mention prerequisites or default behaviors for layout_name and map_frame, but the schema covers those defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already provide good explanations for parameters like scale and save, but the context reports 0% schema coverage. The tool description adds some context about scale (1:1000 examples) and save (temporary changes), but does not elaborate on aprx_path, map_frame, or layout_name beyond what the schema offers.
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 ('set the camera scale denominator'), the target resource ('selected layout map frame'), and the specific tool used ('arcpy.mp camera.scale'). It distinguishes the tool from siblings like export_layout_pdf or set_map_extent_from_layer by specifying a known-scale use case.
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 advises when to use the tool: 'before exporting a layout when the map must be fixed to a known scale.' While it does not list alternative tools or when not to use it, the 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the operation (reads target/join features, writes out_features) and mentions PathGuard root constraints. However, it does not describe side effects (e.g., no modification of inputs), permission requirements, behavior on empty features, or details about overwrite and match_option behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the core action and technology, the second provides usage context. It is front-loaded, contains no redundant information, and every sentence adds value.
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?
While the description covers the basic operation and PathGuard roots, it omits important details for a spatial join tool: explanation of different match options (e.g., INTERSECT vs WITHIN), join operations (one-to-one vs many), overwrite behavior, and output schema characteristics. With no annotations and no output schema visible, the description should provide more context to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions (e.g., for target_features, join_features, out_features) already provide clear parameter meanings. The description adds some context ('reads target_features and join_features and writes out_features inside PathGuard roots') but does not significantly enhance understanding beyond the schema, which has high 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 clearly states the purpose: joining attributes from one feature layer to another based on spatial relationships using ArcPy SpatialJoin. It specifies the action (join), resources (feature layers), and distinguishes from other spatial tools like intersect_features or spatial_autocorrelation by explicitly mentioning counting, summarizing, or transferring attributes.
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 usage context: 'Use this to count, summarize, or transfer nearby, contained, intersecting, or matching feature attributes into a new output feature class.' It implies when to use the tool but does not explicitly state when not to use or mention alternatives, though the sibling list shows related tools like summarise_within and intersect_features.
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 full burden. It discloses that the tool reads input features and writes output, uses ArcPy Union, and enforces path restrictions. However, it lacks details on performance, input mutability, or error handling, which are important for a spatial 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 three sentences, front-loaded with the core action, and contains no redundant or tangential information. 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 (union of polygon layers) and the presence of a detailed schema and output schema, the description covers the essential aspects: what it does, when to use it, and path constraints. Minor improvements could include mentioning attribute behavior more explicitly.
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 but adds no new parameter information beyond what is already in the schema (e.g., path constraints). It merely restates that paths must be inside allowed roots, offering no additional semantic value.
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 'Overlay two or more polygon feature layers using ArcPy Union and write a new polygon feature class', specifying the verb (overlay), resource (polygon feature layers), and output. It distinguishes from sibling overlay tools by mentioning 'union' and 'retaining attributes from each input', which is unique to union 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 provides explicit use cases: 'Use this to compare zoning, land-use, administrative, or planning layers'. It gives clear context for when to apply the tool, though it does not explicitly state when not to use it or list alternative tools.
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 burden. It declares mutation and lists supported geometry properties, but does not clarify if the field is created automatically or if values are overwritten. Missing details like prerequisites or field creation 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?
Two sentences, no wasted words. First sentence front-loads the core purpose, second adds usage context and mutation warning. Excellent conciseness.
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 presence of an output schema (not shown) and comprehensive input schema descriptions, the tool description covers the essentials: purpose, usage, and mutation. Could mention the lack of return value but is adequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes full descriptions for each property, so the baseline is 3. The description adds context by listing geometry property options and mentioning ArcPy, but does not explain unit parameters or path constraints beyond what schema already provides.
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 calculates geometry properties (area, length, perimeter, centroid, point coordinates) into an attribute field using ArcPy. It distinguishes from siblings like calculate_field and add_xy_coordinates by specifying the exact geometry calculations.
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 explicit use cases (reporting, QA/QC, labeling, downstream analysis) and mentions mutation. However, it does not explicitly state when NOT to use this tool or suggest alternatives like calculate_field for non-geometry calculations.
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 full burden. It discloses that the tool 'mutates the geodatabase storage layout but not feature content', clearly indicating a non-destructive mutation. It does not cover auth needs or rate limits, but for a geodatabase maintenance tool, this 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences that front-load the main action and context. It avoids fluff but could be more structured by separating usage and behavior into clearer sections.
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 simplicity (one parameter, output schema present), the description covers purpose, usage scenario, and key behavioral trait. Explanation of return values is unnecessary due to the output schema, resulting in adequate completeness.
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?
Despite the schema having a description for the 'gdb' parameter, the context signal indicates 0% schema description coverage. The tool description does not add any extra meaning beyond the parameter name, failing to compensate for the low coverage. It merely restates the purpose without clarifying 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 clearly states the tool compacts a file geodatabase using ArcPy Compact, with specific verbs and resource. It differs from siblings like 'create_file_gdb' or 'delete_dataset', making its purpose distinct and unambiguous.
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 context for when to use the tool: 'as maintenance after heavy editing, deletion, or intermediate output cleanup'. It implies when it is appropriate but does not explicitly mention when not to use it or list alternative tools, which prevents a higher score.
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 disclose behavioral traits. It mentions the requirement for a Spatial Analyst license and that it writes a polyline feature class. However, it does not discuss performance, error conditions, or the effect of overwriting existing outputs, which limits its transparency.
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 at three sentences, each serving a distinct purpose: tool action, use cases, and requirements. It is well-structured and front-loaded with the primary function.
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 has an output schema (not shown) and the input schema is detailed, the description covers the core functionality and requirements. It could mention the output schema briefly, but the overall completeness is high for a tool with structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema includes descriptions for each parameter, the context indicates 0% schema description coverage. The tool description does not elaborate on parameter meanings beyond mentioning 'DEM raster' and 'elevation isolines', but the schema itself is explicit. Thus, the description adds little beyond 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 clearly states the tool creates vector elevation isolines from a DEM raster using ArcPy Spatial Analyst Contour. It provides specific use cases: cartographic contours, terrain analysis inputs, elevation reference lines. This distinguishes it well from sibling tools like raster_calculator or slope_analysis.
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 the tool ('Use this to generate...') and lists common applications. However, it does not mention when not to use it or provide alternatives, such as other raster-to-vector tools or methods for contour generation.
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 partially covers behavior: it mentions the prerequisite that the parent folder must be within a PathGuard allowed root and that it returns the created path. However, it does not disclose whether an existing geodatabase with the same name will be overwritten or if errors are raised for invalid names beyond the regex pattern.
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: the first defines the operation and method, the second states use cases and constraints. Every sentence adds value, and the structure is front-loaded with the primary action.
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 creation tool with two well-documented parameters, the description covers purpose, use context, a key constraint (PathGuard), and return value (path). An output schema exists (not shown) to cover return details. The only minor gap is the lack of clarification on overwrite behavior, but overall it is sufficient for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both parameters (gdb_name with pattern and maxLength, parent_folder with absolute path requirement). The description adds the PathGuard constraint for parent_folder, but otherwise does not significantly enhance understanding beyond 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 clearly states the verb ('Create') and resource ('file geodatabase') and lists specific use cases (scratch outputs, copied data, imports, analysis results). It distinguishes itself from sibling tools like create_feature_class by targeting the workspace itself rather than a dataset within.
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 explains when to use the tool ('prepare a workspace for scratch outputs...') and implies it's for creating a container rather than a feature class or other dataset. However, it does not explicitly mention when not to use it or compare to alternatives like create_feature_class, leaving some ambiguity.
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?
Without annotations, the description carries the transparency burden. It discloses that the tool writes outputs to a PathGuard allowed root and requires `overwrite=true` for existing outputs. It does not detail other behavioral traits like error handling or coordinate system behavior, but the core behavior is adequately described.
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 at four sentences, front-loading the core function and immediately following with use cases. Every sentence adds value without redundancy or 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 inputs, purpose, and constraints (overwrite, PathGuard). With an output schema present, return values are documented elsewhere. The omission of coordinate system handling is minor and typical for GIS tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters, so the description adds only modest additional context (e.g., 'optional Y-axis orientation'). The baseline of 3 is appropriate given the high schema coverage; the description does not significantly enhance parameter understanding.
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 explicitly states the tool's function: creating a rectangular fishnet/grid using ArcPy CreateFishnet with specific inputs. It lists numerous concrete use cases such as sampling grids, planning units, and map production, clearly distinguishing it from sibling tools like 'create_feature_class' or 'dissolve_features'.
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 context for when to use this tool: 'before spatial join, summarize-within, raster conversion, QA/QC, or map production.' However, it lacks explicit guidance on when not to use it or alternative approaches, though given the specificity of the tool, this is a minor gap.
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 must disclose behavioral traits. It states that the tool writes a new output feature class without modifying inputs, but lacks details on prerequisite input geometry type (points) or projection requirements. Adequate but not thorough.
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 concise sentences: first defines the tool's action and resource, second adds usage guidance and constraints. No redundancy or 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?
Given the tool's moderate complexity and the presence of an output schema, the description covers key aspects: purpose, supported parameters, and non-destructive nature. However, it omits details like input geometry constraints (points) and output field contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions ellipse_size and weight_field, but the input schema already provides complete descriptions for all parameters. With 0% schema coverage claimed, the description adds minimal value beyond what is already 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?
Clearly states it creates standard deviational ellipse features using ArcPy DirectionalDistribution, and lists specific use cases like point-pattern analysis and movement corridors. This distinguishes it from sibling tools like mean_center or hotspot_analysis.
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?
Provides explicit use cases and mentions supported options (ellipse_size, weight_field) and non-modifying behavior. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks.
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?
The description explicitly states the tool is read-only on the source dataset: 'Reads in_features and writes out_features without modifying the source dataset.' This is a key behavioral trait. However, since no annotations are provided, the description carries full burden; it could disclose more (e.g., license requirements, performance implications), but the current disclosure 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 is extremely concise: two sentences, front-loaded with the core action and use case. No extraneous information, every sentence serves a purpose.
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 (one nested parameter object with multiple sub-parameters) and the presence of an output schema, the description sufficiently covers the tool's purpose and key behavioral aspect (non-destructive). It could mention output feature class properties, but the output schema likely covers that. Overall, it provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions in_features and out_features in passing, without detailing parameter semantics. However, the input schema itself provides thorough descriptions for each parameter (e.g., condition, overwrite, part_area, etc.). Since schema descriptions are rich, the description's minimal contribution is acceptable, but it does not compensate for the 0% schema description coverage as per guidelines.
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?
Description clearly states the tool removes small polygon holes/parts using ArcPy EliminatePolygonPart and writes output. It identifies the use case: cartographic cleanup, sliver removal, polygon interior simplification. However, it does not explicitly differentiate from sibling tools like simplify_features or multipart_to_singlepart, which are related but distinct 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 provides clear use contexts: 'cartographic cleanup, removing sliver holes, or simplifying polygon interiors by area or percentage thresholds.' It implicitly advises when to use this tool, but does not mention when not to use it or suggest alternative tools.
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 bears the full burden. It describes the read-write process, PathGuard restriction, and overwrite requirement. However, it does not specify whether the tool reprojects to WGS84 or preserves the input projection, nor does it mention selection behavior or attribute handling. Some important behavioral details are 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 extremely concise: three sentences that front-load the main action, then provide usage context and key constraints. Every sentence serves a purpose without 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?
Given the existence of an output schema (which presumably documents the return structure), the description covers input, output, overwrite, and path restrictions. It lacks explicit mention of coordinate transformation or attribute inclusion, but overall it is fairly complete for a straightforward export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for each parameter. The tool description adds little beyond, explaining the overall process (reading in_features, writing out_json) and the overwrite condition. Since schema coverage is effectively high (despite context claiming 0%), the description provides marginal added value.
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 exports features to a WGS84 GeoJSON file, specifies the underlying tool (ArcPy FeaturesToJSON), and provides usage context for sharing with web maps, APIs, etc. It differentiates from siblings like export_to_shapefile and import_from_geojson.
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 advises when to use the tool ('share vector data with web maps, APIs, notebooks, or non-Esri tools') but does not explicitly mention when not to use it or compare with alternative export tools. Still, the context is clear enough for 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?
Without annotations, the description must disclose behavioral traits. It states the operation (fill sinks), license requirement, and optional z_limit parameter. However, it does not clarify that the input raster is not modified, that a new output raster is created, or discuss overwrite behavior. The description provides basic context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a distinct purpose: action, use case, and additional requirements. It is front-loaded and contains no superfluous information.
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 raster analysis tool with an output schema and a single composite parameter, the description covers the essential use case, license, and key parameter. It is adequate for an agent to understand the tool's purpose and when to invoke it, though it could mention output characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (in_raster, out_raster, z_limit, overwrite). The description adds context for z_limit (controls maximum sink depth) but does not significantly augment the schema's explanations. With high schema coverage, the description's added value is marginal.
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 fills sinks/depressions in elevation rasters using ArcPy Spatial Analyst Fill. It specifies the context of hydrologically conditioning DEMs before flow direction, accumulation, watershed, or stream network analysis, which distinguishes it from sibling raster 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 explicit guidelines on when to use the tool: for hydrologically conditioning DEMs before hydrologic analyses. It also mentions the required Spatial Analyst license. It does not explicitly state when not to use it, but the context is 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?
No annotations are provided, so the description must carry the full burden. It discloses that it writes a point feature class, uses ArcPy MeanCenter, and respects PathGuard allowed roots. However, it does not mention potential side effects like overwriting or performance considerations for large datasets.
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 long, front-loaded with the main purpose, and includes essential use cases and parameter hints. Every sentence adds value, and there is no wasted wording.
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 (statistical calculation with optional weighting and grouping), the description covers the main points and typical uses. An output schema exists, so return values are documented separately. Could mention that output includes fields for coordinates and groups.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters (100% coverage), so the baseline is 3. The description adds context about PathGuard allowed roots and optional weight/case fields, but does not add significant meaning beyond what the schema already provides.
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 that the tool calculates the geographic mean center using ArcPy MeanCenter and writes a point feature class. It specifies the resource (mean center) and verb (calculate), and distinguishes from siblings by focusing on central tendency summary for incidents, facilities, etc.
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 typical use cases (summarizing central tendency of various spatial features) and mentions optional parameters. However, it does not explicitly state when not to use this tool or suggest alternatives like directional_distribution for dispersion.
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 full responsibility. It discloses that the tool reads in_features and creates out_features without modifying the source dataset, which is good. However, it does not mention error conditions (e.g., what happens if input is already singlepart), performance implications, or permission requirements. More behavioral context would elevate this score.
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: the first states the action and method, the second provides usage guidance. It is concise, front-loaded with the essential verb and resource, and contains no extraneous information. 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 that the tool has an output schema (not shown but present) and no annotations, the description covers the core purpose, usage context, and non-destructive behavior. It lacks details about output format or side effects, but for a simple split operation with an output schema, it is sufficiently complete. A small gap is the absence of edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for parameters are comprehensive and cover the meaning of in_features, out_features, and overwrite. The description adds only 'Reads in_features and creates out_features,' which adds minimal value beyond what the schema already provides. Since the schema already does the heavy lifting, a score of 3 is appropriate.
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 uses ArcPy MultipartToSinglepart to split multipart features into singlepart features, which distinguishes it from sibling tools that perform other operations (e.g., dissolve, merge). It identifies the resource (features) and the action (split).
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 the tool: 'before per-feature editing, counting, topology checks, joins, or analysis that requires one geometry part per row.' It does not explicitly list when not to use it, but the use cases imply that it is inappropriate when multipart geometry is needed. A clear exclusion or alternative would improve the score.
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 provided, so description bears full burden. It mentions reading in_raster and writing out_raster within PathGuard allowed roots, and exposes resampling_type and cell_size. However, it omits details on overwrite behavior, error handling, or performance impacts, leaving 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?
Three sentences: first defines purpose and method, second gives usage context, third lists key parameters and constraints. Efficient, well-structured, 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?
Given the rich schema and presence of an output schema, the description covers essential usage and constraints. It misses mention of required out_wkid and overwrite behavior, but these are in the schema, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes detailed descriptions for all parameters, so the description's mention of resampling_type and cell_size adds little new value. With high schema coverage, baseline 3 is appropriate.
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 reprojects a raster dataset into another CRS, using ArcPy ProjectRaster. It provides specific use cases like aligning DEMs and imagery, which distinguishes it from vector projection or resampling tools among siblings.
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 advises use before overlay, map algebra, extraction, or export, giving clear context. It implicitly excludes vector use but does not explicitly contrast with alternatives like resample_raster, which could refine guidance.
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 full burden. It discloses the high-level operation (reads in_raster, writes out_features) and references the ArcPy function, but does not detail side effects (creation of a new feature class, overwrite behavior, permissions, or impact on existing data). The overwrite parameter is documented in the schema, but the description misses emphasizing the destructive potential.
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 extremely concise: two sentences that efficiently state the action, the underlying tool, specific use cases, and input/output. No superfluous words; every sentence adds value.
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 that the input schema is detailed and an output schema exists (though not shown), the description provides a sufficient high-level overview. It covers the core functionality and typical applications. Minor omissions include handling of NoData, attribute preservation, and coordinate system behavior, but these are not critical for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters (e.g., simplify, in_raster, out_features). The tool description adds only a summary ('Reads in_raster and writes out_features'), which does not significantly enhance understanding beyond the schema. Since schema description coverage is high (all parameters have descriptions), baseline is 3.
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 ('Convert raster zones or classes to polygon features') and the specific resource ('using ArcPy RasterToPolygon'). It distinguishes from siblings by providing examples ('classified rasters, suitability classes, land-cover codes, or cell regions') and contrasts with the inverse tool polygon_to_raster, which is in the sibling list.
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 use cases ('Use this to vectorize classified rasters, suitability classes, land-cover codes, or cell regions') and suggests appropriate contexts ('GIS editing, overlay, and cartographic workflows'). However, it does not explicitly state when not to use this tool or mention alternatives like polygon_to_raster for reverse conversion.
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 convey behavioral traits. It states the tool requires a Network Analyst license, reads stops, and writes results to out_features. However, it does not detail side effects (e.g., whether inputs are modified) or behavior when overwrite is false. This is adequate but not rich.
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: first sentence defines the core function, second adds use cases and requirements. It is front-loaded and contains no redundant words.
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 moderate complexity and the presence of an output schema (not shown but noted), the description covers the routing workflow well. It lacks mention of output schema details, but those are provided elsewhere. Slightly incomplete in explaining the result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (0% description coverage but schema has detailed parameter descriptions). The description adds little beyond the schema, only reiterating the overall process. Baseline 3 is appropriate as the schema carries the semantic burden.
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's purpose: 'Solve the best route through ordered stop points using ArcPy Network Analyst MakeRouteAnalysisLayer.' This is a specific verb-resource pair, and it distinguishes the tool from siblings like closest_facility or od_cost_matrix.
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 lists explicit use cases (A-to-B routing, multi-stop field visits, logistics paths, etc.) and notes licensing requirements. It does not explicitly state when not to use or compare with sibling tools, but the 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions using ArcPy ApplySymbologyFromLayer, PathGuard constraints, and conditional saving. However, it does not disclose whether the operation is reversible, side effects of modifying the project, or failure scenarios. This is adequate but not rich.
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?
Three sentences, each serving a clear purpose: action+method, use case, and constraints. No redundant or vague phrasing. Very efficient.
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 rich input schema and presence of an output schema, the description covers the core functionality, use case, and key constraints. It could be improved by noting the permanent effect on the project when saved, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes detailed descriptions for all five parameters. The description reiterates the save behavior and PathGuard constraints but adds minimal new meaning beyond the schema. Since schema coverage is high, a baseline of 3 is appropriate.
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 (apply cartographic symbology), the resources (.lyrx file, target layer), and the specific use case (standardize styling before export/delivery). It distinguishes well from sibling tools, which include general layer operations but not symbology application.
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 'Use this to standardize colors, classifications, labels, renderers, and map styling before export or project delivery,' providing clear context. It does not explicitly list when not to use or alternatives, but given the lack of sibling tools for symbology, this is sufficient.
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 full burden. It discloses that it modifies the layout and saves the project when save=true, and mentions using internal properties layout.pageWidth and layout.pageHeight. However, it does not mention prerequisites (e.g., layout must exist) or potential side effects on layout elements.
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?
Three sentences with clear front-loading: first sentence states action, second gives use cases, third mentions save behavior. No unnecessary words.
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 5 parameters and an output schema, the description is fairly complete. It covers purpose, usage, and key behaviors. Missing mention of prerequisites like layout existence, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (low), so description must compensate. It mentions page_width, page_height, and save, but omits aprx_path and layout_name. The schema provides detailed descriptions for all parameters, so the description adds some value but not full compensation.
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's purpose: 'Change the physical page width and height of a selected ArcGIS Pro layout' and provides specific use cases ('switch between sheet sizes, portfolio formats, report pages, or print/export templates'). This distinguishes it from sibling tools like set_map_scale or export_layout_pdf.
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 usage guidance: 'Use this to switch between sheet sizes, portfolio formats, report pages, or print/export templates.' It does not explicitly exclude other scenarios or compare to alternatives, but the context is 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?
No annotations are provided, so the description bears full responsibility. It discloses that the tool changes the map frame camera and optionally saves the project. However, it does not discuss permissions, reversibility, or failure scenarios, leaving 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 three sentences, each serving a distinct purpose: action statement, usage guidance, and behavioral effect. It is compact and front-loaded with the essential information, with no superfluous 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?
Given the tool's five parameters and the presence of an output schema, the description covers the core purpose and typical use case. It could mention prerequisites or error conditions, but it is sufficient for most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters, including defaults and constraints. The description adds a brief mention of the save parameter and the internal functions used, but this does not significantly enhance understanding beyond 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 clearly states the tool sets a layout map frame extent to match a named layer, using specific functions. It distinguishes from siblings like set_map_scale or zoom_to_layer by focusing on layer-based extent. The context of use before export is explicit.
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 advises using this before exporting a layout to focus on a dataset or area, providing clear context. It does not explicitly list when not to use it or name alternatives, but the intended use case is well stated.
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 bears full responsibility. It discloses that the tool creates a new output feature class and does not modify inputs. However, it omits potential behaviors like geometry type requirements, coordinate system handling, or error conditions. The disclosure is adequate but not comprehensive.
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 only two sentences, each serving a distinct purpose: the first states what the tool does, the second provides usage guidance and behavioral notes. It is front-loaded with the key action and is free of filler or 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?
Given the tool's moderate complexity and the presence of an output schema (not shown), the description covers the main operation, inputs, and outputs succinctly. It mentions that inputs are unchanged and outputs are new. It could optionally discuss geometry type compatibility or preprocessing steps, but missing these does not leave a significant gap for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains detailed descriptions for all parameters (in_features, out_features, overlay_features, overwrite). The tool description does not add any additional parameter information, so it provides no extra value beyond the schema. With schema descriptions present, a baseline score of 3 is appropriate.
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 starts with a clear verb-resource pair: 'Create the non-overlapping parts of two feature layers using ArcPy SymmetricalDifference.' It immediately defines the tool's core function and differentiates from siblings like intersect or union. The use cases (compare boundaries, detect areas in only one dataset, isolate disagreement) further clarify purpose.
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 the tool: 'Use this to compare boundaries, detect areas present in only one of two datasets, or isolate disagreement between two polygon/line sources.' It does not provide explicit when-not-to-use or alternatives, but the specific use cases imply appropriate contexts. It also notes that inputs are not modified, which is helpful.
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 must fully disclose behavior. It states the tool 'reads the topology dataset and returns validation metadata,' but does not clarify that ValidateTopology may also write error features or require specific privileges. This omission could lead to incorrect assumptions about 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 three concise sentences: purpose, usage context, and output handling. Every sentence adds value without 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?
Given the tool's complexity and the absence of annotations, the description covers purpose, usage scenarios, and post-validation steps (inspect error feature classes in ArcGIS Pro). With an output schema available, the description does not need to detail return values, but it omits prerequisites like ArcPy license or path constraints already in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both parameters (in_topology with path constraints, visible_extent with extent options). The tool description adds no additional parameter information, so it does not enhance beyond the schema. With good schema coverage, baseline 3 is appropriate.
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 validates a geodatabase topology using ArcPy ValidateTopology, specifying the verb and resource. It differentiates from sibling tools like check_geometry or repair_geometry by focusing on topology rule validation after editing workflows.
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 'after editing, appending, repair, or geometry cleanup workflows,' providing clear context. It does not, however, mention when not to use it or list alternative tools, so it lacks exclusionary guidance.
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?
Given no annotations, the description carries the full burden. It discloses mutation ('Mutates the input dataset schema') and a safety constraint ('dataset must be inside a PathGuard allowed root'), which are essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise sentences: purpose, usage context, and behavioral detail. No wasted words; each sentence adds distinct value.
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 field addition tool with one parameter object, the description covers purpose, usage, mutation, and safety. An output schema exists (not shown but indicated), so return value details are unnecessary. Missing details like field type defaults are in the schema.
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 reported as 0%, so the description must compensate. It only restates the overall purpose ('Add one attribute field...') without explaining individual parameters. The schema itself contains descriptions, but according to the context signals, coverage is low, and the description does not mitigate this.
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 adds one attribute field to an existing feature class or table using ArcPy AddField. This is a specific verb+resource that distinguishes it from add_fields_batch, which adds multiple fields at once.
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 explicit usage context: 'Use this to prepare schema before imports, joins, calculations, or manual editing.' However, it does not explicitly state when not to use this tool or directly compare to alternatives like add_fields_batch.
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 provided, so the description carries full burden. It states the tool reads metadata only, does not modify the dataset, and uses a specific ArcPy method. It does not detail error handling or performance, but for a simple read operation, this is sufficient.
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 three sentences long, no extraneous text. It front-loads the core purpose, then gives usage guidance, and ends with a safety note. Every sentence adds value.
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 simplicity (one parameter, no nested objects), and the presence of an output schema, the description is nearly complete. It specifies the return values and use cases. Minor gaps: no mention of validation behavior or error cases, but adequate for most scenarios.
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% per context, meaning the tool description must compensate for parameter details. However, the description does not add any information about the 'dataset' parameter beyond what the schema already provides. The schema itself has a detailed description, but the tool description adds no additional value for parameter semantics.
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 returns xmin, ymin, xmax, ymax, and CRS metadata using ArcPy Describe().extent, which distinguishes it from sibling tools like describe_dataset. It specifies exact outputs and the method used.
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 lists use cases: before clipping, map export, fishnet creation, raster analysis, or spatial QA/QC. It also notes that it reads metadata only and does not modify data, implying safety. However, it does not explicitly 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.
- 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. It discloses key behaviors: operates on saved .aprx files (not live sessions), saves when save=true, and uses arcpy.mp addDataFromPath. It does not mention error conditions or permissions, but the core safety profile (non-destructive addition) is evident.
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?
Three tightly written sentences deliver purpose, usage context, and behavioral note without extraneous words. Every sentence earns its place, making it efficient for an AI agent to 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?
Given the presence of a comprehensive schema and an output schema (not shown), the description provides enough context: operation, data types, saved-file constraint, and save behavior. It could mention default map_name behavior or potential errors, but overall it is largely complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all four parameters with sufficient detail, so the baseline is 3. The tool description does not add additional semantic information about parameters beyond what the schema already provides, meeting the minimum but not exceeding.
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 'dataset to a map inside an .aprx project', and provides examples of supported data types. It distinguishes from live sessions and mentions the underlying arcpy method, leaving no ambiguity about the tool's function.
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 context for when to use the tool ('before styling, exporting, or layout automation') and mentions it operates on saved files, implying it's for batch/automation workflows. It does not explicitly contrast with sibling tools like remove_layer_from_map, but the unique operation (adding) is 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?
With no annotations, the description carries the full burden. It states the tool reads in_features and writes out_features, mentions PathGuard constraints, and the overwrite flag. It implies non-destructive behavior ('safe working copy') but does not detail what happens if input is a layer vs feature class or any size limits.
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: first sentence gives purpose and method, second adds PathGuard and overwrite context. No unnecessary words, well 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?
The description covers the essential context: input/output paths, PathGuard constraints, and overwrite behavior. It does not mention return values, but an output schema exists (not shown). It could mention that all features are copied, but overall it's sufficiently complete for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes parameters (in_features, out_features, overwrite) with clear descriptions. The tool description adds no additional semantic value beyond what the schema provides, so a baseline score of 3 is appropriate.
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 copies a feature class or layer using ArcPy CopyFeatures, preserving geometry, attributes, schema, and spatial reference. This distinguishes it from siblings like create_feature_class (empty creation) or export_to_shapefile (format conversion).
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 advises using it to create a 'safe working copy' and mentions PathGuard allowed roots and overwrite requirement. However, it does not explicitly state when not to use it or suggest alternatives like export_to_shapefile for format conversion.
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 present, so the description carries the full transparency burden. It discloses that the tool reads paths, writes output, and does not modify source datasets. This is valuable beyond the schema. However, it omits details like error behavior or workspace requirements.
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 three sentences, front-loaded with the core action. Every sentence adds value: purpose, use cases, and behavior. No wasted words, highly efficient.
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 input, operation, and output, and notes non-destructive behavior. The presence of an output schema (per context) reduces the need to describe return values. It does not mention parameter constraints or overwrite handling, but these are in the schema. For a tool with nested parameters and multiple use cases, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters, including path constraints and overwrite behavior. The tool description adds little new parameter-specific meaning beyond mentioning ArcPy Erase. Baseline 3 is appropriate given rich schema 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 clearly states the action ('Remove portions of input features that overlap an erase layer using ArcPy Erase') and identifies the resource (features). It provides explicit use cases (exclusion zones, masking, subtraction), which helps distinguish from siblings like clip_raster or intersect_features.
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 lists explicit use cases but does not mention when not to use this tool or suggest alternatives. While the purpose is clear, lacking exclusions or comparisons to similar siblings slightly reduces guidance.
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?
Discloses that it reads .xlsx, writes within PathGuard allowed roots, and requires overwrite=true for existing outputs. No annotations provided, so description carries full burden; could mention error handling but adequate for a simple import.
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?
Four sentences, front-loaded with purpose, no wasted words. Efficiently conveys action, use case, constraints, and condition.
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?
Covers main action, use cases, constraints, and overwrite behavior. Output schema exists but not shown; description does not explain return values or errors. For a simple tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description only indirectly references in_xlsx, out_table, and overwrite. Does not explain 'sheet' parameter, though schema descriptions cover it. With 0% schema description coverage, description partially compensates by adding context but lacks full parameter 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?
Clearly states it imports an Excel worksheet to a geodatabase table, names the underlying ArcPy function, and specifies the resource types (worksheet, table). Distinguishes from sibling tools like table_to_excel which does the reverse.
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?
Explicitly says to use for spreadsheet-based attributes, lookup tables, or external tabular data. Mentions overwrite requirement but does not provide explicit alternatives or when-not-to-use cases.
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 full burden. It discloses that the tool reads the .aprx project (read-only), writes output inside PathGuard allowed roots, and requires overwrite=true for existing files. It does not mention any other side effects, which is acceptable for a standard export 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 long, front-loading the core purpose and usage context. Every sentence adds value without verbosity, making it highly efficient for an AI agent to 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?
Considering the tool has six parameters (nested under one) and no annotations, the description covers the essential purpose, usage, and key behavioral constraints (PathGuard, overwrite). With an output schema presumably present, return values need no elaboration. Minor gaps exist (e.g., not mentioning that layout_name can be null to use the first layout), but overall completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (aprx_path, out_pdf, overwrite, resolution, layout_name, image_quality), covering 'schema_description_coverage' effectively. The description adds minimal extra value beyond stating the project is read and the output path constraints, so a baseline of 3 is appropriate.
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 exports a selected ArcGIS Pro layout to PDF using layout.exportToPDF. It distinguishes this from sibling tools like export_layout_png (PNG) and export_map_as_image (image) by specifying the PDF output format.
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 explicit usage context: 'print-ready map sheets, reports, submittals, or archival exports with controlled DPI and image quality.' It does not explicitly say when not to use or mention alternatives, but the context is clear enough for an AI agent to decide.
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 full burden. It discloses that the tool reads the .aprx project file and writes output within PathGuard allowed roots, and uses layout.exportToPNG. This provides sufficient transparency about disk operations and constraints.
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 sentences with no wasted words. Purpose is front-loaded, and key details (DPI, transparency, path constraints) are efficiently included.
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 an output schema exists (not shown), the description doesn't need return values. It covers high-level context, tool method, and path restrictions. Could mention error cases or required ArcGIS Pro license, but overall adequate for a parameter-rich tool with good schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema's property descriptions, but those descriptions are thorough. Baseline 3 is appropriate since the schema already covers parameter details (e.g., resolution, overwrite).
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 'Export a selected ArcGIS Pro layout to a PNG image', specifying the verb, resource, and format. It distinguishes from siblings like export_layout_pdf by focusing on PNG output and providing specific use cases (previews, portfolio images, web graphics).
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 explicit usage scenarios: 'Use this for previews, portfolio images, web graphics, or presentation-ready map layouts'. It implies when to use but does not explicitly mention when not to use or name alternatives like export_layout_pdf.
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. It discloses that the tool uses ArcPy ExportTable, writes to PathGuard allowed roots, and requires overwrite=true for existing files. These details provide adequate transparency for a read 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 concise with three sentences: purpose, use cases, and behavioral details. No extraneous information. Front-loaded with the core action.
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 input constraints, output behavior, and overwrite rules. With an output schema present, return values are not needed. It is complete enough for the tool's simplicity, though could mention error handling or large dataset considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters. The tool's description reinforces the PathGuard constraint and overwrite behavior but does not add significant new semantic information beyond summarizing the schema. Given high schema coverage, a score of 3 is appropriate.
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 'Export' and the resource 'feature class or table', and specifies the output format 'CSV'. It differentiates from sibling export tools by mentioning specific use cases (notebooks, data pipelines, reports, non-GIS 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 states when to use the tool ('move attribute data into notebooks, data pipelines, reports, or non-GIS tools'), providing clear context. It does not explicitly mention when not to use or name alternative tools, but the context is adequate for an AI agent to decide.
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 full burden. It discloses that the tool reads an input table and writes a new output table, must use PathGuard allowed roots, and that overwrite=true is needed for existing outputs. However, it does not mention error handling, performance implications, or license requirements.
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 concise sentences plus one additional sentence. It is front-loaded with the purpose, immediately followed by use cases and then a constraint. Every sentence adds value and there is no redundancy or 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 the tool's purpose, typical usage, and key behavioral constraints (input/output, PathGuard, overwrite). It does not detail the output table structure (e.g., fields: combination fields + frequency count), but the output schema is noted as existing which should fill that gap. For a simple frequency-counting tool, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all four parameters (in_table, out_table, overwrite, frequency_fields). The description adds only overarching context (e.g., 'using ArcPy Frequency', PathGuard) but does not enrich parameter meanings beyond what the schema provides. With schema coverage effectively 100%, the baseline 3 is appropriate.
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 counts unique combinations of attribute values via ArcPy Frequency. It specifies the action (count), resource (attribute values), and method (ArcPy Frequency). This distinguishes it from sibling tools like statistics_analysis or summarize_within which aggregate differently.
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 use cases: profiling categorical fields, detecting duplicates, summarizing classes, and preparing frequency tables for QA/QC and reporting. It implies when to use but does not mention when not to use or list alternative tools, which would raise the score to 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?
No annotations provided, so the description carries the full burden. It discloses that the tool creates a feature class (write operation) and lists output fields, but does not mention prerequisites like ArcGIS license, performance implications, or error handling.
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 concise sentences: the first states the core action and output, the second provides usage guidance and parameter summary. No wasted words.
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 (spatial statistics) and the presence of parameter descriptions in the schema, the description covers the algorithm, output fields, use case, and supported parameters. It is mostly complete, though it could mention that the input field must be numeric.
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 context indicates 0% schema description coverage, so the description must compensate. It adds context about the algorithm (ArcPy HotSpots) and result fields, and summarizes the key parameters (spatial conceptualization, distance method, optional distance band). However, it does not detail parameter constraints beyond what the schema already provides.
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 runs Getis-Ord Gi* hot and cold spot analysis using ArcPy HotSpots and writes a feature class with specific result fields (GiZScore, GiPValue, Gi_Bin). The purpose is specific and distinct from sibling tools like spatial_autocorrelation.
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 states when to use the tool ('identify statistically significant clusters') and mentions supported parameters, but does not explicitly say when not to use it or identify alternatives among sibling tools.
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 discloses constraints (PathGuard allowed roots) and behavior (overwrite required for existing outputs), but does not detail error handling or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous words, front-loaded with purpose. Every sentence adds value.
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 has multiple parameters and an output schema (per context), the description covers input, output, and constraints adequately, but could elaborate on return values or error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description is the sole source. It adds context for 'in_json' and 'out_features' (PathGuard, overwrite), but the 'overwrite' parameter is only mentioned in passing, and not all parameters are described in detail.
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 converts GeoJSON to an ArcGIS feature class using ArcPy JSONToFeatures, specifies the verb 'convert' and the resource, and distinguishes from sibling tools like export_to_geojson.
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 context for when to use the tool ('bring web, API, or exchange-format vector data into a geodatabase'), but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It mentions that the tool 'updates the saved .aprx project when save=true' and uses map.moveLayer internally. This is adequate for a non-destructive reordering operation, though it could note that the change is persistent if saved.
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 extremely concise with two sentences. The first defines the action and method, and the second provides usage examples and the save behavior. No unnecessary words 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 reordering tool, the description covers the core functionality, usage context, and the important save effect. The output schema (if present) would cover return values. With no annotations, the description compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all parameters (e.g., aprx_path, layer_name, position). The description adds general usage context but does not elaborate on parameter specifics. Since schema coverage is high, the baseline is 3.
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 moves a named layer relative to a reference layer in the map drawing order. The verb 'move' and resource 'layer' are specific, and the purpose is distinct from sibling tools like add_layer_to_map or remove_layer_from_map.
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 context for when to use the tool (e.g., 'control cartographic stacking') and gives concrete examples ('placing boundaries above imagery'). It does not explicitly exclude alternatives, but the guidance is sufficient for selecting this tool over unrelated ones.
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 and discloses key behaviors: the tool mutates the project structure, does not delete underlying datasets, and requires confirm=true. It does not cover error cases or permissions but is adequate for safe usage.
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 four concise sentences, each serving a purpose: action statement, use-case guidance, behavioral note, and parameter requirement. It is front-loaded with the core action and avoids extraneous 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?
Given the tool's moderate complexity (5 parameters, output schema present), the description covers the key aspects: purpose, usage, safety (confirm, no data deletion). It lacks error handling or default behavior for map_name, but the schema supplies parameter details. Overall sufficient for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (e.g., aprx_path includes path constraints, confirm explains mutation). The tool description restates that confirm must be true but adds no new parameter-level information beyond what the schema already covers.
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 ('Remove'), the resource ('a named layer from a map'), and the context ('inside a saved ArcGIS Pro .aprx project'). It distinguishes from siblings like add_layer_to_map or rename_layer by specifying it is for removal and map cleanup before export or packaging.
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 explicit usage context ('controlled map cleanup before export, packaging, or automated project updates') and notes the required confirm parameter. However, it does not explicitly list when not to use it (e.g., for hiding layers use set_layer_visibility) or alternative tools among siblings.
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 provided, so description carries the burden. It states the tool 'reads in_features, applies where_clause, and writes selected rows to out_features,' which gives basic behavior but lacks details on overwrite behavior, error conditions, or permission needs. It does not contradict any annotations.
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-loaded with the main purpose and immediately followed by usage guidance. Every sentence adds value with no wasted words.
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 presence of an output schema and the tool's moderate complexity (4 params, 1 required), the description covers the core functionality, usage context, and high-level parameter roles. It does not detail overwrite or path constraints, but those are in the schema, so completeness is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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. It names the three main parameters (in_features, where_clause, out_features) and explains their role in the action, but does not add detailed semantics beyond what the schema's property descriptions already provide. This is adequate but not exceptional.
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 materializes a SQL attribute query into a new feature class using ArcPy Select, which is a specific verb and resource. It also distinguishes from siblings like select_by_location by specifying 'saved subset rather than an in-memory layer selection.'
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?
The description explicitly says 'Use this when a stateless MCP workflow needs a saved subset rather than an in-memory layer selection,' providing clear when-to-use and implying alternatives. This differentiates from other selection tools.
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 burden. It states the tool writes an output feature class and does not mutate source features, and automatically detects shape type to choose between SimplifyPolygon and SimplifyLine. This adds meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: first for core purpose, second for use cases, third for behavioral note. No wasted words, well-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?
Given the tool's complexity, the description adequately covers purpose, usage scenarios, and non-destructive nature. With an output schema present, return values need not be explained. Missing are error handling and prerequisites like ArcPy license, but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not elaborate on parameters; however, the input schema includes detailed descriptions for each property (e.g., algorithm enum, tolerance units). Since the schema provides adequate parameter semantics, the description adds no additional value, warranting a baseline score of 3.
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 simplifies polygon or polyline geometry using specific ArcPy functions and detects shape type automatically. It specifies the resource (geometry) and verb (Simplify), and distinguishes from smooth_features by focusing on vertex density reduction.
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 explicit use cases: cartography, web export, performance, scale-appropriate analysis. However, it does not mention when not to use it or alternative tools like smooth_features, missing some context for tool selection.
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 discloses that the tool only reads in_features and does not create or modify datasets, which is key for safety. It does not detail other potential behaviors like license requirements, but covers the main non-destructive aspect.
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 concise sentences that front-load the verb and resource, with no wasted words. The structure is efficient and clear.
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 and lack of annotations, the description adequately covers its purpose, usage context, output (scalar statistics), and non-destructive nature. It omits details like output schema structure, but that is covered by the existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no additional parameter information beyond what is already provided in the input schema, which itself includes detailed descriptions for each parameter. Thus the schema does the heavy lifting.
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 calculates Global Moran's I and returns specific scalar statistics. It distinguishes from sibling tools like hotspot_analysis by positioning it as a precursor to local analysis.
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 advises using the tool to test for clustering before choosing local hotspot or modeling workflows, providing clear context for when to use it versus alternatives.
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. The description discloses that it reads input and writes .xlsx within PathGuard allowed roots, and requires overwrite=true for existing files. This adds behavioral context beyond the schema, though it does not mention potential failures or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core functionality and the second adds usage context and a key constraint. No redundant information, perfectly 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?
The description covers the essential purpose, usage, and constraints. An output schema exists, so lack of return value explanation is acceptable. It is missing details on error conditions or support for older .xls format, but for a simple export tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for each parameter (table, out_xlsx, overwrite). The tool description echoes key constraints ('PathGuard allowed roots', 'overwrite=true') but adds no new meaning beyond the schema. Given the high schema coverage, baseline 3 is appropriate.
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 'Export an attribute table or feature class table to an Excel workbook' using a specific tool. It specifies the action (export), resource (table/feature class), and output format (Excel). This distinguishes it from siblings like excel_to_table, feature_to_csv, and export_to_geojson.
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 says 'Use this to share tabular GIS attributes with analysts, reports, or spreadsheet workflows,' giving clear usage context. However, it does not explicitly mention when not to use it or compare with alternatives like csv export, so guidance is slightly implicit.
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?
The description states the tool does not modify data, which is critical behavioral transparency given no annotations are provided. It also describes the output fields, but could mention error conditions or performance implications.
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 concise sentences: the first states the action and method, the second provides usage context and return details. No superfluous information.
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 read-only tool with one parameter and an output schema, the description covers purpose, usage context, and behavior completely. It explains what it returns and that it is non-destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema's detailed description of the dataset parameter (absolute path, PathGuard constraint). With 0% schema description coverage indicated, but the schema itself is informative, a baseline of 3 is appropriate.
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 lists field metadata for feature classes or tables using ArcPy ListFields, specifying what it returns (names, types, lengths, aliases, nullable status). This distinguishes it from sibling tools that modify data, such as add_field or delete_field.
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 before calculating, deleting, joining, or exporting attributes, providing clear context for when to inspect schema. While it does not list alternatives, the sibling tools' write operations make the use case 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?
The description explicitly states 'Reads the project only and does not save or mutate the .aprx file', which is critical behavioral information. Since no annotations are provided, the description carries the full burden and handles it well, though it could mention potential errors or access requirements.
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 extremely concise, containing only two sentences that directly convey the purpose, usage, and safety. Every sentence earns its place, 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, output schema provided), the description covers purpose, read-only nature, and usage context completely. No additional information is needed for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description for aprx_path, including constraints on PathGuard and that it operates on saved files. The tool description does not add new information about the parameter, and with 0% schema coverage, it does not compensate as expected. However, the schema description is sufficient, so the lack of addition is not harmful.
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 explicitly states 'List all layouts in a saved ArcGIS Pro .aprx project using arcpy.mp listLayouts', clearly specifying the verb and resource. It also mentions the use case of discovering layout names, page sizes, and page units, which distinguishes it from sibling tools like list_layers or list_maps.
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 advises to use this tool 'before exporting or modifying a layout', providing clear context. While it does not explicitly mention when not to use it or alternatives, the usage guidance is practical and sufficient for the typical workflow.
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?
No annotations are provided, so the description bears full responsibility. It clearly explains that the tool modifies only the map layer's display name, not the underlying dataset, and that it saves the project when 'save=true'. This provides necessary behavioral context.
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 three sentences long, each adding value. The first sentence states the core action, the second provides a use context, and the third clarifies scope and side-effect. No unnecessary words.
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 moderate complexity with 5 parameters and an output schema. The description covers purpose, scope, and key behavior. It does not detail return values, but this is acceptable since an output schema exists. Minor gaps in parameter explanation are partially offset by the schema descriptions (though coverage is stated as 0%).
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?
Context signals indicate 0% schema description coverage, meaning the description must compensate. However, the description only mentions the 'save' parameter effect and does not explain 'aprx_path', 'layer_name', 'new_name', or 'map_name'. This is insufficient for a tool with 5 parameters.
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: renaming a layer in the ArcGIS Pro Contents pane by updating 'lyr.name'. It distinguishes itself from sibling tools like 'rename_dataset' by specifying it renames only the map layer, not the underlying dataset.
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 a use case: 'to make automated map outputs clearer before export, handoff, or presentation.' It implies when to use but does not explicitly state alternatives or when not to use. Given the sibling tools, the guidance is adequate but not exhaustive.
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 full burden. It discloses that the tool rewrites geometry in place, may delete null geometries, and requires confirm=true. It lacks details on permissions or performance, but covers key destructive behaviors.
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 concise sentences, front-loaded with purpose and usage, followed by a behavioral caveat. Every sentence adds value with no 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?
Given the tool's complexity and lack of annotations, the description is mostly complete: it covers purpose, usage, and key behavior. It assumes knowledge of invalid geometry definitions and prerequisites but is adequate for typical use. An output schema exists so return values need not be explained.
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. It only adds that confirm=true is required, which is already in the schema. The description does not address delete_null or in_features beyond the schema, which already has good descriptions. Thus, it adds minimal value.
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 repairs invalid feature geometry using ArcPy RepairGeometry, and distinguishes from sibling tools like check_geometry by specifying it is used after checking for problems or before operations requiring valid shapes.
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?
The description provides explicit usage context: use after check_geometry or before overlay/topology/network/export operations. It implies when not to use (if no geometry problems) and references a sibling tool (check_geometry) as prerequisite.
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, the description fully discloses that the operation is destructive ('irreversibly overwrites column values'), that PYTHON3 executes code in the worker (potential arbitrary code execution), and that confirm=true is required for safety. This exceeds expectations.
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 sentences front-loading purpose and key guidelines. Zero wasted words; every sentence adds value.
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 (destructive, code execution risk, multiple expression types), the description covers purpose, safety, and recommended usage. With a detailed input schema and output schema, it is adequately complete, though could mention the PathGuard dependency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters. The tool description adds marginal value by emphasizing the confirm requirement and ARCADE preference, but does not provide new meaning beyond 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 explicitly states the verb ('Calculate') and resource ('existing field'), and distinguishes from siblings like 'add_field' and 'calculate_geometry' by specifying 'existing field' and 'controlled attribute updates'.
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 recommends using ARCADE for LLM-facing workflows and warns about PYTHON3 requiring confirm=true. It does not explicitly compare to all siblings but gives clear guidance on expression type selection.
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?
The description explicitly states that the operation is irreversible, mutates the input dataset, and requires confirm=true. With no annotations provided, this full behavioral disclosure is critical and well-done.
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?
Three concise sentences efficiently convey purpose, usage, and behavioral traits without excess. Key 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?
Given the presence of an output schema, the description adequately covers what is needed: purpose, usage, behavior, and key parameters. It could be slightly more explicit about the need for a copied dataset, but the instruction 'use only on an intended working dataset' suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is reported as 0%, so the description must compensate. It mentions 'selected fields' and 'optional geometry tolerance' and notes that confirm=true is required, adding some meaning beyond the schema. However, it does not fully describe all parameters, such as the dataset path.
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 'Delete duplicate rows', the resource 'feature class or table', and the method 'ArcPy DeleteIdentical' with key parameters. It distinguishes itself from sibling tools like delete_dataset or delete_field by focusing on row-level deduplication.
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 advises using the tool only on an 'intended working dataset', implying not on original data. This provides clear context for usage, though it does not explicitly list alternative tools for other scenarios.
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 full burden. It discloses that the tool is read-only ('does not modify layer state') and operates on the saved project file only. While it does not detail permissions or error conditions, it is transparent about the core 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 three sentences with no redundancy. Each sentence serves a distinct purpose: what it does, when to use it, and its scope/behavior. 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?
Given the tool's simplicity and the presence of an output schema (handling return values), the description adequately covers the tool's purpose, usage, and constraints. It could mention that the map must exist in the project, but this is implied by the read operation.
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?
Although schema description coverage is low (0% per context), the tool description adds value beyond the schema by noting that 'map_name' can be None to target the first map. This compensates for the missing schema documentation and helps the agent understand parameter usage.
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 (List), resource (layers in a selected map), and specific details (visibility, group-layer status, data source). It distinguishes from sibling tools like 'list_layers' by specifying 'in a map' and the exact use case for discovering layer names before 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 explicitly states when to use the tool ('before visibility, ordering, symbology, rename, or zoom operations') and clarifies that it only reads the saved .aprx and does not modify state. It does not list exclusions or alternative tools, but provides sufficient context for 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?
The description notes it 'Reads the project file only and does not modify or save it', which is key safety info. No annotations exist, so description carries the behavioral burden. Missing details on potential errors or exact return format (handled by output schema).
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?
Three concise sentences: function, usage context, and safety guarantee. No extraneous words; efficiently packed.
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 list tool with one parameter and an output schema, the description covers purpose, usage, and safety. Lacks explicit error handling and return format description, but is largely complete.
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 parameter aprx_path is well-described in the schema with path constraints and behavior. The description adds usage context but no extra parameter details. Despite schema coverage signal being 0%, the property description is adequate.
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 function: 'List map names inside a saved ArcGIS Pro .aprx project'. It specifies the resource (map names in an .aprx project) and differentiates from siblings like list_layers by focusing on maps.
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?
Explicitly says when to use: 'before map-scoped operations when the target map name is unknown or when validating project contents'. It implies not needed if map name is known, but does not explicitly exclude alternatives like list_layers_in_map.
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 provided, so the description carries full burden. It discloses that the tool reads in_features, writes out_features within PathGuard allowed roots, requires overwrite=true for existing outputs, and supports an optional transform_method for datum differences. This adequately describes the write operation and key constraints.
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 (three sentences) and front-loaded with the main purpose. Every sentence adds relevant information without wasted words.
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 presence of an output schema and comprehensive schema descriptions, the description is fairly complete. It covers the main operation, constraints, and optional parameter. Minor missing details (e.g., error handling, licensing) are acceptable given the schema richness.
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 descriptions cover all parameters, so the bar is lower. The description adds value by explaining that transform_method is needed 'when datums differ' and that overwrite is for replacing existing outputs. This goes slightly beyond the schema baseline of 3.
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 transforms vector feature classes/layers into another coordinate system using ArcPy Project. It specifies the verb 'transform', the resource 'vector feature class or layer', and distinguishes from siblings like project_raster (raster) and define_projection (assigns CRS without transformation).
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 lists use cases: overlay, distance measurement, map export, analysis, alignment with other datasets. It implies by context (vector vs raster) when not to use, but lacks explicit alternatives or when-not-to-use statements.
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?
Discloses mutation (add/update fields) and recommends running on intended working dataset. No annotations provided, so description covers key behavioral traits, though could explicitly mention overwrite 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?
Three sentences front-load action, then use cases, then behavior. No fluff, every sentence adds value.
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 simple tool with one parameter and output schema, description covers purpose, use cases, and mutation. Prerequisites (point features) are clear. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has a detailed description for the single parameter (path with PathGuard). Tool description does not add new semantics beyond repeating schema info, meeting baseline.
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 adds or updates POINT_X and POINT_Y fields on point features using ArcPy AddXY, distinguishing it from generic field tools.
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?
Explicitly lists use cases (export, QA/QC, labeling, tabular analysis, integration) and warns about mutation, guiding when to use and caution.
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 provided, so description carries full burden. It clearly states the operation is irreversible and mutates local project data, and that confirm=true is required. This provides essential behavioral traits, though additional detail about permanent disk removal or effects on dependent items could enhance transparency.
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-loading the action and resource types in the first sentence, and irreversibility and requirements in the second. No wasted words; every sentence adds essential information.
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 simplicity (one required parameter, a confirmation flag) and existence of an output schema, the description covers key aspects: what it deletes, irreversibility, confirm requirement, and path constraint. It does not discuss error conditions or return values, but the output schema handles return values. Overall 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?
Context indicates schema description coverage is 0%, so description must compensate. The description explains the confirm parameter must be true and the dataset must be an absolute path inside a PathGuard allowed root, adding critical meaning beyond parameter names. The schema itself also has descriptions, but following given context, the description adds unique value.
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 deletes an existing feature class, table, raster, or geodatabase item, using the specific verb 'Delete' and resource 'dataset'. It differentiates from siblings (e.g., delete_field, delete_identical) by specifying the 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 mentions that confirm=true is required and the dataset must be inside a configured PathGuard allowed root. It implies usage for deleting datasets but does not explicitly contrast with alternative deletion tools or provide when-not-to-use scenarios. However, among siblings, no other tool deletes entire datasets, so guidance is 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 must cover behavioral traits. It discloses that the tool 'mutates the input schema and drops data', which are key destructive aspects. It also notes the confirm=true requirement. It could further mention irreversibility or permission needs, but the core behavior is well communicated.
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 long, with the first sentence clearly stating the action and method, and the second adding critical usage context. Every word serves a purpose; no fluff 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?
Given the tool's simplicity and the presence of a detailed input schema with parameter descriptions, the description covers purpose, usage, and behavioral effects completely. The output schema exists (not shown but noted) so return values are not needed in the description.
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 already includes descriptions for all parameters (fields, confirm, dataset). The description reinforces the confirm parameter's necessity and adds the context that system-required fields cannot be deleted. This provides additional clarity beyond the schema alone.
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 ('delete one or more fields') and the resource ('feature class or table'), using a specific verb and noun. It also references the underlying ArcPy function, providing precision. This distinguishes it from sibling tools like add_field or calculate_field.
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 context: 'Use this only when unwanted attribute columns should be permanently removed.' This tells the agent when to choose this tool. It also mentions the confirm=true requirement. However, it does not explicitly list alternatives or situations where it should not be used.
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 explicitly states 'Reads metadata only and does not modify the dataset,' which is a key behavioral trait. This is sufficient for a non-destructive tool, though it does not cover error conditions or prerequisites.
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-loaded with the main action and followed by usage guidance and safety note. Every sentence earns its place with no wasted words.
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 simplicity of the tool (one parameter, read-only), the description covers all necessary context: what it does, what it inspects, and that it does not modify data. An output schema exists, so return values do not need elaboration. The description is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'dataset' is described in the schema with path requirements. The description adds meaning by explaining that the tool inspects data type, geometry, CRS, and extent, which clarifies the purpose of the parameter. Schema description coverage is 0% per context (though parameter has schema description), so the description compensates well.
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's purpose: describe an existing dataset using ArcPy Describe. It specifies the types of datasets (feature class, table, raster, geodatabase item) and the information returned (data type, geometry type, CRS, extent). It distinguishes itself from siblings by advising use 'before choosing an analysis tool.'
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 guidance on when to use this tool ('before choosing an analysis tool') and emphasizes it is read-only. However, it does not explicitly mention when not to use it or provide direct alternatives from the sibling list, though the context is 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 must disclose behavioral traits. It mentions that overwrite must be true to replace an existing output, indicating explicit opt-in. It also describes the return format. However, it does not clarify whether input data is modified (likely not, but not stated) or detail error behavior for invalid tool names. The description adds useful context but could be more comprehensive.
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 brief opening sentence, followed by a bullet-like list of parameters. Every sentence adds value without redundancy. The key 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?
Given the tool's complexity (5 parameters, nested object, no annotations), the description covers the essential aspects: allowed tools, parameter meanings, overwrite behavior, and return format. It mentions allowed roots and scratch GDB for context. However, it could include more on error cases or the validation of tool names. The presence of an output schema partially compensates for missing return details.
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 has 0% description coverage, so the description must compensate. It explains each parameter: tool as allowlisted name, in_features as absolute path, parameters with tool-specific examples, out_features as optional auto-naming, and overwrite as explicit opt-in. This adds significant meaning beyond 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 clearly states the tool executes an allowlisted geoprocessing tool, with specific examples (Buffer_analysis, Clip_analysis). This distinguishes it from sibling tools which are individual geoprocessing tools, making the purpose and scope immediately clear.
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 implies that this tool is for running specific tools not individually exposed, and lists which tools are allowed. However, it does not explicitly state when to use this tool versus the dedicated sibling tools, nor does it provide guidance on when not to use it. The examples provide some context, but explicit alternatives or exclusions would improve clarity.
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?
Without annotations, the description carries full burden. It discloses spawning a real worker without importing arcpy, and reports specific outputs. This is sufficient for understanding the tool's behavior, though it could mention if there are no 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?
Two sentences that front-load the core purpose and then provide key details. Every sentence adds value; no wasted words.
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 tool with no parameters and an output schema present, the description is complete. It explains the tool's function, what it returns, and its recommended use case.
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?
With zero parameters and 100% schema coverage, the description adds meaning beyond the empty schema by explaining what the tool does and its output, compensating for lack of parameters.
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's purpose: verify the full execution pipeline from server to conda worker and back. It specifies that it spawns a worker process and reports interpreter version and configuration summary, distinguishing it from all sibling tools which are GIS 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 explicitly says 'Use this first when diagnosing connectivity,' providing clear when-to-use guidance. It does not mention when not to use or alternatives, but the sibling context makes alternatives irrelevant.
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 full burden. It reveals the return format (ListLayersOutput JSON with workspace, layers, elapsed_seconds) and parameter behavior. It does not mention side effects, authentication, or performance limits, but it is transparent about being a read operation on a file geodatabase.
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, using a docstring format with clear Args and Returns sections. It front-loads the main purpose and includes no unnecessary words.
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 simplicity and the presence of an output schema, the description is largely complete. It covers inputs and output format. Minor gaps include not specifying whether the list is recursive or limited to top-level datasets, or any restrictions on workspace roots.
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. It explains each parameter fully: workspace is an absolute path to a .gdb, dataset_filter is an optional wildcard. This adds significant meaning beyond the schema's type declarations.
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 it lists feature classes, tables, and rasters inside a file geodatabase. This is a specific verb-resource combination that distinguishes it from siblings like list_layers_in_map (which lists layers in a map document) and other geodatabase 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 context for when to use the tool (to list contents of a file geodatabase). It does not explicitly state when not to use it or mention alternatives, but the context is sufficient and the tool's scope is well-defined.
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, the description carries full behavioral disclosure. It explicitly states the tool mutates the input by adding/updating NEAR_FID and NEAR_DIST fields, requires confirm=true, and recommends using a copy. This fully informs an agent of the mutation risk and safety measures.
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?
Three concise sentences with no fluff. The first sentence states the core purpose, the second explains the mutation effect and prerequisite, and the third gives safety guidance. Highly efficient.
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 mutating tool with an output schema, the description covers all necessary context: what it does, what it changes, what input validation is needed, and best practices. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains good descriptions for all parameters (100% coverage). The tool description reiterates the mutation and confirm requirement but adds no new parameter-specific meaning beyond the schema. Per guidelines, baseline 3 is appropriate.
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 starts with a clear verb ('Calculate nearest-neighbor distance') and specifies the resource ('each input feature'). It distinguishes from siblings like 'generate_near_table' by highlighting mutation and the confirm requirement.
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 advises using a copied working dataset when exposing to an LLM/automated agent and requires confirm=true. It does not explicitly name alternatives for non-mutating scenarios, but the advice is clear for this tool's mutation behavior.
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?
Despite no annotations, the description discloses that it mutates the workspace namespace but does not edit geometry or attributes, and requires a path inside PathGuard allowed root. This fully informs the agent of behavioral traits and constraints.
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-loaded with the action and method, and each sentence adds essential information without 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?
The description, combined with the schema and output schema (not shown), covers purpose, parameters, behavior, and constraints. It mentions mutation, no geometry changes, and PathGuard, making it complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaningful information beyond what is already in the input schema parameter descriptions. The schema itself provides detailed semantics for 'dataset' and 'new_name', so the description's contribution is minimal.
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 'rename' and the resource 'dataset', specifying it operates within the same workspace and is for intermediate feature classes, tables, or rasters. This distinguishes it from siblings like delete_dataset or describe_dataset.
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 says 'Use this for controlled cleanup of intermediate...' providing a specific use case. It does not explicitly mention when not to use or provide alternatives, but the context implies it is the only rename dataset tool.
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. It discloses the operation (aprx.save), the scope (operates on saved .aprx file), and the return value (saved project path). The behavior is transparent and no contradictions.
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 three sentences: first states the action, second gives usage context, third specifies constraints and return. Every sentence adds value with no 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 simple save tool with one parameter and no annotations, the description is fully complete. It explains the operation, when to use, parameter constraints, and return value, covering all needed context.
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 single parameter aprx_path has 0% schema description coverage, but the tool description adds crucial meaning: it must be an absolute path inside a PathGuard allowed root, and operates on saved project files, not live sessions. This compensates well.
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 saves an ArcGIS Pro .aprx project using aprx.save, specifying the resource and action. It differentiates from sibling tools by being the only tool that explicitly persists project changes.
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 context on when to use the tool: after a sequence of changes when persistence is needed before export or handoff. It implies not to use if no persistence required, though no explicit alternatives are mentioned since none exist.
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 provided, but the description clarifies it is read-only ('does not modify data') and operates within PathGuard allowed roots. This adds important behavioral context beyond the name.
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 (three sentences) and well-structured, starting with the core purpose and then providing usage guidance and behavioral notes. Every sentence adds value.
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 simplicity and the presence of an output schema (not shown but indicated), the description adequately covers purpose, usage, parameters, and behavior. No gaps are apparent.
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 single parameter 'dataset' is thoroughly described: it explains the expected input types (feature class, table, raster, geodatabase item) and security constraint (PathGuard allowed root). This 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 explicitly states 'Return the row or feature count for an existing dataset' and positions it as a lightweight validation step. This clearly distinguishes it from sibling tools that perform more complex analyses.
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 advises using it 'before and after geoprocessing, filtering, import, export, or QA/QC workflows', providing clear usage context. It lacks explicit alternatives but is sufficient.
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 fully discloses that the tool is a pure lookup, has no filesystem input/output, and does not modify datasets. It also indicates the kind of information returned (CRS name, type, datum, units), which compensates for the lack of annotations.
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 redundant words, front-loading the action and adding necessary context efficiently.
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 lookup tool with one parameter and an output schema, the description fully covers the purpose, usage, and behavioral constraints, making it complete without exceeding needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% per context signals, but the description does reinforce the parameter's purpose (WKID/EPSG) and usage context. However, it does not add new information beyond what the schema's parameter description already provides, so a baseline 3 is appropriate.
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 it looks up an ArcGIS spatial reference by WKID or EPSG code using arcpy.SpatialReference, which is a specific verb and resource. Among sibling tools, this is distinct from projection or modification tools like define_projection or project_features.
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?
The description explicitly advises using it before projection workflows to verify CRS attributes, and clarifies it is a pure lookup with no filesystem I/O or dataset modification, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully discloses behavioral traits: it is metadata-only, does not transform coordinates, mutates the dataset definition, requires confirm=true, warns of downstream analysis corruption if wrong WKID is used. This is comprehensive and beyond what the schema provides.
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?
Three sentences, front-loaded with action and purpose. Every sentence provides essential information without redundancy. Highly efficient.
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 critical nature of this metadata-mutation tool and no annotations, the description covers purpose, usage guidelines, behavioral implications, and required confirm parameter. It is fully adequate for an agent to invoke 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 input schema already provides descriptions for all parameters (wkid, confirm, dataset). The description reinforces the confirm requirement and the 'mutates dataset definition' aspect, adding context beyond the schema. However, it does not add new parameter-level details beyond the schema's existing 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 clearly states it assigns coordinate reference metadata using ArcPy DefineProjection and a WKID/EPSG code. It explicitly distinguishes itself from transformation tools like project_features by noting it is metadata-only, which differentiates it from siblings.
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?
Provides explicit when-to-use guidance: 'Use this only when the dataset coordinates are already in the specified CRS but the spatial reference is missing or unknown.' This clearly defines the appropriate context and implies 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.
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/muend/arcgis-mcp-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server