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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds rich behavioral detail beyond that: it knows 81 spellings of 30 legal forms across 21 countries, ignores word order, down-weights generic words, and flags obfuscation (homoglyphs, invisible characters, digit substitution) in an 'obfuscation' field. It also mentions the reasoning is broken out, giving insight into the output structure. This fully compensates for the missing output schema.

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 a single, information-dense paragraph. It is front-loaded with the core purpose, then enumerates specific behaviors, and ends with an important interpretive note. Every sentence adds unique value, but it is longer than strictly necessary. It could be tightened, but the structure is logical and efficient.

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?

Given there is no output schema, the description compensates well by indicating output components: a score from 0 to 1, broken-out reasoning, an obfuscation field, and an instruction to check distinctiveness. It also provides an example in the schema. An agent has enough information to call the tool and interpret results. The tool is simple (3 params, 2 required, read-only) so this level of detail is complete.

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. The main description adds context that helps understand how parameters are interpreted: it explains that legal forms like 'Pty. Ltd.' and 'Proprietary Limited' are treated equivalently, and that word order is ignored. This goes beyond the terse property descriptions ('First name.', 'Second name.', 'Defaults to company.') and helps an agent input names correctly. It doesn't directly describe the 'type' parameter, but the example shows company usage. Slight extra value over the schema.

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 precise verb and resource: 'Score whether two names are the same entity, 0 to 1, with the reasoning broken out.' This clearly distinguishes it from sibling tools like match_entity_name (boolean match) and normalise_entity_name (transformation), even without naming them. The scope is unambiguous.

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 gives a specific interpretive guideline: 'Check distinctiveness: names of only generic words identify weakly however well they match.' This helps an agent decide when to rely on the score. It doesn't explicitly state when to prefer this tool over siblings, but the purpose is clear enough that an agent can infer it. Slightly better than average but not explicit about routing.

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