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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description adds nothing beyond the path and operation ID; the note about describe_operation supplying schemas is a marginal hint but discloses no behavior about what is returned or how results are scoped.

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 first sentence is repeated verbatim, wasting half the text, and the remaining sentence is metadata (operation ID) rather than substance. Not front-loaded with any useful information beyond the path.

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 nested-parameter, zero-coverage read tool with no output schema, the description omits parameter meaning, return content, and pagination behavior. The describe_operation pointer is the only supplement, which is insufficient on its own to call 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 0%, with two parameters including a required nested 'params.id' and an unconstrained 'query' object, yet the description explains neither. It only redirects to describe_operation for request schemas, leaving the agent without meaning for the id or the free-form query parameter.

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 is essentially the raw endpoint path 'GET /api/counterparties/:id/contacts' duplicated verbatim, which restates the title rather than explaining the operation. An agent can infer that it retrieves contacts for a counterparty, but there is no prose stating the verb+resource in plain terms or distinguishing it from siblings like get_counterparty_contacts.

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?

No guidance on when to use this tool versus alternatives such as get_counterparty_contacts, get_contacts_by_id_associations, or get_counterparties_by_id_notices. The only actionable hint is that describe_operation provides native request schemas, which is a pointer to another tool, not usage guidance for this one.

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