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

Annotations already cover read-only, open-world, idempotent, and non-destructive hints, so the bar is for added context. The description contributes exact-match failure behavior ('on a miss you get a user_error naming search_wikipedia as the recovery'), truncation by max_chars, and — critically, since there is no output schema — the exact return format (plain text, '== headings ==' markers, table rows one per line with | separators). This goes well beyond what annotations convey.

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 verb and core distinction are front-loaded in the first sentence, and the body follows a logical structure: use cases → answer types → direct-call strategy → miss handling → alternative routing → parameter interplay → output format. It is long and slightly repetitive in places (the question-phrasing list and title-pattern examples overlap with earlier use cases), so it is not maximally lean, but every sentence does carry routing or formatting value.

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?

There is no output schema, so the description must cover return semantics by itself — and it does: plain text, heading markers, table cell separators, max_chars capping, and exact-match failure behavior. Combined with schema documentation for all three params and annotations for the safety profile, nothing an agent needs to invoke this tool correctly is missing.

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% and the schema already documents title, section, and max_chars with ranges and defaults. The description adds marginal value for parameters: restating the section/max_chars interplay ('Omit section for the whole article (capped by max_chars); pass a section number...') and giving concrete title-pattern examples, but those largely mirror or barely extend the schema. Baseline 3 is appropriate; no extra meaning is truly necessary at 100% coverage.

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 opens with a concrete verb+resource: 'Full text of a Wikipedia article by title — the ACTUAL prose AND its tables, not just the lead paragraph.' It explicitly distinguishes itself from get_article_summary (lead paragraph only) in the first sentence, and later names the miss behavior for searches. An agent can tell exactly what this tool returns and how it differs from close siblings.

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?

Gives explicit when-to-use and when-not-to-use guidance: 'CALL IT DIRECTLY when the title is predictable from the question', 'constructing the title and reading the article beats searching first', 'PREFER OVER get_article_summary whenever the lead paragraph is not enough', and names search_wikipedia as the recovery path on a miss. It even states the condition for using sections from get_article_sections — nothing is left to inference.

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