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

Annotations already declare this as a safe, read-only, idempotent, non-destructive, non-open-world operation. The description adds that it concerns public documents and lists the kinds of activity content, but it does not explain pagination behavior, return shape, or any access constraints beyond the annotations.

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?

A single front-loaded sentence with no wasted wording. Its brevity is appropriate structurally, though it leaves important operational details unstated.

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?

The tool has only three parameters and rich annotations, but the schema descriptions are absent and there is no output schema. The description does not explain how to use id, page, or surface, nor what pagination or activity results look like, leaving the definition under-specified for reliable invocation.

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%, so the description must compensate for undocumented parameters. It only vaguely implies that "id" refers to a public document and does not explain "page" or map the content types to the "surface" enum values.

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 uses a clear verb, "Read," and names the content types it can return: proposals, published revisions, discussion, and tasks for a public document. It is understandable on its own, but it does not explicitly differentiate itself from siblings such as read_document or read_moderation.

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 gives no explicit guidance on when to use this tool instead of alternatives like read_document, read_moderation, or comment. It implies a document-activity context but leaves selection between sibling read tools entirely to inference.

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