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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior beyond them: the answers come from a hand-refreshed rules table dated 2026-10-16, each answer carries that date, and the live on-ramp page is authoritative. That freshness/staleness caveat is exactly the kind of context an agent cannot infer from structured fields.

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?

It is front-loaded with the core question and then the answer contents, and each sentence contributes something (outcomes, data freshness, accepted inputs, exclusions). The first sentence is a dense run-on that could be split, which keeps it short of a 5.

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?

There is no output schema, so the description carries the return-value burden — and it does, listing deed, forms, notarization, witness requirements, owner questions and on-ramp steps, plus the date stamp on answers. Combined with the input format guidance and the freshness caveat, nothing an agent needs to call it correctly is missing.

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?

With 100% schema description coverage, the baseline is 3, and the description earns above it by clarifying the accepted input combinations — 'a 5-digit county FIPS, or a two-letter state with or without a county' — which the schema does not spell out as mutually alternative paths. It does not, however, explain ownerType's effect on the answer, leaving that to the enum.

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 names a specific verb and resource — checking whether a US county or state can be added to Fabrica through the on-ramp — and enumerates the exact outcome values (supported, notConfigured, unsupported). It also spells out what a positive answer contains (deed, forms, notarization, witnesses, owner questions, steps), so an agent knows precisely what this returns and can distinguish it from siblings like buy_land or ask_fabrica.

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 a clear use context (on-ramp eligibility lookups) and at least one explicit boundary against a sibling: 'No fee amounts (ask_fabrica has them) and no owner data.' However, it never states the when-not conditions in full — e.g. that estimates or parcel searches belong to estimate_land_borrowing or find_us_parcel — so the routing map is partial rather than complete.

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