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

Annotations already mark the tool as read-only and idempotent, and the description goes further by explaining that the score is a transparent sum of public-record evidence, that evidence[] carries per-fact weights, and that coverage[] documents missing inputs. It also adds the caveat that the result is heuristic and not an appraisal or offer, which accurately sets expectations beyond the structured annotations.

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 description is compact but information-dense, front-loading the action and scope, then listing contributing factors, naming the output fields, and ending with limitations. Every sentence earns its place and there is no filler or duplication of the schema.

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 single-parameter read-only scoring tool, the description covers what the score means, which inputs feed it, what output fields to expect, and the key caveat. The existing output schema handles structured return details, so the remaining gaps such as explicit sibling routing are minor and already reflected in other dimensions.

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 100% and the single parameter already has a clear format description ('Brazilian registration (PR-TBL).'). The description only refers generically to 'one registration' and adds no registration-specific constraints or format details, so it does not need to compensate for schema gaps.

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 opens with a specific verb and resource ('Score 0-100 of how well one registration fits...') and enumerates the input factors and output semantics. It is unmistakably about per-registration fit, but it does not explicitly contrast itself with sibling tools such as jt_fractional_market or jt_sale_propensity, so it stops short of full sibling differentiation.

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 description implies the use case by saying it scores fit for fractional/shared-ownership and adds an exclusion ('It is a heuristic fit, not an appraisal or an offer'). It does not explicitly say when an agent should prefer this tool over sibling tools like jt_fractional_market, nor does it name alternatives. This is implied usage rather than explicit routing guidance.

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