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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond an internal Operation ID and a pointer to describe_operation — no rate limits, pagination, auth scoping, or result shape.

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 very short text is not concise so much as degenerate: 'GET /api/document-anchors' appears twice in immediate succession, and the Operation ID consumes space without informing an agent. Nothing is front-loaded beyond the endpoint 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 tool with nested-object parameters, zero schema description coverage, and no output schema, the description should explain what the endpoint returns and how to shape the query object. It does neither, leaving the agent dependent on a second describe_operation call.

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% and both parameters ('query' as a free-form nested object, 'params' as an empty closed object) are opaque. The description does not explain what filters belong in 'query' or what 'params' is for, though it does at least name describe_operation as the place to find the native request schema — a partial mitigation.

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 a verbatim restatement of the title/path ('GET /api/document-anchors') repeated twice. It never says what an anchor is, what resource it belongs to in domain terms, or how it differs from the hundreds of sibling get_* tools. Only the HTTP verb and path fragment carry any meaning.

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 when-to-use, when-not-to-use, or sibling routing guidance. The only actionable pointer is 'describe_operation provides native request schemas', which tells the agent how to fetch parameter info but not whether this tool is the right choice over, e.g., get_cam_clauses_by_clauseId_anchors or find_contracts.

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