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

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real value beyond them: the 5-digit positional layout, the max value of 75342, the clarification that each digit is a category value and not a count, and the fact that supplying tokenId makes the response count passing checks. It does not cover behavior when both inputs are supplied or how lookup failures are handled.

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 core action is front-loaded in the first clause, and the digit legend is compact and information-dense. The disclaimer sentence is slightly tangential but earns its place by scoping expectations; overall there is little waste.

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 must carry the return-value burden, and it does explain that a tokenId response additionally counts passing checks. The preconditions for the two input modes and error cases are not addressed, leaving a small gap for a decode tool with two alternative inputs.

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 100%, so the baseline is 3, but the description goes further by decoding what the 'score' value actually represents (per-digit verification groups) and clarifying the tokenId alternative path. That meaning is genuinely beyond the schema's terse 'explain this number' phrasing.

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 (explain a Fabrica property's Property checks from a numeric encoding) and then defines the encoding precisely, so the agent knows exactly what this tool decodes. It is clearly distinguishable from siblings like get_land_property or get_land_tax_status, which retrieve raw property data rather than interpret a verification score.

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 disclaimer that Property checks are 'a starting point for your own research, not a title search or title insurance' establishes a scope boundary, which is useful. However, it never states when to call this versus siblings (e.g. get_land_property) or what condition a user must satisfy to need a decode, so usage is only implied.

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