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

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real value by disclosing that the log is durable, paginated, permission-scoped by key, and that secrets, raw input bodies and signed URLs are never recorded. That last point is material context an agent cannot get from the annotations or schema.

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 tight sentences open with the core verb and resource, then layer the permission and data-exclusion caveats. Nothing is redundant with the title, and no sentence could be removed without losing 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?

An output schema exists, so return values need no explanation, and the annotations cover the safety profile. The description is nearly complete for a three-parameter read tool; the only shortfall is per-parameter cursor/limit semantics.

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% for three parameters, so the description must compensate. It conveys that pagination exists (covering after/limit at a high level) and that project_id relates to cross-project restriction, but it adds no per-parameter meaning such as the limit ceiling of 100 or how the after cursor is obtained.

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 pairs a specific verb ('Read') with a specific resource ('this key's durable MCP operation metadata') and adds the pagination trait. An agent can distinguish it from get_activity or get_job_events by the 'this key's' scope and 'operation metadata' framing, though no sibling is named explicitly.

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 clause 'Restricted keys cannot read other projects' gives one usage constraint that implies when project_id is meaningful, but there is no explicit when-to-use guidance versus the many other get_* read tools, and no stated exclusions beyond that permission note.

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