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

Annotations already cover readOnly/idempotent/non-destructive, yet the description adds genuine operational detail: every read re-checks publication, private/withdrawn bases return 404, and no cached files are served after withdrawal. The untrusted-input warning is also useful safety context, though the search-character and 20-result limits pertain more to sibling search routes than to this call.

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 purpose and publication-check semantics are front-loaded and earn their place. The iframe/embed paragraph and the "3–160 search characters, at most 20 results per page" limits drift into territory belonging to public_search_base and dilute focus for this tool.

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?

With no output schema, the description carries the return-value burden and does so adequately by describing the base plus its documents, auth needs, and 404 semantics. It stops short of describing pagination shape beyond the cursor parameter, but is otherwise sufficient for a read tool.

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 coverage is 100%, so base_id and the after cursor are already fully documented in the schema (including the "do not construct cursors" guidance). The description adds nothing about either parameter, so the baseline 3 applies.

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?

Opens with a specific verb+resource: "Read published base and its documents," which is clear and scoped. The "Published bases only" qualifier helps separate it from the broader public_* family, but it never names a sibling (e.g., public_get_base_document) to disambiguate the document-level tool from this one.

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?

It states prerequisites (published only, no account required) and error behavior, and mentions the iframe embedding use case. However it never says when to choose this over public_list_bases or public_get_base_document, so routing guidance is only implied.

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