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

With no annotations, the description carries the full behavioral burden and mostly does: it discloses that the same durable row is attached rather than copied, that edits propagate back to a shared row, that this creates cross-session soft-collaboration, and that the first listed document is the one focused. It omits auth/permission requirements and error behavior, which keeps it out of 5 territory.

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?

Purpose is front-loaded in the first sentence, followed by attachment semantics and the return contract, so the structure is easy to scan. It is slightly padded ('cross-session soft-collaboration') but every sentence still carries distinct 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 tool with no output schema and no annotations, the description does the heavy lifting: it explains the return value ('refreshed document roster so the client can render tabs immediately') and the token-light behavior of include_html. What remains missing is any mention of authorization requirements or prerequisites such as session initialization.

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 only 50%, and the description's 'The first listed document is focused' adds genuinely non-obvious ordering semantics for document_ids that the schema does not convey. However, session_id and the anyOf string/null 'authorization' parameter are undocumented in both places, so the description only partially compensates for the coverage 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?

States a specific verb and resource ('Load ... SAVED documents into a session as editable tabs') and pins down that only durable/saved documents are eligible, contrasting implicitly with the many upload_* and process_uploaded_document siblings. It does not explicitly name a sibling it differs from (e.g. get_document_detail or list_session_documents), so it stops short of a 5.

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 'Load one or more SAVED documents' framing implies the use case, and include_html's schema text touches on agent workflows ('enumerating or switching tabs'), but the description never states when to prefer this over list_documents, get_document_detail, or focus_session_document, nor any precondition like whether an init_session must come first. Usage must be inferred from context.

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