get_client

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

readOnlyHint=true already establishes this is a safe read, so the bar is lower, yet the description adds essentially nothing beyond "complete detail" — no mention of what happens with an invalid or foreign-company id, nor of error behavior. Since there is no output schema, the description should have described what "complete detail" actually contains, and it does not.

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?

A single short sentence with no wasted words, but the brevity comes at the cost of nearly all substantive content. It is efficient rather than well-structured or front-loaded.

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 simple two-parameter read tool this is thin: no output schema exists, the required id has no documentation anywhere, and the description never explains what the returned "complete detail" comprises. An agent could call it, but with little confidence about the identifier format or response shape.

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?

The description is silent on both parameters. With only 50% schema coverage, the undocumented required "id" parameter is left for the agent to guess, and the company_id fallback semantics (FIC_COMPANY_ID or the token's only company) are only found in the schema, not reinforced or explained in the description.

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?

"Dettaglio completo di un cliente" identifies the resource (a single client) and indicates a full-record retrieval rather than a list, which implicitly separates it from list_clients. However, there is no explicit verb and no stated contrast with siblings like get_supplier or list_clients, so the agent must rely on the tool name for the operation.

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?

There is no guidance on when to call this versus list_clients or client_statement, and no prerequisites such as needing a valid client id. The agent must infer usage entirely from the name.

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