state_gis_parcels

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, so safety is already disclosed. The description adds context about the data source (ArcGIS), the return fields (parcel ID, owner name, address, land area, use codes), and filtering capabilities. However, it does not disclose behavioral traits like pagination, rate limits, or default response size beyond what the schema states for the limit parameter. This is consistent with annotations, so no contradiction, and adds modest value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences with no filler. It opens with the primary action and resource, followed by return fields and filter options. Every sentence contributes useful information, making it appropriately sized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a query tool with no output schema, the description lists the key return fields and explains the filtering mechanism. It lacks information on result ordering, pagination, or error handling, but the presence of a 'limit' parameter in the schema mitigates the pagination gap. Given the moderate complexity and that annotations already cover read-only safety, the description is fairly complete, though a note on large-result UX would push it higher.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented. The description goes further by specifying that the 'where' clause can filter by county, owner name, address, or ZIP, providing concrete examples of usage that the schema's generic example ('COUNTY = 'MONTGOMERY'') only hints at. This adds meaningful semantics beyond the schema, earning a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource: 'Query property parcel boundaries for a US state via ArcGIS.' It clearly identifies the data type (property parcels) and differentiates from sibling tools like state_gis_boundaries or state_gis_query by focusing on parcel boundaries. The statement 'Returns parcel ID, owner name, address, land area, and use codes' further specifies the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus sibling GIS tools or alternatives. It does not mention 'use this for parcel data, use state_gis_query for other data.' The filtering instructions apply within the tool but do not aid in tool selection. This is a clear gap given the numerous sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.