AgingResearch.News

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

Annotations mark it non-read-only, open-world and non-idempotent, and the description adds substantial context the annotations cannot: it consumes one of the user's daily Ask questions (a quota/rate constraint), returns at most ~350 words with numbered linked sources, flags thin coverage explicitly, and describes the async fallback pattern. This goes well beyond the structured hints.

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?

Front-loaded with the trigger condition ('Use this when...') and dense with useful facts, but the single long paragraph packs quota, output format, follow-up and timeout behavior together, making it slightly heavy to scan. Little is wasted, but a small amount of structural separation would help.

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 no output schema, the description carries the full return-value burden and does so: length cap (~350 words), numbered sources with links, and the conversation address are all described, plus quota consumption and the timeout/get_ask_answer handoff. An agent has everything needed to call, interpret and recover from this tool.

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%, so both parameters (question, conversation_id) are already fully documented in the schema, including language handling and the conversation_id pattern. The description's 'Pass conversation_id for a follow-up' largely restates the schema field, so baseline 3 is appropriate.

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: it answers research questions from AgingResearch.News's own record of papers, trials, approvals, mouse lifespan results, researchers and companies. It scopes the subject matter precisely (biology of aging, longevity interventions, age-related disease, people/companies) and is clearly distinguishable from retrieval siblings like search_arn or find_entities.

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 conditions with concrete examples, an explicit exclusion ('Not for personal medical advice, doses or symptoms'), and routes follow-ups via conversation_id. It also names the alternative path when the call times out ('read it with get_ask_answer and its question_id'), which is exactly the when-vs-alternative guidance an agent needs.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world safety. The description adds genuinely new behavior: output is grouped counts per stage, and data completeness depends on the account plan (full records vs. outline). That plan-gated read behavior is not derivable from annotations or schema and is valuable for interpreting results.

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?

Front-loads the trigger ('Use this when...'), then behavior, then a worked example, then the plan caveat. Efficient overall, though the final sentence about account plans is dense and could be tightened.

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 an 11-param, zero-required tool with no output schema, the description covers what is returned (grouped counts per stage) and the important plan-dependent completeness caveat. It is complete enough to call correctly, with only minor gaps in describing pagination/limit behavior, which the schema already documents.

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. The description earns above baseline by explaining cross-parameter interaction the schema cannot ('by=target with indication=obesity counts the targets of obesity programmes') and by naming the grouping values the `by` enum offers.

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 (counts) and resource (drug and therapy programmes/pipeline), and enumerates the grouping dimensions it supports. It also positions itself against sibling list_assets by noting it 'takes list_assets' filters', making the count-vs-list distinction explicit without opening either schema.

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?

'Use this when the user asks how many...' gives a clear trigger condition, and the list_assets filter reference points to the sibling it complements. It stops short of an explicit when-not (e.g., 'use list_assets instead when you need the full records'), so it's strong but not fully routed.

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

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

Annotations already cover read-only, idempotent and non-destructive behavior, but the description adds real traits beyond them: case-insensitive substring and synonym matching, 'most-studied first' ranking, and that each result carries a paper count. These are useful behavioral disclosures the structured fields don't provide.

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?

Three sentences, all earning their place, front-loaded with the 'Use this to...' trigger. No redundancy or 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?

No output schema exists, yet the description covers what the tool returns (type, key, paper counts), the ordering, the matching semantics, and the downstream chaining. With annotations covering the safety profile, an agent has everything needed to call and use it correctly.

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; the description slightly exceeds it by noting that q matches 'a known synonym' (the schema only mentions name or key) and by explaining that a result's type and key feed into get_entity. It does not add further syntax or format detail for limit/cursor.

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 (find) and resource (entity types: drug, gene, process, disease, etc.) and explicitly scopes it as resolving a name to a type and key. It names the sibling tools that follow it (get_entity, list_claims, list_grants), so the agent can distinguish it from them without opening a schema.

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?

Explicitly says when to use it: resolving what a question names before get_entity, list_claims or list_grants. Names the alternatives/downstream tools and the workflow position, leaving little to inference, though it lacks a negative exclusion statement.

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

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

Annotations already declare this is a write (readOnlyHint=false), idempotent, and non-destructive. The description meaningfully adds the downstream effect that the schema and annotations cannot convey: the follow is persisted to the user's account and drives the For you feed and daily follow email.

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?

Three tight sentences with the usage trigger front-loaded, then input provenance, then the user-visible consequence. No filler and nothing repeated from the schema.

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-parameter write tool with no output schema, the description covers trigger, inputs and resulting side effects adequately. It leaves auth/account prerequisites implicit ('saved to the user's account'), which is a minor remaining 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 would be 3, but the description adds provenance semantics by telling the agent where valid type/key pairs come from (find_entities or get_entity), which reduces the risk of guessing an entity key.

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 (follow) plus the resource (a drug, gene, process, disease or other entity) and the effect, which cleanly separates it from the sibling 'unfollow' and 'list_follows'. An agent can identify the operation without opening the schema.

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 an explicit trigger ('when the user asks to follow...') and names the source of valid inputs (find_entities or get_entity). It does not explicitly name 'unfollow' as the inverse or state when-not to use it, so it stops short of full routing guidance.

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

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds real behavioral context beyond them: it blocks up to 20 seconds for a nearly-finished short answer, Ultradeep reviews take minutes, and it can return either the finished answer with numbered sources or an in-progress status. Missing error behavior for an invalid or unknown question_id, which keeps it from 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?

The usage trigger is front-loaded before the behavioral detail, and the content is appropriately short. The stacked colons make the middle clause slightly run-on, but nothing is redundant.

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 no output schema, the description carries the burden of explaining returns and does so (numbered sources, or in-progress status), plus timing expectations. It is complete for its purpose, lacking only failure-mode detail.

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% and the single parameter is fully documented in the schema, so the baseline is 3. The description only echoes the schema by tying question_id to the tools that produced it, adding little syntax or format detail.

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 ('it reads that question's answer by the question_id they gave') and explicitly ties itself to the producing siblings ask_arn and start_ultradeep. An agent can distinguish this retrieval tool from the ones that create the answer without opening the schema.

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 a clear when-to-use condition – when ask_arn or start_ultradeep said an answer is still being written, or the user wants it again – which routes the agent correctly. It does not state a when-not (e.g. for listing all questions, implying list_questions), so it stops short of the full 5.

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

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

Annotations only cover the safety profile (readOnly, idempotent, closed-world), yet the description goes well beyond them, enumerating returned sections (developers/partners/licensors, targets, mechanism, modality, indications with stage and backing trial, lifespan evidence, news) and disclosing a plan-based access tier where non-entitled accounts 'read an outline'. With no output schema, this is exactly the behavioral context the agent needs.

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, front-loaded with the usage trigger before the payload description. The long enumeration of returned fields is dense but each item earns its place given the absence of an output schema; the plan-tier sentence is slightly tangential but genuinely useful.

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 single-parameter read tool with no output schema, the description covers when to call it, what the key accepts, what is returned, and even how entitlements affect response depth. Nothing material is missing for correct invocation.

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% and the schema already says 'the asset's key or a code name', so the baseline is 3. The description adds real value by showing that multiple alias forms are accepted (ubx1325, UBX-1325, BMS-986278), clarifying that the agent need not normalize code names first.

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 ('get one drug or therapy programme') and scopes it to retrieval by name or code name. An agent can distinguish it from list_assets (enumeration) and get_entity (generic entity lookup) without opening any schema.

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 opening clause 'Use this when the user asks about one drug or therapy programme by its name or any code name' gives an explicit trigger condition plus concrete alias examples. It stops short of naming alternatives (e.g. 'use list_assets to browse'), so it is clear context without explicit exclusions.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: result ordering ('most relevant first'), the two-mode behavior with/without `edition`, and the important caveat that an abstract is not a peer-reviewed paper. It stops short of describing pagination behavior, which the schema covers.

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?

Three sentences, each earning its place: trigger first, then return shape, then the caveat and the handoff to get_paper. No repetition of the name or title, 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 no output schema, the description carries the burden of describing returns, and it does so concretely (organiser, site, editions, per-abstract number/format/publication). Combined with the fully-documented input schema and covering annotations, an agent has everything needed to call this correctly.

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 schema already documents each parameter. The description adds value by explaining the interaction between `edition` and `min_visibility` (listing that edition's abstracts worth reading, ranked) and by framing the results as curated, which goes beyond the raw field docs.

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 states a specific verb+resource (get a conference) and distinguishes itself from the sibling list_conferences by naming it as the source of the id. It also enumerates what the tool returns (organiser, site, editions, abstracts), so an agent can tell exactly what this tool produces versus its 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?

It opens with an explicit trigger ('Use this when the user asks about one meeting from list_conferences, or what was presented there') and routes the agent onward to get_paper for full-text reading. Both the entry condition and the follow-up alternative are spelled out rather than implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, yet the description still adds real behavior: return ordering ('newest first'), the per-paper role, the structure of the `evidence` block, and a genuine data-coverage caveat ('counts are of the papers AgingResearch.News has read, not of all the literature'). It does not mention pagination mechanics, but the cursor param covers that.

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?

Front-loaded with the use cases and the answer content, so the important routing information comes first. However, the semicolon-chained 'evidence' enumeration is dense and hard to parse, and the intervention/gene/process qualifier could be tightened.

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 no output schema, the description carries the return-value burden and does so: entity plus its papers newest-first, per-paper role, and the full shape of the `evidence` object. Combined with the usage questions and the caveat on counts, an agent has everything needed to select and call it.

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; the description earns above it by explaining the provenance of type/key ('Takes a type and key from find_entities') and giving concrete example values ('intervention rapamycin, disease sarcopenia'). It says nothing extra about limit/cursor/min_relevance, which the schema already documents.

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 concrete verb and resource ('Get a drug, gene or topic and its papers') and specifies the exact question shapes it answers (human evidence, replication, species, trials, funders). It also differentiates itself from the sibling find_entities, which supplies the type/key inputs rather than the answer.

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?

Opens with explicit when-to-use framing ('Use this for questions about one drug, supplement, gene, process or disease, such as: ...') and closes with an explicit exclusion ('Not for personal medical advice or doses'). It also names the upstream sibling (find_entities) that produces its required arguments.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context: the id is expected from another tool, the record includes aging relevance, non-English title handling, authors with ORCID and institutions, and a source link. It omits error behavior for a bad id but adds value beyond the annotations.

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 description is front-loaded with the when-to-use condition and ends on a pithy caveat ('It does not replace the paper'). The middle is a long run-on enumeration of return contents, but since no output schema exists, that detail is largely load-bearing rather than 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 no output schema, the description must describe the return payload, and it does so thoroughly: findings, species/subject counts, caveats, authorship, language, story sections, studied drugs/genes/processes, and source link. For a one-parameter read tool this is complete enough for an agent to call it correctly.

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% and the single id parameter already carries its type, example and description. The description repeats the MED-42823970 example and adds only the provenance note that the id comes from another tool's results. Baseline 3 is appropriate since the schema does the heavy lifting.

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 states a specific verb and resource ('Get a paper' / 'one paper in depth') and clarifies the scope as a single-record drill-down, which implicitly separates it from list_papers and search_papers. It also notes the id originates from another tool's results, reinforcing that this is a follow-up detail call rather than a discovery call.

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 trigger condition ('Use this when the user wants one paper in depth') and explains where the input id comes from. There is no explicit when-not guidance or naming of alternative siblings (list_papers/search_papers) for broader retrieval, so it stops short of full routing instructions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine behavioral context beyond that: the full set of returned data (registry summary, outcomes, dates, every recorded change, citing papers) and the special attribution/processing-date field for WHO ICTRP records, which matters since no output schema exists.

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?

Front-loaded with the usage trigger, then a compact inventory of returns; every sentence carries information. The final WHO ICTRP attribution sentence is somewhat niche but still actionable for display purposes, so it earns its place.

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 no output schema, the description must cover return contents, and it does so explicitly. Input identifier scope, return shape, and the WHO attribution caveat are all present, and annotations handle the safety profile.

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% and the nct_id parameter is fully documented with pattern and example, so the baseline is 3. The description adds real value by enumerating the accepted registry namespaces (NCT, ISRCTN, ChiCTR, CTRI, CTIS and others), clarifying the identifier space beyond the schema's pattern.

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 names a specific verb+resource (fetch one clinical trial by registry number) and enumerates what the caller gets: design, outcomes, dates, change history, and citing papers. It is clearly distinguishable from the plural sibling list_trials.

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?

"Use this when the user asks about one clinical trial by its registry number" gives an explicit trigger condition and implicitly scopes it to single-record lookups versus list_trials. It never names the alternative tool or states when not to use it, so it falls short of a 5.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's extra value is real: it discloses the sort order (furthest stage first) and the plan-dependent behavior where some accounts read only an outline rather than full records. It does not discuss rate limits or error behavior, so not quite 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?

It is front-loaded with the usage trigger and then layers output contents, filter dimensions, and sibling routing in a logical order. It is dense and long, but nearly every clause carries distinct information; only slight compression is possible.

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 11 optional parameters, no output schema, and no annotations gaps, the description compensates well: it enumerates the fields returned per asset (developers, partners, code names, modality, targets, mechanism, indications with per-indication stage, hallmarks, lifespan evidence) and the ordering, plus it points to get_asset for full detail.

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%, so the baseline is 3. The description groups the filter dimensions (target, mechanism words, modality, hallmark, indication, stage, country, organisation, name) into a readable narrative, but it adds little syntax or semantics beyond what the schema already documents for each parameter.

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 names a specific verb and resource (lists drug and therapy programmes/assets) and states exactly what each record contains. It explicitly distinguishes itself from get_asset ('read one in full') and count_pipeline ('count them'), so an agent can route without opening a schema.

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 opens with the user intent that should trigger it ('which drugs or therapies are in development against a target... who develops them and how far each has got') and names both alternatives with their distinct jobs. When-to-use and sibling routing are fully explicit.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed world), so the description's job is to add operational detail. It does: result ordering ('newest first') and the exact field set returned. It omits pagination/rate-limit behavior, but limit/cursor are schema-documented.

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?

Front-loaded with the triggering question, then result shape, then filtering, then the sibling hand-off and the exclusion. Dense but every clause carries a distinct instruction; the run-on opening sentence is the only mild structural weakness.

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 no output schema, the description carries the return-value burden and does so concretely, enumerating the fields of a claim and giving a worked example (rapamycin extends_lifespan in Mus musculus). For a 7-parameter, annotation-covered read tool, this is complete enough to call correctly.

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%, so the schema already defines every filter with examples and match semantics (case-insensitive substring vs exact relation). The description's 'Narrow by subject, object, relation, organism or paper' largely restates that, adding only the news-first ordering context. 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?

States a specific verb and resource: lists findings extracted from papers, rendered as subject/relation/object with organism, conditions, effect size and paper. It distinguishes itself from the sibling get_paper by framing this tool as the discovery surface and get_paper as the verification surface.

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?

Opens with concrete user-question patterns ('does an intervention extend lifespan, and in which organisms', 'what lowers a biomarker'), names the alternative (get_paper) with its selecting condition ('check a finding that matters'), and adds an explicit when-not ('Not for personal medical advice'). 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.

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: the ordering contract (upcoming soonest-first, then recent past) and the per-edition payload (dates, place, abstract count). It omits pagination/result-limit behavior.

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?

Three sentences, front-loaded with the usage trigger before the payload description. The middle sentence is a dense run-on but every clause carries ordering or field information; minimal waste.

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 no parameters, no output schema and full annotation coverage, the description fills the remaining gap by describing ordering and the fields each entry returns, plus the sibling handoff. Nothing an agent needs to select or call it 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?

The tool takes zero parameters, so the baseline of 4 applies; there are no argument semantics for the description to compensate for.

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+resource (list conferences) with scope ('meetings on aging research and age-related disease') and enumerates what each entry carries (dates, place, abstract count). It also distinguishes itself from the sibling get_conference, which handles single-edition reads and abstracts.

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?

Explicitly frames the trigger ('when the user asks which meetings... are coming up, or which have just been held') and routes detail retrieval to get_conference. It stops short of stating when NOT to use it or how it behaves relative to the other list_* siblings, but the primary routing decision is covered.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that this is the sidebar feed returning story cards, a small amount of scope/format context beyond the structured fields.

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?

It is a single terse fragment with no waste, but it reads more like a label than a front-loaded explanation, and the compressed phrasing ('as story cards') is cryptic rather than efficient.

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 one-parameter, read-only tool with full annotation coverage and no output schema, the description is minimally adequate. It omits any relation to list_stories and any hint of ordering, volume, or pagination, which leaves the agent to infer how the feed is delivered.

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 0%, so the schema does not document the single 'tab' parameter beyond its enum values. The description compensates by naming the two modes ('For you or Top'), which maps directly onto the for-you/top enum, adding meaning the schema lacks.

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 identifies the resource (the sidebar's feed) and its two variants (For you / Top) presented as story cards, but it uses a noun phrase with no verb and never distinguishes itself from siblings like list_stories or list_news. An agent can guess it returns the feed, but the boundary against similar list tools is not drawn.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The mention of 'For you or Top' hints at the tab dimension but gives no guidance on choosing this tool over list_stories, which appears to serve a related purpose.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds behavior beyond that: results are ordered newest first, each item carries its page, and the id format feeds the unfollow tool — useful cross-tool context not present in the annotations.

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, front-loaded with the usage trigger followed by the return content. No filler; every clause (item types, ordering, page, id format) carries 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?

With no output schema, the description must describe the return, and it does: item categories, newest-first ordering, and per-item page. It does not address list size or pagination behavior for accounts following many entities, which is the only remaining gap for a zero-parameter listing tool.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description adds the meaningful 'type:key' identifier format that links this listing output to the unfollow input, which is more than the empty schema conveys.

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 ('Lists the drugs, genes, processes and saved searches their account follows'), enumerating the exact item types returned. An agent can distinguish this from siblings like list_feed or follow without opening anything else.

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 an explicit trigger ('Use this when the user asks what they follow on AgingResearch.News') and implicitly links to the unfollow sibling by explaining that an entity's id is the 'type:key that unfollow takes'. It does not state a when-not condition, but the routing intent is clear.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description goes further by disclosing the data sources, the default sort order (newest award first), and the exact fields returned (title, funder, holder, investigators, amount, funded period, scheme, link). These are behavioral traits the annotations cannot 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?

Two dense sentences, front-loaded with the trigger before the routing exclusion and the filter list. Nearly every clause earns its place, though the second sentence packs sources, sort order, return fields and filter modes into one long run-on that could be slightly tightened.

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 an 8-parameter, no-required-args listing tool with no output schema, the description supplies the missing return-value detail (enumerated fields), the ordering guarantee, the source coverage, and the filter model. Nothing an agent needs to select or invoke it correctly is absent.

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, but the description adds meaning beyond the schema by tying the entity filter to a sibling ('type:key, as find_entities gives') so the agent knows where to obtain a valid key, and by framing the filters as narrowing dimensions (entity named in title, funder/holder key, title words, award date). It does not restate format details like the cursor's page-continuation contract.

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 (lists research grants) plus scope (aging-relevant grants from NIH, CORDIS, UKRI, Wellcome, newest first). It also names the sibling it is not — 'for company financings use list_news' — so an agent can distinguish it from other list_* tools without opening schemas.

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?

Opens with an explicit trigger ('when the user asks who funds work on a target, a drug, a process or a lab, how much and since when') and closes with an exclusion plus the correct alternative ('Other funders and private money are not here; for company financings use list_news'). Both when-to-use and when-not-to-use are covered.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds substantive traits beyond that: one story per event (deduplication), newest-first ordering, the publisher of record, and links to every outlet that covered the event.

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?

Front-loads the usage trigger, then the return semantics, then the filtering summary and exclusion. Three sentences with little waste, though the publisher/outlet-links clause is descriptive padding that could be trimmed without loss.

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 no output schema, the description carries the return shape and does so adequately: one story per event, newest first, sourced, with coverage links. All five optional parameters are schema-documented, cursor pagination is explained in the param, so nothing an agent needs to call this 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%, so q, kind, limit, since and cursor are all fully documented in the schema itself. The description only adds a summarizing line ('Narrow by words, kind or date') that maps loosely to q/kind/since, giving baseline value without new syntax or format detail.

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+resource (list news) with a tightly scoped domain: aging research and longevity industry events, enumerating the covered categories (financings, trial readouts, approvals, policy, conferences). It also distinguishes itself from generic siblings by excluding general, political and market news, so an agent can tell it apart from list_stories/list_feed without opening the schemas.

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?

Opens with an explicit trigger ('Use this when the user asks about events in aging research and the longevity industry') and closes with a clear exclusion ('Only news of this field; not for general, political or market news'). It does not name specific alternative siblings for those excluded cases, so the routing guidance stops just short of fully explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: results are ordered by date added (not relevance), and the corpus is scoped to what AgingResearch.News has read. It stops short of describing pagination mechanics, though the cursor param schema does.

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?

Dense but front-loaded on the usage trigger, with the search_papers routing placed at the end. It is somewhat long and repeats the filter story across two sentences, but every sentence carries useful routing or scoping 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 12-parameter, zero-required list tool with full schema coverage and safety annotations, the description covers trigger, ordering, corpus scope and the sibling alternative. Nothing critical is missing, though it does not summarize the default page size or return shape (no output schema exists).

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%, so all 12 parameters are already documented in the schema. The description reinforces that filters mirror search_papers and that author resolves names or ids, but adds little beyond what the structured fields already state, 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?

States a specific verb (list) and resource (papers), plus the defining scope: the newest papers by the date they were added. It names concrete filters (field, study type, body system, author) and distinguishes itself from search_papers, so an agent can tell the two apart without opening either schema.

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?

Opens with an explicit trigger ('Use this when the user asks what is new') and gives the counter-case ('For the papers that best answer a question, use search_papers'). It also supplies concrete use cases (journal club shortlist) and notes author accepts a name or an author_id from get_paper.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. With no output schema, the description usefully adds return shape: newest-first ordering and each item's title plus its address where the answer and sources live.

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 usage trigger is front-loaded and the sentence wastes little; the return description is compact. It is a single run-on sentence but remains readable and appropriately sized.

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 one-parameter read-only list tool with annotations covering safety and no output schema, the description supplies the trigger, ordering, and return fields. Nothing critical for correct invocation is missing, though naming get_ask_answer as the single-item alternative would complete the picture.

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 single limit parameter is fully documented with its range and default, so the schema carries the parameter burden. The description's 'most recent' phrasing implies recency ordering but adds no limit syntax or semantics beyond the schema.

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 (lists the user's questions to AgingResearch.News) and scopes it to 'their most recent conversations.' It implicitly distinguishes itself from get_ask_answer by listing rather than fetching a single answer, though it never names that sibling explicitly.

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?

'Use this when the user asks about questions they asked AgingResearch.News (Ask) before' is a clear usage trigger. It gives no explicit when-not or named alternative, so it falls short of full routing guidance.

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

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

Annotations already carry readOnly/idempotent/non-destructive, so the safety profile needs no restating. The description adds genuinely new behavioral context: the return shape (plain-language headline, body, why-it-matters, caveats, plus the paper), newest-first ordering, and the editorial scope limit that only story-selected papers appear. It stops short of describing pagination/volume behavior, which the schema handles instead.

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?

Three tight sentences: use case, what gets returned, filters plus alternative. The opening use-case list ('what happened this week... a short list for a journal club') is slightly wordy but earns its place by anchoring intent. Front-loading is good, though it starts with intent rather than the action.

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 7-param, filter-only list tool with no output schema, the description supplies everything an agent needs: what a story contains, ordering, the story-selected scope, usable filters, and the routing alternative. Nothing about invoking it correctly is left unstated.

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 explains matching semantics ('A paper matches when it involves any of them', cursor reuse guidance, date formats). The description only restates the filter dimensions ('Narrow by category, body system, study type or publication date') without adding interpretation, 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?

States a specific verb and resource ('Lists the stories AgingResearch.News wrote about new papers, newest first') and immediately scopes it ('each checked against its paper'). It explicitly distinguishes itself from the sibling search_papers by contrast: 'Only the papers chosen for a story; for every paper on a question use search_papers.'

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?

Opens with a concrete when-to-use trigger ('when the user wants a readable round-up of recent findings: what happened this week... or a short list for a journal club'), then names the excluded case and the alternative tool by name. The routing decision between list_stories and search_papers is fully specified.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is to add operational context — and it does: results are ordered by newest registry update first, the default relevance floor is 1.8, and scope is restricted to aging-related trials. It does not mention pagination limits beyond what the cursor/limit schema already implies, so not 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?

Front-loaded with the use case, then scope, then return fields, then filters, then the sibling pointer. Every sentence carries information, though the middle catalog of fields is a slightly listy run-on rather than maximally tight.

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 no output schema, the description names the returned fields (phase, status, sponsor, size, conditions, interventions, latest change) and the ordering, and the schema handles pagination via cursor/limit. For a 9-parameter, 0-required read tool, nothing an agent needs to call it 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%, so the enums, date format, limit bounds, and cursor mechanics are already fully documented. The description only restates the filterable axes in prose (words, phase, status, focus, industry, update date) without adding syntax or defaults beyond the schema; 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?

States a specific verb (lists) and resource (clinical trials bearing on human aging from ClinicalTrials.gov), and distinguishes itself from get_trial ("Read one with get_trial") and from generic trial registries ("Only trials about aging, not every registered trial"). An agent can route correctly without opening the schema.

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 concrete triggering user intents (what is recruiting, what changed lately, which trials test a drug, which companies run them) and names the exclusion plus the sibling to use for single-item retrieval. When-to-use and when-not-to-use are both explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-openWorld). The description adds genuinely non-structured behavior: the feed defaults to 'For you' when the user is signed in and 'Top' otherwise, and search is included in the view. That auth-dependent default is useful disclosure beyond the annotations.

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: the invocation trigger comes first, followed by a compact enumeration of the view's contents. No filler, no repetition of the name or annotations.

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 no output schema, the description carries the burden of describing what the caller gets, and it does: stories, follows, recent questions, and search, plus the default-tab rule. For a single-optional-param read-only view tool, nothing material 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 enum values are self-explanatory, so the baseline would be 3. The description adds meaning by explaining what happens when 'tab' is omitted — the default is derived from sign-in state ('For you' when signed in, else 'Top'), which the schema does not convey.

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 states a specific verb ('open') and resource (AgingResearch.News) plus the composite content it surfaces: newest stories, follows, and recent questions with search. It implicitly contrasts with the granular list_* siblings ('in one place'), but never names an alternative, so sibling differentiation is inferential rather than explicit.

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?

'Use this when the user asks to open AgingResearch.News or to see their feed, follows and recent questions in one place' gives a clear triggering condition for invocation. It offers no when-not guidance and does not point to list_feed / list_follows / list_questions as the granular alternatives, which an agent choosing between them would want.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that results come back 'as cards' and span topics and papers, which is modest extra context. It says nothing about result richness, pagination, or ranking.

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?

A single tight sentence with no filler. The 'sidebar's search' framing is slightly wasted given it says nothing about function, but the whole definition is short and front-loaded.

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 simple single-parameter read tool whose annotations cover safety and with no output schema to explain, the description covers the essentials of what is searched and the card return form. It remains incomplete on sibling differentiation, which is the main gap an agent needs.

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?

The single parameter 'q' has no schema description (0% coverage), so the description must compensate. 'Matching words' hints that q is a keyword string, which adds some meaning beyond the schema's type and length bounds, but it does not explain matching semantics or expected input shape.

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?

It names a resource (topics and papers) and the matching behavior, implying a search verb. However, 'The sidebar's search' frames the tool by its UI location rather than its function, and it never distinguishes itself from the closely related sibling search_papers or find_entities. The core purpose is inferable but not sharply defined.

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?

There is no guidance on when to use this tool versus alternatives, even though search_papers is an obvious overlapping sibling. No exclusions, no context, no prerequisites are stated. The agent is left to guess the routing.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive), so the description is free to add real behavioral context: ranking is best-match-first, results are filtered to aging papers by default, each hit carries study type/aging linkage/subjects/story, and critically that the corpus is not all of PubMed so a null result is not proof of absence. That coverage caveat is exactly the kind of non-obvious behavior an agent needs.

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?

Front-loaded with the trigger and corpus, then filters, then caveats and the sibling pointer. The long list of example topics is verbose but serves a real disambiguation purpose; the whole thing is a single dense block that would read better split into short sentences.

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 12-parameter search tool with no output schema, it covers the essentials an agent needs: scope, default filtering, syntax, result contents, corpus limits, and the follow-up tool. It does not explain pagination/cursor beyond the schema, but nothing required to call it 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%, so the baseline is 3. The description groups the available filters (study type, category, body system, link to aging, preprint status, author, date added) and restates query syntax, which aids scanning but adds little beyond what the schema already documents per parameter.

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 (search) over a specific corpus (titles and abstracts of every paper AgingResearch.News has read) and explicitly separates itself from get_paper for full-text reading. The domain enumeration plus the 'often without the word aging' prompt helps the agent recognize this tool even when the user's phrasing never says 'aging'.

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 a clear triggering condition ('when the user asks what research has found'), explicit exclusions ('Not for personal medical advice, symptoms or product recommendations'), and names the follow-up sibling (get_paper). It also routes the agent correctly when the user's question lacks the word 'aging'.

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

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

Goes well beyond the annotations (which only say write, open-world, non-idempotent): it discloses the several-minute runtime, the exact five sections produced, that it runs on the user's own account and consumes a quota ('counts against their plan's Ultradeep reviews'), and that it returns immediately with a conversation address plus question_id. Quota consumption and async return semantics are exactly the kind of behavior annotations cannot express.

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?

Front-loads the trigger condition and exclusion, then covers output shape, cost, and return semantics in tight declarative sentences. No filler; the five-section list earns its place by setting runtime expectations.

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?

No output schema exists, but the description compensates fully: it explains the immediate return value (conversation address + question_id) and names get_ask_answer as the polling path to retrieve the finished review. Scope, duration, cost, and result retrieval are all covered.

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%, so both parameters (question, conversation_id) are already documented in the schema, and the description adds no syntax or format detail for either. Baseline 3 applies when the schema carries the parameter burden.

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 — starting a multi-minute, five-section evidence review on a research question — and immediately scopes it against 'a short answer', which distinguishes it from the sibling ask_arn. An agent can tell what it produces without opening the schema.

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 ('user asks for a full review of the evidence... beyond a short answer'), when-not ('Not for personal medical advice, doses or symptoms'), and routes follow-up work to get_ask_answer. The trigger condition and the exclusion are both stated, not inferred.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation and safety profile are known. The description adds the concrete effect ('removes the follow from the user's account'), which is useful, but says nothing about permissions, errors when no follow exists (beyond the idempotency hint), or confirmation behavior.

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?

Three short sentences, front-loaded with the trigger, then the input source, then the effect. Nothing is redundant and the ordering matches how an agent decides and then calls the tool.

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-parameter idempotent mutation with full annotation coverage and no output schema, the description covers trigger, inputs, and effect. The only minor gap is not stating failure behavior for a non-existent follow, though the idempotent annotation largely implies it.

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%, so both `key` and the `type` enum are already fully documented in the schema, and the enum constrains `type` to valid values. The description adds provenance the schema lacks — that the pair comes from `list_follows`, `find_entities`, or `get_entity` — but no format or pairing rules, so baseline 3 is appropriate.

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 ('stop following a drug, gene, process or other entity') and scopes it to the AgingResearch.News follow graph, which cleanly distinguishes it from the sibling `follow` and from read-only listing tools. An agent can identify the operation and its domain without opening the schema.

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 an explicit trigger ('when the user asks to stop following...') and tells the agent where the arguments come from by naming `list_follows`, `find_entities`, and `get_entity`. No when-not guidance is offered (e.g., what to do if the user was never following the entity), but the context is clear enough to act.

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