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

Annotations already declare readOnlyHint=true, so safety is covered. The phrase 'with all its fields' adds a little context about return breadth, but nothing is said about behavior on a missing or invalid id (error vs empty result), which is the main unknown for a single-record fetch.

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 short sentences, front-loaded with the verb and resource, followed by the one invocation detail that matters. No filler.

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 one-parameter read tool with annotations covering safety and no output schema, this is nearly complete: it says what comes back ('all its fields') and how to form the id. Only the not-found behavior is unaddressed.

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% and the schema already documents both the numeric id and the 'code:ABC' identifier form with a full pattern. The description's only addition is naming abraflexi_list_contacts as the id source, which is marginal against a schema that already carries the syntax.

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 specific verb and resource ('Get one address-book entry') and scopes it to a single record with all fields, which separates it from the plural abraflexi_list_contacts sibling. It does not, however, distinguish itself from abraflexi_get_record or abraflexi_get_company, which are also single-record retrievals.

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 implies usage by pointing to abraflexi_list_contacts as the source of the id, which is a helpful sequencing hint. It never states when to prefer this over abraflexi_get_record or abraflexi_get_company, so the agent must infer the choice.

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