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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety needs no restating. The description adds behavior the annotations cannot: retrieval is semantic rather than keyword-based, queries may be in any language, and the response is an answer rather than a raw record fetch. It omits failure and low-confidence behavior, which keeps it off a 5.

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?

Two sentences with no filler. The subject matter is front-loaded in a scannable list, and the behavioral note about semantic search follows the scope. Nothing repeats the schema or the title.

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?

This is a two-parameter read tool, and the description covers scope, retrieval mode, and query phrasing adequately for an agent to call it confidently. With no output schema, a brief note on what comes back (a synthesized answer with sources, or a list of passages) would close the only real gap.

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 the baseline is 3, and the description earns above that by clarifying that a query may be written in any language while the separate language parameter selects the language of the answer rather than constraining the query. That distinction is easy to get wrong and is not spelled out in the schema. It does not mention the 200-character cap or give example phrasings, so it is not a 5.

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 gives a specific verb ("find answers") tied to a specific corpus (Jensing knowledge) and enumerates the topic areas covered: who it helps, problems solved, getting started, cost and funding, approvals, track record, origin. That is meaningfully more specific than the title alone. It stops short of naming a sibling, so an agent still has to infer that get_article fetches a known document while this tool discovers unknown ones.

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?

"Searches by meaning, so ask in plain words, in any language" tells the agent how to phrase a query, which is genuine usage guidance. It never says when to reach for this instead of get_article or get_company, nor does it state what to do when no confident match exists. Usage is implied by the topic list rather than stated as a routing rule.

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