match_entity

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it explains the scoring system (0.0-1.0 with confidence thresholds), defines PEP, and notes that PEP status appears in 'topics' as 'role.pep.' It could improve by mentioning rate limits or authentication needs, but it covers the core matching algorithm and output interpretation.

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 appropriately sized and front-loaded, with the purpose stated first. Each sentence adds useful information (e.g., scoring, PEP definition), but it could be slightly more concise by integrating the PEP explanation into the initial sentence or reducing redundancy.

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 the tool's complexity (screening with scoring), no annotations, and no output schema, the description is mostly complete. It explains the purpose, usage, scoring, and PEP details. However, it lacks information on error handling or example outputs, which would enhance completeness for a tool with no output schema.

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%, so the baseline is 3. The description adds some value by mentioning that the matching algorithm uses 'name comparison, birth dates, nationalities, and identifiers for scoring,' which provides context for the 'properties' parameter, but it does not significantly elaborate beyond what the schema already describes for parameters.

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 clearly states the tool's purpose: 'Screen a person or company against sanctions and PEP lists using structured properties.' It specifies the verb ('Screen'), resource ('person or company'), and target ('sanctions and PEP lists'), and distinguishes it from siblings by labeling it as 'the primary screening tool.'

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 provides clear context for when to use this tool: it's for screening against sanctions and PEP lists. However, it does not explicitly state when not to use it or name alternatives (e.g., 'investigate_entity' might be for deeper analysis), though it implies this is the main tool for initial screening.

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