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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds the useful behavioral nuance that version selection returns an older revision and that omitting doc_id changes the response shape. It does not mention whether versions beyond 20 are dropped or how large the listing can get, leaving some behavioral gaps.

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 response modes and the workflow trigger are front-loaded in the first two sentences with no filler. The trailing Traditional Chinese sentence duplicates the same meaning without adding information, a minor redundancy that costs it the top score.

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 two-optional-parameter read tool with no output schema, the description covers both return modes, the versioning concept and the workflow position, which is sufficient to call it correctly. Only the shape of the returned document (fields, ordering of the list) is left implicit.

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 100%: doc_id ('omit to list all documents') and version ('an earlier version, the last 20 are kept') are already fully documented in the schema. The description restates the omit-to-list behavior but adds no format or constraint details beyond it, 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?

The first sentence names a specific verb and resource ('Returns one saved document by doc_id') and covers both the single-fetch and list modes, so the agent knows exactly what comes back. What it lacks for a 5 is an explicit contrast with the write-side sibling save_brand_doc; the read semantics are only implied by 'Returns'.

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 gives a clear usage context — 'Applies before generating or scheduling posts' — which tells the agent when this tool is relevant in a workflow, and it explains that omitting doc_id switches to list mode. There is no explicit exclusion or 'use X instead when...' rule, so a 4 rather than a 5.

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