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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, which already convey the safety profile. The description adds useful behavioral context: it returns specific fields (name, summary, record_count, owner/org, feature service URL) and indicates the tool is for open geospatial datasets. However, it doesn't say anything about pagination or rate limits, which would be extra value, but annotations suffice for core transparency.

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

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

The description is two sentences: the first concisely states purpose and scope, the second lists return fields and the chaining action. Every word adds value, no redundancy, and it's appropriately sized relative to the tool's simplicity.

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

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

Given no output schema, the description compensates by naming the exact fields returned and the chaining recommendation. The tool is a search/discovery read operation, so it doesn't need to explain side effects. The only slight gap is lack of mention of pagination, but with 1-50 limit and no required params, the context is sufficient for a candidate selection task.

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%, with each parameter (limit, query, org_id) having a meaningful description. The tool description adds context about the default org (City of Austin GIS) and that query is keyword-based, but it doesn't repeat parameter details beyond that. Baseline 3 for high coverage, with a slight bump for the description's note that 'query' can be multiword and the default scope, which supplements the schema.

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

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

The description clearly states a specific verb ('Search') and resource ('City of Austin GIS open geospatial datasets'), and enumerates content areas. It distinguishes itself from sibling tools like query_layer and layer_info by explaining its role as a discovery step and explicitly mentioning that the returned URL is to be passed to those tools.

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 explicit usage guidance: use this tool to find datasets by keyword, and then pass the returned Feature Service URL to query_layer / layer_info. It positions the tool as a discovery precursor, making the appropriate context clear and implicitly distinguishing it from tools that operate on a specific layer.

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