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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the scope of the indexed corpus, the shape of results (ranked, with highlighted snippets, identifiers and links), and that it is free of charge — valuable since there is no output schema.

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 tight sentences: what it searches first, what it returns second. Every clause carries information (corpus scope, ranking, snippet/highlight output, cost) with no filler.

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 six parameters at low schema coverage and no output schema, the description should clarify the type/kind filters and any empty-result or paging behavior; it covers only corpus scope and return shape. Adequate to call the tool correctly on the required `query`, but incomplete for the optional filters.

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 33%, so the description must compensate and it does not — kind, type, limit, topic and year_from are never mentioned. Critically, it leaves unexplained the overlap between the `type` enum (all/papers/dossiers) and the `kind` enum (preprint/article/review/trial), which is the most likely source of mis-invocation.

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?

Names a specific verb and resource ('Full-text search over indexed frontier research papers, clinical trials and research dossiers') and even enumerates subject domains, so an agent knows exactly what it retrieves. It does not explicitly contrast itself with get_paper/get_dossier, though the mention of 'identifiers and links' implies the retrieval-then-fetch pattern.

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?

Usage is only implied: the mention of returned 'identifiers and links' suggests this is the discovery step before the get_* siblings, but no alternative is named and no when-not condition is given. The 'Free' note is a mild cost hint, not a usage rule.

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