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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, and the description adds substantive context beyond them: the returned fields (ids, names, categories, licences) and the default result size of 25. The trailing 'Read-only' restates the annotation but the rest is genuinely additive; pagination or total-count behavior is not covered.

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

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

Two compact sentences: the search scope and corpus size come first, then the return fields and the chaining hint. Nothing is padded, though 'Read-only' is mild redundancy against the annotations.

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?

With no output schema, the description usefully enumerates what comes back, and it names the default limit. It lacks detail on how to raise the limit, whether counts are returned, and what non-vector layers are good for after being found.

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

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

Schema coverage is 0%, so the description must carry the load, and it does for `query` by characterizing it as free-text words with concrete examples ('seagrass', 'coral bleaching'). The '25 by default' phrasing implies the `limit` parameter's default without naming or bounding it, which is good but not complete.

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?

States a specific verb and resource ('Find Biohotspot map layers by words') plus the corpus searched (1,600+ world layers) and gives example queries. It also distinguishes itself from the sibling get_features by casting itself as the discovery step that feeds it.

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?

Clear usage context: keyword search over the layer catalogue, with an explicit follow-up path ('vector layers can then be read with get_features'). It does not name when to prefer it over siblings like look_here or look_in_area, so it stops short of full routing guidance.

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