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

With no annotations the description carries the full burden, and it does disclose non-obvious behavior: a paid account key (or Bearer header) is required, and an empty state triggers a search across every PLSS state rather than a failure. It omits rate limits, error semantics beyond the ok flag, and any accuracy caveats, so it stops short of a 5.

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?

Content is dense but the priority is wrong: the definition front-loads pricing ($3/month, $1/day) instead of the tool's purpose, forcing the agent to read past marketing before learning what it does. The trailing response-shape list also duplicates the output schema, spending words on information already available.

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 three-parameter geocode tool with an output schema (so return values need not be restated) and no annotations, the description covers auth, both input semantics, and fallback behavior adequately. The remaining gap is the missing disambiguation from plss_lookup, which matters given how many sibling tools exist.

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 0%, so the description must compensate, and it does: q is illustrated with four distinct notation styles (T2N R3E Sec 14, fractional-section, spelled-out township, BLM-coded), state is defined as a two-letter code with an explicit empty-default behavior, and api_key is tied to the account or the Bearer alternative.

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 states a concrete transformation — a legal description maps to a coordinate ('a legal description → where it is') — with four concrete input examples, so the agent knows exactly what the tool does. It does not, however, distinguish itself from the sibling plss_lookup, which likely covers overlapping territory.

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?

It gives functional context (whether state is supplied or left empty, which silently searches every PLSS state) and states the auth/pricing requirement, but never says when to choose this over plss_lookup or any other sibling. Usage is implied rather than routed.

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