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

Annotations cover safety (readOnly, idempotent, closed-world), and the description adds substantial behavior beyond that: search order ('labels, keys and tabs before scanning'), what is returned ('exact saved evidence, unknown/missing counts and pagination'), exclusions ('masked fields and restricted records are excluded'), and pagination contract ('Honor complete/hasMore').

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?

Front-loads purpose, then the example, then operator semantics, then exclusions and pagination — a sensible order for a 10-param tool. The operator enumeration is dense but earns its place; a few sentences are run-on.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. What remains is query semantics, exclusions, and pagination, all present; only the state/locationSearch filters and empty-result behavior are unaddressed.

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 carries the load and does so for the core params: condition operator families, compareValue/compareTo pairing, combine:'and'/'or' with a 5-filter cap, and a fieldSearch example. It leaves state and locationSearch unexplained, so it does not fully compensate.

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 sites') plus the mechanism ('saved Details-tab fields, not web research'), which immediately separates it from free-text search or list_locations. An agent can tell what this tool does without opening the schema.

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?

Gives a concrete worked example ('For plastic bag bans use fieldSearch:plastic bag, condition:ban') and a disambiguation rule ('Fees/proposals are not bans'), which is real when-to-use guidance. It stops short of naming an explicit alternative sibling for simpler listing needs, so it is not a full 5.

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