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 covered. The description adds nothing beyond that — no mention of result shape, pagination, or scope of returned changes — and the duplicated path line carries no behavioral value.

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 and second sentences are identical restatements of the path, so a full sentence is wasted. The operation ID and the describe_operation pointer are the only non-redundant content, and they are not front-loaded as the primary information.

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 endpoint with a nested 'query' object and no output schema, the description should clarify what field changes are returned and how the query bag is used. Instead it repeats the path and defers all substantive info to another tool, leaving an agent unable to call it correctly without an extra lookup.

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 the description explains neither the required 'id' path param nor the open-ended 'query' object. It only redirects to describe_operation for schemas rather than adding meaning, which slightly mitigates but does not compensate for the documentation gap.

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 twice restates the HTTP path 'GET /api/leases/:id/field-changes', which conveys a specific verb and resource (field-change history for a lease). However, it never elaborates what a 'field change' record is, and among hundreds of get_leases_by_id_* siblings it offers no distinguishing phrasing beyond the path itself.

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 statement of when to use this vs. the many other lease sub-resource tools, nor any exclusions or prerequisites. The only navigational hint is that describe_operation holds the request schemas, which is a reference, not usage guidance.

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