partner_verify

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

Despite annotations covering the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds substantial behavioral context: it lists exactly which snapshot fields are stored, enumerates change types returned in `result.changes`, explains error semantics (not_applicable, registry_unavailable with snapshot preservation, not_found), discloses the side-effect notification on degrading changes, and states the required permission and throttling. This goes well beyond what annotations provide.

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 dense paragraph, front-loaded with purpose and then details. Every sentence earns its place, but the parenthetical lists and error explanations could be structured as bullets for faster scanning. It is information-rich without being redundant.

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?

With no output schema, the description fully explains the return shape: updated partner fields, `result` with checked/source/changes/error, and notification side effect. It also covers permissions and throttling. An agent has everything needed to invoke and interpret the tool correctly.

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 schema already fully documents the three parameters (type enum, uuid, companyId override). The description does not add syntax or format details beyond what the schema provides, but it does implicitly clarify that `type` selects the registry path. Baseline 3 is appropriate when schema does the heavy lifting.

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 clear verb ('Check') and specific resource ('one client or supplier'), names both registries (ANAF for CUI, VIES for EU VAT), and notes the snapshot storage side effect. This distinguishes it from siblings like clients_anaf_lookup and clients_vies_lookup, which are single-registry lookups, and from partners_verify_all.

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 makes clear this is for a single partner and explains when each registry applies based on partner type (CUI vs VAT number). It also documents error conditions for individuals/non-EU partners. However, it does not explicitly name or compare against the sibling partners_verify_all for bulk operations, leaving that routing inference to the agent.

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