clients_anaf_lookup

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

No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that this tool does NOT create a client (a read-only lookup), which is essential safety information. It also states it returns 'pre-filled form data' describing the output shape. While it doesn't disclose rate limits or network dependency on ANAF, the non-mutating nature is the most important behavioral fact and is clearly stated.

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?

Two sentences, zero wasted words. The first sentence states purpose and the non-mutation behavior; the second describes the return value and its downstream use. Efficient and front-loaded with the most important information first.

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 read-only lookup tool with 100% schema coverage and no output schema, the description is quite complete. It explains what it returns, what it doesn't do (create), and how results connect to a sibling tool (clients_create). The only minor gap is that it doesn't describe failure modes (e.g., what happens if CUI not found in ANAF), but for this simplicity level the description is solid.

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 baseline is 3. The description adds meaning by explaining that the cui parameter identifies a company in the ANAF registry and that the returned data feeds into clients_create. The description of the returned fields (name, address, VAT status, registration number) provides context on what the cui lookup yields, adding value beyond the raw 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 clearly states 'Look up company details by CUI in the ANAF public registry without creating a client' with a specific verb (look up), resource (ANAF registry), and scope. It distinguishes itself from clients_create by explicitly noting it does NOT create a client and provides pre-filled form data, and from clients_vies_lookup and anaf_validate_cif by specifying the ANAF public registry context.

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 clearly states this is for lookup before creating a client ('without creating a client') and explicitly says the returned data 'can be used to populate a clients_create call,' which implies the use case of pre-populating client creation. However, it doesn't explicitly exclude alternatives like clients_vies_lookup or anaf_validate_cif, though the CUI/ANAF distinction is reasonably implied.

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