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

Annotations already establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the key behavioral fact that no search is executed and enumerates the analysis output (complexity, intent, PICO, recommendations), which is genuine 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?

Front-loads the core action and constraint in the first sentence, then efficiently documents args and returns. The Returns list is a bit verbose but each line conveys distinct return fields.

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 compensates by enumerating the analysis return fields. For a single-param read-only tool whose annotations cover safety, this is nearly complete; only deeper query-format guidance 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 coverage is 0% and there is one parameter, so the description must carry the meaning. It only restates 'query: The search query to analyze' with no added syntax, format, or length guidance beyond the schema's minLength/maxLength constraints.

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 ('Analyze a search query') and immediately scopes it with the constraint 'without executing the search', which cleanly distinguishes it from the sibling unified_search.

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 usage as a pre-flight step to unified_search ('understanding how unified_search will process your query before actually running it'), naming the alternative and the condition that selects this tool. It does not state when not to use it, but the routing is unambiguous.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the one-PMID API-load constraint, that depth=3 can trigger ~100+ API calls and be slow, and that depth controls traversal cost.

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 well structured with headers, bullets and an example block, and the critical one-PMID warning is front-loaded. However, the output_format enum is fully documented twice (once in the 'Output Formats' section and again under Args), which is redundant padding.

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?

Although there is no output schema, the Returns section describes the response shape (Markdown summary plus JSON graph data with metadata and statistics) and the examples cover the main call patterns, leaving nothing essential 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 description coverage is only 20%, so the description must carry the load, and it does: it documents pmid (single value, example format), depth (range 1-3 with per-level meaning), direction (forward/backward/both), limit_per_level (default 5), and every output_format enum value with its intended consumer.

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 (build) and resource (citation tree/network) and clearly defines the two axes of the tree (forward/citing vs backward/references), which lets an agent distinguish it from the single-direction siblings find_citing_articles and get_article_references 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?

It gives concrete usage conditions: only ONE PMID per call with an explicit instruction to call separately for multiple papers, plus recommendations for depth and direction defaults. It never names a sibling tool as an alternative, so the routing guidance is implicit rather than exhaustive.

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 declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the description adds substantial side-effect context beyond them: the chronicle is persisted with a monotonic revision number, re-runs create revision N+1, and artifact persistence failure 'is reported but does not roll back the already saved Chronicle revision'. That is exactly the write/persistence semantics 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 core purpose, then organized into description, Args, Returns, and Examples – a clean structure where each section is useful. It is longer than strictly necessary; lines like 'Agreement between projections is not independent evidence verification' and the Topic → Branch → Entry → EvidenceArticle walkthrough are informative but add bulk for an agent that mainly needs mode and output selection.

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-parameter, zero-required tool with no output schema, the description covers everything needed: entry conditions, parameter interactions, the artifact-plus-locator return shape, what the audit reports, and four concrete invocation examples. Nothing essential to correct invocation 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?

With schema description coverage reported at 0%, the description carries the full burden and does so thoroughly: it explains the topic/pmids/chronicle_id mutual fallbacks, the max_events inheritance rule and default of 30, min/max_year scoping to topic mode, and enumerates all ten output values, noting which return JSON vs Markdown. This meaningfully exceeds anything the 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 precise verb and artifact ('Build a persisted, versioned, evidence-backed Research Chronicle') and defines what a chronicle is (durable record of how a topic evolved). It explicitly positions itself against siblings, noting it 'replaces the older one-shot timeline tools' and is 'the single entry point for research-evolution work', so an agent can distinguish it from read_research_chronicle and build_citation_tree.

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 clear context for each mode: topic mode for new searches, pmids='last' to reuse prior search results, and chronicle_id to 're-run the stored scope' as revision N+1 so the diff shows research movement. It does not explicitly state when NOT to use the tool or name read_research_chronicle as the read-only alternative, so it stops short of full when/when-not coverage.

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?

Adds real behavioral context beyond annotations: remote service callers may call with no arguments to inspect operator-installed config but cannot mutate server-owned deployment-wide OpenURL settings, and enable defaults to True. It also discloses idempotence implicitly via the preset/config model. It doesn't spell out the full destructive implications for existing config, keeping it at 4.

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 purpose is front-loaded, but the body is padded with ASCII-art banners and a multi-step 'how link resolvers work' explanation that an agent doesn't need to select or invoke the tool. Several sentences could be cut without losing invocation-relevant 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 zero-required-parameter mutation tool with no output schema, the description covers the key risks (server-owned settings, remote vs local mutation), the option space, and default behavior. It leaves the exact returned configuration status format vague, but the rest 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 0%, so the description must compensate, and it does: the Args section plus usage examples explain resolver_url, preset (with the full preset list), and enable/disable semantics. It's strong compensation, though it doesn't note the enum values embedded in the schema pattern or URL length limit.

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 (configure) and resource (institution's OpenURL link resolver for full-text access), and immediately clarifies the integration type and its purpose. An agent can distinguish this from siblings like diagnose_institutional_access or test_institutional_access.

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 lays out three usage modes (preset, custom URL, disable) with example invocations, and notes that remote callers can inspect but not mutate deployment-wide settings. It doesn't explicitly name sibling alternatives such as list_resolver_presets or diagnose_institutional_access for related tasks, so it stops 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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new context by disclosing the mapping's reliability limits — a "limited convenience crosswalk, not a substitute for a current licensed UMLS terminology service." Useful, though it says nothing about return shape or handling of unmapped codes.

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, front-loaded with the purpose, then usage per direction, then the reliability caveat. No filler; every sentence 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?

For a 2-parameter conversion tool with no output schema, the description covers purpose, per-direction input semantics, and data limitations. It leaves the return format only loosely implied ("the returned mapping"), which is a minor 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 description coverage is 0%, so the description must carry the load, and it does: it explains what ``value`` must contain for each ``direction`` (a complete ICD code vs. a MeSH term) and names both direction literals. It could add format examples, but it meaningfully compensates for the empty 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?

The description states a specific verb and resource: "Query the curated ICD/MeSH crosswalk in one explicit direction." This is unambiguous and, since no sibling tool performs code/terminology conversion, an agent can immediately identify its role.

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 explicitly routes the agent per mode: use ``icd_to_mesh`` with a complete ICD-9-CM/ICD-10-CM code, or ``mesh_to_icd`` with a MeSH term. It stops short of a when-not to use the tool (beyond the UMLS caveat), so it falls just short of the top tier.

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 and idempotentHint=true, but the description adds genuinely useful context beyond them: that execution history is destroyed (not just the config) and that process-level schedules are removed only after the deletion succeeds, with isolated tenants exempt from scheduler mutation. That is real side-effect disclosure 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?

Front-loads the destructive action in the first sentence, then adds the tenant/scheduler caveat, then Args/Returns. Efficient and well-organized, though the tenant-scheduler sentence is somewhat more detailed than most callers need.

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 covers the return ('Confirmation of deletion'), the scope of destruction, and the scheduler side effect. It is nearly complete for a single-parameter destructive tool; only name-discovery and irreversibility recovery guidance are 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 0% and the description only restates the obvious ('name: Name of the saved pipeline to delete'). It does not explain the naming constraints already implied by the schema (lowercase, pattern, 64-char limit) or how to discover valid names, so it adds little beyond a bare restatement.

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 ('Permanently delete a saved pipeline configuration and execution history'), which is enough to separate it from save_pipeline, list_pipelines, and load_pipeline. It does not explicitly contrast itself with the very similar unschedule_pipeline sibling, which also touches scheduling, so sibling differentiation is only partial.

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 word 'Permanently' hints this is the irreversible removal path, but there is no explicit when-to-use/when-not guidance and no pointer to unschedule_pipeline for the case where the user only wants to cancel scheduling. The agent must infer the boundary between delete and unschedule.

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 establish readOnly/idempotent/openWorld/non-destructive, and the description adds substantial behavior beyond them: the three probe phases, what each probe does with the DOI, that EZproxy requires exported browser cookies and specific env vars, and that it probes live external hosts. Auth and network prerequisites are disclosed, which is exactly the added value expected.

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 purpose and organized into numbered phases plus a Usage block, so it is easy to scan. It is somewhat long and the docstring-style Args/Returns sections partly restate the schema, but each section contributes usable detail 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?

For a 3-parameter diagnostic tool with no output schema, the description covers purpose, all probe phases, configuration prerequisites, and the markdown report it returns. The only notable gap is the absence of any pointer to the overlapping institutional-access siblings, which leaves an agent unsure of routing between them.

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% for the top-level parameters, so the description must carry the burden, and it does: it defines source (exactly one PMID or DOI, with the PMID-to-DOI resolution behavior explained), try_direct (Phase 1 toggle, default True), and try_ezproxy (Phase 2 toggle, default True). This adds real meaning — the resolution side effect — beyond the schema's bare booleans.

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 precise verb and resource ("Diagnose why institutional fulltext access succeeds or fails for an article") and enumerates the three probes it runs, so the agent knows exactly what it does. However, it never differentiates itself from closely related siblings such as test_institutional_access, configure_institutional_access, or get_institutional_link, so it falls short of a 5.

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 well conveyed through two concrete invocation examples and clear preconditions (campus/VPN IP for Phase 1; EZPROXY_HOST/COOKIE_FILE/ENABLED for Phase 2; manual OpenURL when automated paths fail). There is no explicit when-not-to-use guidance or routing to the sibling tools that overlap this space, so it is clear context without alternatives.

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=true, so safety is covered. The description nonetheless adds a real behavioral trait beyond them: inputs are string-only and the whole batch fails if any single PMID is invalid — an all-or-nothing failure mode an agent must plan around.

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 Args block is well organized and front-loads the key batch-failure constraint, but the long format enumeration partially duplicates the schema examples, and the 'Returns: Detailed information for each article' line is nearly tautological and adds little.

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 return value is described only as 'detailed information for each article', leaving the agent unsure what fields come back. Combined with no usage guidance, the definition is adequate for calling but thin on what to expect and when to choose 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?

With schema coverage at 50%, the description compensates well for the pmids parameter, enumerating single, comma-separated, prefixed, list, JSON-array-string forms plus newlines, semicolons, pipes and Chinese separators — more than the schema examples convey. It says nothing about output_format, which the schema's enum/default already covers.

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: 'Fetch detailed information for one or more PubMed articles.' This is clear enough to distinguish from lookup-style siblings like get_fulltext or get_citation_metrics, though it never explicitly names what it is not versus those tools.

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?

No guidance on when to use this versus alternatives such as get_fulltext (full text), get_citation_metrics (metrics), or get_article_figures. The description assumes the agent already knows it wants article metadata; there are no exclusions or prerequisites.

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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully covered by structured data. The description reinforces the forward-in-time direction and notes the PubMed Central data source, which is mild added context. It does not add behavioral detail beyond annotations (no coverage notes, ordering, or pagination), so a 3 is appropriate.

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 core purpose well, but the heavy ASCII-banner formatting, emoji, and an EXAMPLE block that largely restates the usage section consume substantial space beyond the essential two-sentence purpose. Helpful but not tight; every line does not earn 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?

For a two-parameter read-only lookup with no output schema, the description covers when to use it, the direction of the search, the data source, and both parameters. It lacks detail on result ordering/return fields, but annotations and the schema carry most remaining burden. Nearly complete.

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 50%. The description documents pmid (accepting '12345678' or 'PMID:12345678') and the limit range/default (1-100, default 10), which matches the schema even though the schema actually supports more formats (URLs, backticks). The description adds no syntax beyond the schema's own pmid description, so baseline 3 is right.

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 ('Find articles that cite a given PubMed article') and explains the data source. It explicitly distinguishes itself from citation-based backward search (get_article_references) and topic-based search (find_related_articles), so an agent can route correctly among the many 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?

Provides explicit use cases (impact tracking, follow-up studies, controversies, literature review) and a COMPLEMENTARY TOOLS section naming both alternatives with the condition that selects each. 'Direction: Source Paper → Papers that cite it (FORWARD in time)' unambiguously frames when to use this versus backward search.

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, so the safety profile is covered. The description adds genuinely useful behavior context: results are algorithm-based similarity (topics, MeSH terms, authors), not citation-derived, and papers are not ordered by publication date. It does not mention pagination, rate limits, or error cases for an unknown PMID.

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 purpose is front-loaded in the first two lines, but roughly 30 lines of box-drawing separators, emoji, and a workflow example that largely repeats the numbered sibling list is oversized for a two-parameter tool. Decorative formatting earns no place; the comparative content is the only part that does.

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 read-only lookup with two parameters and no output schema, the description is nearly sufficient: it covers what it does, when to use it, inputs, and that it returns 'similar papers'. The return description ('List of related articles with details') is vague and there is no note on ordering or truncation, but annotations carry the safety/idempotency 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 description coverage is 50%; the pmid schema entry itself already documents accepted forms far more precisely (URL, prefix, backticks, rejections) than the description's '12345678' or 'PMID:12345678'. The description restates the limit range/default that the schema already enforces, so it adds little beyond the schema. 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?

The opening line states a specific verb+resource ('Find articles related to a given PubMed article') and the second line names the underlying mechanism (PubMed's Related Articles feature). The numbered sibling comparison makes it unmistakable versus find_citing_articles and get_article_references.

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 explicitly routes the agent: 'Good for: Discovering related research you might have missed' plus named alternatives for forward and backward citation search, with a three-step example workflow showing when each tool is appropriate. No inference required.

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, openWorldHint and destructiveHint=false, so safety and idempotency are covered. The description adds real behavioral context: reliance on external NCBI ESpell and MeSH services, the note that 'focused' adds an RCT publication-type filter but 'study quality still requires appraisal', and a detailed Returns breakdown. It stops short of stating rate limits or failure modes, so it is strong but not exhaustive.

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 purpose is front-loaded and the Args/Returns blocks earn their place, but the two MODE walkthroughs are very long and largely re-document orchestration that overlaps the sibling tools' own descriptions (e.g. detailed PICO steps and filter syntax). The box-drawing formatting pads length without adding call-time clarity, so it is over-sized relative to the marginal 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?

With no output schema and 0% parameter description coverage, the description supplies everything needed: purpose, the two invocation patterns, full parameter semantics, and the exact JSON return fields including estimated_count and pubmed_translation. An agent can call this correctly and interpret the result without consulting other sources.

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 description carries the full burden, and it does: 'topic' is explained as 'a single keyword or PICO element', each 'strategy' enum value is given distinct meaning including the caveat that focused adds an RCT filter without guaranteeing quality, and check_spelling/include_suggestions are explained with their defaults. This fully compensates for the bare 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?

The opening lines state a specific purpose — 'Gather search intelligence for a topic - returns RAW MATERIALS' and 'BUILDING BLOCKS for search, not finished queries' — and it expands this into concrete outputs (corrected_topic, keywords, mesh_terms, all_synonyms, suggested_queries). This clearly distinguishes it from siblings like unified_search (executes) and analyze_search_query (interprets), and even resolves the naming tension between 'generate_search_queries' and 'not finished queries'.

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 spells out two distinct usage modes with user-intent examples and explicit step-by-step routing to sibling tools (validate_pico_plan, analyze_search_query, unified_search), plus when to apply each clinical_query filter. An agent knows exactly when to pick keyword mode vs PICO mode and what to call next, so 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety and repeatability are covered. The description adds real value beyond that by disclosing the return contents (figure labels, captions, image URLs, PDF links) and the open-access-only limitation, though it says nothing about failure modes for non-OA articles or result limits.

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?

Purpose is front-loaded in sentence one, then the Args/Returns/Example blocks are scannable and each line is actionable. There is minor duplication between the prose return sentence and the 'Returns:' block, but the structure is efficient for the amount of parameter complexity it must carry.

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 small read-only tool with no output schema, the description covers the identifier format, the two optional extraction flags, and the shape of the result, which is what an agent needs to call it. The unmentioned output_format parameter and the absence of any behavior note for non-open-access input are the only remaining gaps.

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?

With top-level schema coverage at 0%, the description carries the load and does so for three of four parameters: it explains the discriminated source object with concrete PMID/PMCID examples, and clarifies include_subfigures and include_tables. The gap is output_format (markdown/json/toon, default markdown), which is never mentioned in the description.

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 opening sentence gives a specific verb, resource, and scope: structured figure metadata (label, caption, image URL) plus PDF links from a PMC Open Access article. That scope cleanly separates it from siblings like get_fulltext, search_biomedical_images, and prepare_figure_search without needing to name them.

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 through the 'PMC Open Access article' constraint, which tells the agent this won't work for closed-access papers. There is no explicit statement of when to choose this over get_fulltext or prepare_figure_search, and no stated preconditions such as whether a prior resolve/lookup step is needed.

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 and openWorldHint, so the safety profile is fully covered by structured data. The description adds directional semantics and a worked multi-tool workflow, but says nothing about error behavior for an invalid/unknown pmid, whether missing references yield an empty list, or pagination beyond the limit cap. With annotations carrying the behavioral load, a 3 is appropriate.

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 core statement is front-loaded and the example workflow genuinely helps an agent chain calls, but the ASCII banner blocks, emoji headings and repeated direction framing consume a large fraction of the text without adding decision-relevant content. Information is real but over-formatted for its size.

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, and the description gives only a thin return statement ('List of referenced articles with details'), but the direction, scoping, example chaining and error-free happy path make the tool callable correctly. A short note on return fields or empty-result behavior would close the 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 50%: pmid is richly documented in the schema (prefixes, URL form, backticks, rejection rules), while limit carries only bounds. The description restates pmid formats ('12345678' or 'PMID:12345678') and the limit range/default, both of which already appear in the schema, so it adds no meaning beyond the structured fields. Baseline 3.

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 ('Get the references (bibliography) of a PubMed article') and immediately positions it against a named sibling: 'This is the OPPOSITE of find_citing_articles'. The backward-vs-forward citation contrast lets an agent pick the right tool 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?

Provides explicit when-to-use categories (foundational papers, methodology sources, background reading, verifying claims) and an explicit alternative with the selecting condition (get_article_references = papers this article cites; find_citing_articles = papers that cite it). 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real behavior beyond that: batching is fail-closed and capped at 1,000 items before deduplication, and iCite transport/response failures surface as an explicit retryable error rather than an empty result. Rate limits and auth requirements are not mentioned.

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 what the tool returns, then Args, then Returns, using headers and bullets so an agent can scan it. The metric glossary earns its space because those fields are non-obvious, but the duplicated sort_by listing (once under returns, once under args) adds some redundancy.

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 correctly spends space explaining the return fields and their normalization, and it also covers batch limits and failure behavior for a 6-parameter, open-world tool. The omission of output_format and of any statement about ordering direction or result caps keeps it short of fully complete.

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 reported as 0%, so the description carries the burden and mostly does: it documents the multiple PMID input formats (comma-separated, list, JSON array string, 'PMID:' prefix, 'last'), the batch cap, every sort_by enum value with meaning, and the semantics of min_citations/min_rcr/min_percentile with example thresholds. The one gap is output_format, which is never mentioned in the prose despite being a real enum 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+resource ('Get citation metrics from NIH iCite for articles') and enumerates exactly which metrics come back, including the meaning of each (RCR, nih_percentile, apt). It is clear what the tool does, but it never names or contrasts itself against plausible siblings such as find_citing_articles or build_citation_tree, leaving the agent to infer the boundary.

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 implied rather than stated: sorting/filtering is described, 'relative_citation_ratio' is marked recommended, and 'last' is noted as reusing PMIDs from the previous search. There is no explicit when-to-use/when-not guidance or named alternative for retrieving citation data by other means, so the agent must infer the context.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value by stating the return payload contents (formula, SMILES, properties), but says nothing about error behavior for invalid CIDs or rate limits on the external PubChem service.

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 one-line purpose followed by short Args/Returns blocks. No filler, though the Args/Returns labels are slightly heavy for a single-parameter 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 simple single-parameter read tool with no output schema, the description supplies enough: purpose, the parameter's meaning, and the shape of the return. The missing piece is routing guidance relative to search_compound.

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 description must carry the load. It expands 'cid' into 'PubChem Compound ID', which is more than the bare string-typed schema property, but it omits the numeric-string format constraint captured only by the schema 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?

States a specific verb and resource ('Get detailed information about a compound') and names the identifying key (PubChem CID). It does not distinguish itself from the sibling search_compound, but an agent can still tell what this tool does from the name and description alone.

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 over search_compound or get_compound_literature, nor any prerequisite or CID-acquisition note (e.g., you must first call search_compound). The agent is left to infer the workflow.

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, openWorldHint and destructiveHint=false, so the safety and idempotence profile is covered. The description adds useful provenance (data comes from NCBI curated links, not free-text mining) but says nothing about pagination, behavior on zero results, or rate limits, so it is a modest addition rather than rich behavioral context.

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 purpose in one sentence, then adds a provenance line and Args/Returns sections that each carry information not present in the 0%-coverage schema. Structure is clear, though the Args/Returns block is formulaic rather than tightly integrated.

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, explaining the return value ('JSON with linked PubMed IDs') is genuinely necessary and present, as is the data source and both parameter meanings. For a simple two-parameter lookup this is close to complete; only edge-case behavior (no links found, ordering) 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 description coverage is 0%, so the description carries the burden, and it does: it identifies 'cid' as a PubChem Compound ID (the schema only gives a string pattern) and gives the 'limit' range of 1-100. It omits the default of 20 and any format/ordering semantics for the returned IDs, keeping it short of 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?

States a specific verb and resource ('Get PubMed articles linked to a compound') plus the mechanism ('NCBI's curated compound-to-publication links'). An agent can distinguish this from the analogous get_gene_literature and from general search tools like unified_search 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?

There is no explicit when-to-use, when-not-to-use, or alternative tool guidance. It never clarifies the relationship to siblings like find_related_articles, get_compound_details, or search_compound, leaving the agent to infer the boundary from purpose alone.

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 declare openWorldHint=true, readOnlyHint=false and non-idempotent, and the description adds real behavioral context beyond them: the source fallback chain, the tri-state semantics of allow_browser_session, and the guarantee that abstracts are never substituted for missing body evidence. It omits rate limits, permissions, or failure behavior, keeping it short of 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 a one-line purpose, then a numbered source chain, then Args and examples. Slightly long because the extended source list and two near-duplicate examples consume space, but every section is scannable and 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?

For a 7-parameter tool with no output schema and no annotation-specified return format, the description covers inputs thoroughly and briefly states the return (fulltext content with PDF links). A short note on failure modes when no source yields fulltext would complete 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 0%, so the description carries the full burden and does so: it defines the discriminated source object with three concrete examples, explains sections filtering and its missing-title reporting, and gives the default plus purpose of include_pdf_links, include_figures, extended_sources, output_format, and the allow_browser_session tri-state.

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 (multi-source fulltext retrieval) and distinguishes itself from siblings like fetch_article_details or get_article_figures by describing the retrieval/fallback chain rather than metadata lookup. An agent can tell what it returns 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?

Explains the standard retrieval order and exactly when to enable extended_sources (searching the extended downloader chain after standard policy) and when to disable include_pdf_links. It does not explicitly name sibling alternatives such as fetch_article_details, so routing between tools is left partly 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered without the text. The description adds the return shape (symbol, name, summary, location), but says nothing about behavior for invalid/unknown gene IDs, rate limits, or external NCBI dependency despite openWorldHint=true.

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 one-line purpose followed by Args and Returns sections; every line earns its place with no filler or repetition of 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?

With no output schema, the Returns block usefully enumerates the JSON fields an agent can expect. Minor gap: no mention of error/missing-gene behavior, which matters for a single-required-param lookup 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 0%, so the schema only conveys the type and a regex pattern, not meaning. The description compensates by defining gene_id as an NCBI Gene ID and indicating where to obtain it, which is more than the schema provides.

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 ('Get detailed information') and resource ('a gene') keyed by NCBI Gene ID. It is clearly distinguishable from the search_gene sibling by the 'details vs search' distinction, 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?

The parenthetical '(from search results or known)' implies the ID comes from a prior search, which is a useful workflow hint. However, it does not state when to use this over search_gene or get_gene_literature, nor any prerequisites or 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds the data provenance (NCBI curated links over keyword search), which is useful for interpreting result trust, but says nothing about auth, rate limits, or truncation behavior. With annotations doing the heavy lifting, a 3 is appropriate.

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 one-line purpose, then concise provenance note, then Args/Returns blocks. Every line earns its place and nothing is padded.

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 correctly states the return shape ('JSON with linked PubMed IDs'), and annotations cover safety. Both parameters are documented, so an agent has what it needs; only edge-case behaviors remain unspecified.

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 description carries the burden and mostly does: it clarifies gene_id is an NCBI Gene ID (not a symbol) and gives limit's meaning and 1-100 bound. It still doesn't explain the format constraint on gene_id beyond the schema pattern, so 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?

States a specific verb and resource ('Get PubMed articles linked to a gene') and explicitly contrasts itself with keyword-based retrieval, so an agent can separate it from unified_search. It does not name or distinguish itself from other article-linking siblings like find_related_articles, so it falls just short of 5.

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 clear context for when this tool is the right choice: when you want curated gene-to-publication links rather than keyword matches. No explicit when-not conditions or prerequisites are stated, which keeps it from 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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the prerequisite dependency on configure_institutional_access, which is useful behavioral context beyond annotations. It also notes the return is a link or error message.

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 well-structured with clear sections, but it includes decorative ASCII art and emojis that add length without informational value. The core content is efficient 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?

Given the complexity of the parameter (a discriminated union with multiple formats) and the lack of schema descriptions, the description provides complete information needed to call the tool correctly, including prerequisites, formats, and return type.

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 description must clarify the parameter. It does so thoroughly by showing three different formats for the 'source' parameter with concrete examples, explaining that exactly one explicit PMID, DOI, or bounded metadata object is required.

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: generating an OpenURL institutional access link for an article. It clearly distinguishes itself from siblings like configure_institutional_access or test_institutional_access by focusing on link generation.

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 includes a PREREQUISITES section requiring configure_institutional_access(), and provides concrete usage examples for PMID, DOI, and metadata. It doesn't explicitly state when not to use it, but the context 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=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds genuine behavioral value beyond that: it explains the diff-analysis semantics (new/removed articles vs. the previous run) and the shape of returned data, which is not derivable from 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?

Front-loaded with a one-line purpose, then Args and Returns sections. Every element earns its place; the only minor overhead is the conventional docstring scaffolding, which is still efficient and scannable.

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 fills the gap by describing the return contents (date, article count, new/removed articles, status). Annotations cover the safety profile and both parameters are addressed, making it largely complete, though the name-pattern constraint and absence of pagination guidance are minor gaps.

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 description must carry the load. It documents both parameters, including the limit default of 5, which the schema also encodes. However, it does not explain the name pattern (lowercase slug, max 64 chars) or the limit bounds (1-100), leaving format constraints undocumented.

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 execution history for a saved pipeline') and clarifies scope ('for a saved pipeline'), which distinguishes it from pipeline-management siblings like save_pipeline, list_pipelines, and delete_pipeline. It does not explicitly name any sibling, but the read-only history focus is unambiguous.

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?

No explicit when-to-use guidance or alternatives are given. The phrase 'for a saved pipeline' implies the pipeline must already exist, but the description never says to use list_pipelines first, nor when this is preferred over any other tool. Usage is only weakly inferable.

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 and openWorldHint, so the safety profile is fully covered. The description adds the useful constraint that source is 'exactly one PMID or PMCID' and sketches the return content ('counts and sections'), but says nothing about rate limits, coverage gaps, or failure behavior for non-indexed articles.

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?

Well front-loaded: the core purpose is the first sentence, followed by cleanly separated Args and Returns blocks. Slight redundancy between the prose list of entity types and the bulleted semantic_type options, but nothing egregious.

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 does sketch the return ('List of text-mined entities with counts and sections'), and annotations cover safety. However, one of three parameters (output_format) is undocumented and the semantic_type list is incomplete, leaving gaps an agent must guess at.

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 0%, so the description carries the parameter burden. It documents the source discriminator shape and gives human-readable labels for semantic_type values, but it omits the enum member 'EFO' present in the schema and never mentions the output_format parameter (markdown/json/toon) at all.

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 text-mined annotations from Europe PMC') plus the scope of what is extracted (genes, diseases, chemicals, organisms). An agent can distinguish it from general article tools like fetch_article_details, though it never names a sibling alternative 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?

The description explains the mechanics of the call (one PMID or PMCID, optional semantic_type filter) but never says when to reach for this tool versus fetch_article_details, search_gene, or get_gene_literature. No exclusions or prerequisites for the operation itself are stated.

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, so safety is covered. The description adds the return shape (table with name, scope, description, tags), which is useful behavioral context, but says nothing about ordering, pagination, or limits.

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 one-line purpose followed by a compact Args/Returns block. Every line earns its place; 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 supplies the return shape, and both param semantics are documented. Only minor gaps remain (no ordering/pagination/limits, no sibling routing).

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 description must carry the params—and it does: tag (filter, empty=show all) and scope ('workspace'/'global'/''=show all). This fully maps to both parameters and clarifies the empty-string sentinel semantics the schema only implies via defaults.

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?

Clear specific verb+resource: 'List all saved pipeline configurations.' An agent immediately knows this is a read/list operation. However it does not distinguish itself from siblings like get_pipeline_history, load_pipeline, or list_resolver_presets.

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 implied by the filtering args (tag/scope) but there is no explicit statement of when to use this vs load_pipeline, get_pipeline_history, or save_pipeline. No prerequisites noted (e.g., workspace context).

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 establish that this is a read-only, idempotent, non-destructive, closed-world listing tool. The description adds useful context about what the presets are and that the return value includes preset URLs, which matters because 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?

The substantive content is short and front-loaded, but the large ASCII banner and emoji add visual noise without conveying additional information. The core sentences earn their place, while the decorative formatting does not.

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 zero-parameter, read-only listing tool with annotations covering safety and no output schema, the description adequately says what is returned: available presets with URLs. It could be slightly more precise about return structure, but it 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?

This tool takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it does not introduce any confusion about inputs.

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: 'List available institutional link resolver presets.' It also names the related sibling configure_institutional_access, which helps an agent distinguish listing presets from configuring access.

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 description implies usage by saying presets should be used with configure_institutional_access(preset="name"), but it does not explicitly say when to call this tool versus alternatives or when not to use it. The intended follow-up workflow is clear, but direct invocation guidance is only 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 mark the tool as readOnly, idempotent, and non-destructive. The description adds useful behavioral details beyond those annotations, including the two supported source formats, the restriction on local-only files for authenticated service callers, and the fact that the returned YAML can be passed onward to unified_search or save_pipeline. This gives agents a clearer model of what happens after load.

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 well-structured and front-loaded with the core purpose, followed by source formats, usage examples, and return behavior. It is slightly longer than strictly necessary because the Args/Returns formatting partially duplicates information already in the schema, but every section adds practical value for correct invocation.

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?

Given the tool's low complexity (one parameter), the description is nearly complete: it covers source variants, an important auth-related limitation, and the return value. It could arguably mention that list_pipelines can be used to discover valid saved names, but this is not essential for calling the tool 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 0% and the schema only defines 'source' as a string with length constraints. The description fully compensates by explaining the accepted source formats with examples ('saved:weekly_remimazolam' and 'file:path/to/pipeline.yaml') and by clarifying the authentication restriction on file paths. This adds substantial meaning beyond the bare 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?

The description states a specific verb and resource: 'Load a pipeline configuration for review or editing.' It clearly differentiates the load action from sibling tools like save_pipeline, delete_pipeline, and list_pipelines, and explains the two source types. The purpose is immediately understandable and unambiguous.

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 description gives clear context for when this tool is appropriate: when a pipeline configuration needs to be reviewed, edited, or prepared for execution or saving. It also provides an explicit exclusion: local-only file sources are disabled for authenticated service callers. It does not explicitly name alternatives to avoid, but the workflow notes referencing unified_search and save_pipeline provide strong situational 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 declare a non-read-only, open-world, non-idempotent operation, and the description adds real behavioral context beyond them: include_abstract=False requires source='local' because official payloads are returned unmodified, local is offline capable, and the return shape is status + export_text. It stops short of explaining latency, rate limits, or side effects that justify readOnlyHint=false.

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?

Well front-loaded with the recommended-default callout, then organized into scannable sections (When to Use, Source Options, Format Selection) and ended with runnable examples. It is long, and the box-drawing banner is decorative overhead, but nearly every line carries actionable 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 4-parameter tool with no output schema, the description covers input formats, defaults, valid parameter combinations, offline vs API behavior, and the return payload shape. Nothing an agent needs in order 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 reported as 0%, so the description carries the full burden and does so thoroughly: accepted pmids encodings (last, comma-separated, list, JSON array string, PMID: prefix), the meaning of each format enum value, the include_abstract default and its source constraint, and the source trade-offs. This is exactly the compensation the low schema coverage requires.

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 ('Export citations to reference manager formats') up front, and the format/source tables make clear it produces formatted citation text rather than fetching or analyzing records. An agent can distinguish it from get_citation_metrics or fetch_article_details 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?

Explicit 'When to Use' list names the concrete scenarios (EndNote/Zotero/Mendeley, BibTeX for LaTeX, manuscript citation lists), and the source/format tables give guidance on which option to pick and when. It also flags a hard constraint (bibtex/csv/json require source='local') so the agent can avoid invalid combinations.

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/openWorld/non-destructive, but the description adds substantial behavior beyond that: it returns ImageContent plus TextContent, does NOT invoke a vision model, imposes an English-only query constraint (Open-i requirement), and notes the host agent controls any subsequent search within its permissions. These are exactly the behavioral facts an agent cannot get from 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 workflow is well front-loaded and scannable, but the block is heavy with ASCII rules and emoji, and several points are restated — the English-only requirement appears in both IMPORTANT RULES and IMPORTANT, and the 'follow user-requested scope' idea is repeated. Some USE CASES bullets duplicate the SEARCH TYPES section, so not every line 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?

For a tool with no output schema, the description fully explains the return payload (ImageContent + TextContent) and the post-call workflow, and it documents all three parameters. An agent has everything needed to call it and to interpret the result 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 0%, so the description must carry the load, and it does: it shows concrete source shapes for both base64 and URL kinds, describes context as 'what to look for in the image', and enumerates the meaning of each search_type value. It stops short of syntax-level detail (URL bounds, base64 size limits) but covers the semantic intent of all three parameters.

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 ('Analyze a scientific figure or image for literature search') and immediately clarifies the actual mechanism — it returns the image via MCP ImageContent rather than performing the search itself. This distinguishes it cleanly from siblings like search_biomedical_images and unified_search, which it names 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?

Provides an explicit numbered workflow, states when to invoke (image provided, literature retrieval in scope), names the exact follow-up tools (search_biomedical_images(), unified_search()), and even gives the condition for the next step. Nothing about when/when-not to use it 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 genuine context beyond that: chronicles persist across sessions, analysis/comparison are instant and re-run no search, and the diff caveat 'Absence does not prove retirement' warns against over-reading removal results. It omits any pagination or sizing detail for large chronicles.

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 purpose, then a scannable per-action list, then interface notes and examples — well organized and mostly waste-free. Minor deduction: the lead sentence advertises an 'analyze' action that does not exist in the discriminator (the real actions are load/list/diff/narrate/milestones/compare), a small internal inconsistency in an otherwise tight layout.

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 six-action, heavily nested discriminated-union tool with no output schema, the description covers every action, the selection shape, the return medium ('Markdown or JSON text depending on the action and output format'), and provides a call example per action. Nothing essential to invoking 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 effectively 0% at the wrapper level (only fragments like 'Positive Chronicle revision' exist), so the description must compensate. It explains that the `request` discriminator makes invalid field combinations unrepresentable, that `compare` takes a typed `selection` of either 2-5 topics or 2-5 Chronicle IDs, and it points at output formats and narrate modes — meaningful semantics the schema alone does not spell out.

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 opening line names a specific verb (read) and resource (stored Research Chronicles) and enumerates the six actions, then names the sibling that creates them (`build_research_chronicle`). An agent can distinguish this read facade from the build tool and from the other read tools 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?

Each action is paired with a condition that selects it (load = one revision, list = stored chronicles, diff = compare two revisions, compare = 2-5 chronicles side by side), and the text routes creation to `build_research_chronicle`. It stops short of explicit 'use X instead of Y' exclusions or prerequisites, but the per-action framing gives clear context.

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/idempotent/non-destructive, so the bar is lower; the description still adds genuine value by disclosing the redaction policy for local paths (requires include_local_paths plus a server setting) and that replay_search returns credential-free arguments. It omits return-shape and pagination-bound behavior, but the security disclosure is substantive.

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 purpose in one sentence, then a tight bulleted action index, then a short paragraph of edge-case rules. The bullets partly restate schema discriminants, but for a 9-way union the index earns its length.

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, so the description carries return-shape burden, and it never says what each action returns beyond a phrase. Most critically, it omits the schema's 'log' action, leaving an agent that reads only the description blind to one valid mode of a highly complex discriminated union.

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% at the top level, so the description must compensate — it does for only a handful of fields (locator, artifact_file, offset/max_chars, include_local_paths). Many discriminants (event_limit, history_limit, query_filter, search_index, status, run_id, kind, tool) get no semantic gloss.

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 lead sentence names a specific verb+resource ('Read session data') and the bulleted action list concretely enumerates the read modes (pmids, article, summary, artifacts, search runs, replay). However the enumeration is incomplete — the schema's 'log' action is never mentioned — and nothing distinguishes this from siblings like read_research_chronicle or fetch_article_details.

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 implied usage ('Each action accepts only its own fields') and a conditional instruction for artifact reads (choose artifact_id vs artifact_uri, page with artifact_file/offset/max_chars), but no explicit statement of when to call read_session versus unified_search, fetch_article_details, or read_research_chronicle.

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, readOnlyHint=false and openWorldHint=true, and the description goes well beyond that: it discloses the four-step directory resolution order, the authenticated-service boundary where remote callers cannot set output_dir/template_file and env paths are ignored, and the filename-collision overwrite semantics. These are non-obvious behaviors an agent could not infer from the 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?

Headings (When to Use, Local Directory Resolution, Authenticated Service Boundary, Args, Returns, Examples) make it easy to scan and the critical scoping info is front-loaded. It runs somewhat long and repeats the format list in both prose and Args, but nearly every line carries actionable 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 9-parameter mutation tool with no output schema, the description covers destination resolution, tenant/auth constraints, overwrite behavior, and even the return shape (written/skipped files, index info, wiki_validation, path vs. logical locator). An agent has everything needed to call it correctly in both local and authenticated contexts.

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 description carries the burden and largely does: the Args block defines all nine parameters, explains note_format semantics ('wiki' default, Foam-compatible), and gives template placeholder examples ({title}, {pmid}, {citation_key}). A few entries remain thin (output_dir is only 'Optional target folder'), but overall it compensates well for the empty schema descriptions.

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+output artifact: 'Save searched articles as guided local wiki/Foam/Markdown notes.' It immediately distinguishes itself from siblings like prepare_export and generic write_file, and the note_format vocabulary (wiki/foam/markdown/medpaper) tells an agent exactly what this produces.

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 'When to Use' block gives explicit sequencing ('After unified_search, persist the selected literature') and names the alternative it replaces ('a structured alternative to generic write_file calls'). It also states the specific capability (Foam wikilinks, wiki_validation) that selects this tool over a plain file write.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description explains that saving overwrites an existing name (upsert semantics) and details storage scope semantics — workspace is git-trackable, global is cross-project, auto resolves at runtime. It does not cover permissions/errors, and the upsert language sits in mild tension with idempotentHint=false, but the destructive behavior itself is disclosed clearly.

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 one-line purpose, then uses Args/Returns structure with a compact usage example. Mostly efficient; the inline example and the repeated 'same format as unified_search pipeline param' remark cost a little redundancy but each 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 'Returns: Confirmation with pipeline metadata' line is a reasonable (if thin) return note, and the description covers format, naming, tags, scope, and overwrite behavior for a 5-parameter mutation tool. Only operational details like permission requirements or failure modes are 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 description coverage is 0%, so the description must carry all parameter meaning, and it does: name format/limits plus overwrite behavior, config format equivalence, tags as a bounded array of canonical tags with examples, description purpose, and all three scope values with defaults. This is a strong compensation for an undocumented 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?

Specific verb+resource ('Save a pipeline configuration') plus scope ('for later reuse'), and it distinguishes itself from siblings by naming the load path (unified_search(pipeline="saved:...")) and implying the inverse of load_pipeline/delete_pipeline. An agent can tell instantly what this does and how saved data flows back into unified_search.

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 clear usage context: the config format matches unified_search's pipeline parameter, pipelines are reusable by name, and the example shows the round trip. It stops short of explicit when-to-use/when-not rules against neighbors such as schedule_pipeline or list_pipelines, so it is clear context without 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 readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is largely covered. The description adds useful behavioral detail about storing diff-mode and notify preferences and returning a confirmation, but it does not explain authorization needs, what exactly is destroyed or replaced, or rate limits.

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 a one-line summary followed by structured Args and Returns sections, with no wasted prose. The vague 'removal result' clause slightly weakens an otherwise efficient structure.

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 destructive scheduling tool with four parameters and no output schema, the description covers parameter meanings and a basic return type, and the annotations supply safety hints. However, it omits when to choose this tool over unschedule_pipeline and leaves the 'removal result' ambiguous, so an agent still lacks some routing and outcome clarity.

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 description carries the burden of explaining parameters. It successfully documents all four parameters, including a concrete cron example and the meaning of diff_mode/notify preference storage, though it does not elaborate on the name pattern or boolean-string nuance already present in 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?

The description states a specific verb ('Schedule') and resource ('saved pipeline') with the scope 'periodic execution,' making the core action clear. However, the later phrase 'removal result' introduces ambiguity with the sibling tool unschedule_pipeline, preventing perfect clarity.

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 description implies usage by saying it schedules a saved pipeline, but it offers no explicit when-to-use guidance, no exclusions, and no mention of the alternative unschedule_pipeline for removing schedules. An agent must infer the routing from the tool name alone.

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/openWorld, and the description adds genuine operational context on top: Open-i accepts English only, built-in CJK translation hints exist but must be verified, limit defaults to 10 with a max of 50, and hmp_type requires collection='hmd'. It does not cover rate limits or result pagination, which keeps it short of 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?

Purpose and the critical language rule are front-loaded, which is good, but the repeated full-width ASCII rule lines and emoji consume substantial tokens without adding information, and the source list restates the opening sentence. The enum documentation earns its space; the decorative separators do not.

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 tool with no schema descriptions and no output schema, the description supplies nearly everything needed to call it correctly, including filter semantics and the return shape in prose. Gaps remain around pagination and behavior when zero images match.

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 description carries the full burden, and it does: every parameter's enum codes are decoded (image_type, collection, sort_by, specialty, license_type, subset, search_fields), inclusion vs exclusion filters are separated, and the cross-parameter dependency on collection='hmd' is stated. Only a few enum members are deferred to "see API 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 first line names the exact verb, resource, and source ("Search biomedical images from NLM Open-i") and the second states the return content (image URLs with caption, article info, MeSH terms). It is unambiguously distinguishable from article-oriented siblings like unified_search and fetch_article_details.

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?

Provides rich context for use: the mandatory English-query rule, a translation workflow, and seven worked examples mapping intent to filters (collection='mpx' for MedPix, video_only for video). However, it never routes the agent away from or toward the closest siblings such as get_article_figures or prepare_figure_search, so the when-not half is missing.

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, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds value beyond that by stating the return shape ('JSON with variant records including significance and conditions'), which is useful given 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?

The content is short and front-loaded: purpose first, then use cases, args, and returns. The heavy '═' divider lines are decorative noise, but they do not meaningfully bloat the semantic content.

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 read-only search with no output schema, the description covers purpose, invocation contexts, both parameters, and the general return shape. Pagination or ranking details are absent, but they are not essential 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 description coverage is 0%, so the description carries the full burden. It explains that 'query' accepts a gene name, variant, or disease condition, and that 'limit' is a 1–50 maximum-result count, which meaningfully supplements the bare schema constraints.

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 ('Search ClinVar for clinical variants') and the use cases make the domain explicit. It does not, however, distinguish itself from sibling tools such as search_gene, search_compound, or unified_search, so an agent cannot route between them from this text alone.

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 USE CASES section gives clear contexts for when to call it (looking up clinical significance, disease associations, pathogenicity classifications). There are no explicit exclusions or alternatives named, but the positive guidance is strong enough to be actionable.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the return shape (JSON records with names, formulas, properties) and the 1-50 limit; nothing about upstream rate limits, match behavior (fuzzy vs. exact), or empty-result handling.

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 purpose and use cases are front-loaded correctly, but the heavy box-drawing separator banners add visual noise without information, and the Args/Returns restatement pads the entry beyond what a two-parameter tool needs.

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 does supply a brief Returns line, and both parameters are named, so nothing critical is missing. It stops short of describing result ordering, result count behavior when limit is hit, or how queries are matched, which matters for an external open-world search.

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 description carries the burden. It documents both parameters — query as 'compound name or description' and limit as 'maximum results (1-50)' — but the query hint is thin (no format/synonym guidance) and the limit note merely restates the schema bounds, leaving the default of 10 unmentioned.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first line states a specific verb and resource: search PubChem for chemical compounds, which is unambiguous on its own. It does not, however, distinguish itself from nearby siblings such as get_compound_details or get_compound_literature, so an agent must infer the boundary.

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 USE CASES block enumerates good reasons to call it (drug lookups, molecular formula, synonyms, properties), which implies usage. But there is no when-not guidance and no explicit routing to get_compound_details (fetch details for a known compound) or get_compound_literature, which are the obvious alternatives.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape ('JSON with gene records including symbols, names, locations') and the result-count range, which 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?

Content is front-loaded (purpose first, then use cases, args, returns) and each content line is short and useful. The triple-line box-drawing banners are pure decoration that consume tokens without adding 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 supplies a brief return summary, and annotations cover behavior for this read-only search. The remaining gap is routing relative to get_gene_details and get_gene_literature, plus any note on result ordering or pagination.

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 description carries the param burden and largely does: query is described as 'Gene name, symbol, or function keyword', and organism includes concrete accepted values ('human', 'Homo sapiens', 'mouse'), which is genuinely useful for a taxonomy-filtered API. The limit line only restates the schema's 1-50 bound and adds no ranking or sorting semantics.

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 clear verb and resource: 'Search NCBI Gene database for gene information,' with a use-case list that scopes what it retrieves (function, aliases, symbols, location). It does not distinguish itself from siblings like get_gene_details or get_gene_literature, so an agent must infer search-vs-fetch from the name alone.

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 USE CASES block gives concrete retrieval scenarios (look up gene function, find aliases/symbols, get chromosome location, search by name or function keyword), which is clear usage context. It stops short of exclusions or naming the alternative tools to use when you already have a gene ID or want literature about a gene.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful scope-limiting context beyond that: it only tests endpoint reachability, actual full-text depends on subscriptions, and a resolver may respond without VPN while still not serving full text.

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 content is useful, but it is wrapped in large ASCII banner blocks with repeated separators, producing substantial visual noise for what amounts to a few sentences. Front-loading is fine, but the decoration is not earning 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?

For a single-parameter, read-only test tool, the definition supplies purpose, scope caveats, a return-value outline, and setup guidance. That is complete enough for correct invocation; the only real omission is how it relates to the sibling diagnostic 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?

Only one parameter and schema description coverage is 100%, so the schema carries the semantic load (format, examples, length limits). The description merely restates the pmid default (38353755), adding essentially nothing beyond what the schema already states.

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 (test) and resource (institutional link resolver configuration) and enumerates what is being checked: configuration, reachability, and response validity. It does not, however, distinguish itself from the sibling diagnose_institutional_access, which appears to cover very similar ground.

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 FREE TEST OPTIONS section gives clear situational guidance: if you lack institutional access, call configure_institutional_access(preset="test_free") first, and it notes most university resolvers respond without VPN. That is real when-to-use context, though it never contrasts with the sibling diagnose_institutional_access tool.

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?

Beyond the annotations (openWorldHint, readOnlyHint=false), the description discloses substantial behavioral detail: parallel multi-source search, dedup/merge, auto-relaxation on zero results, background fulltext prefetch that requires no polling, and env-gated commercial connectors (SCOPUS_API_KEY, etc.). This is far more than the structured 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?

Headers and front-loading make it navigable despite its length, and the length is defensible for an 11-parameter tool with a pipeline DSL. However, there is visible redundancy (the 'exact canonical spelling' rule is repeated) and at least one garbled sentence around the native_semantic/systematic flags, plus decorative box-drawing that adds noise.

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 correctly supplies a Returns section covering query analysis, ICD expansions, statistics, ranked articles, OA links, preprints, relaxation info, and pipeline summaries. Combined with full parameter documentation, nothing needed to invoke 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 0%, so the description carries the full burden, and it does so thoroughly: every parameter (query, limit, sources, ranking, output_format, fulltext, filters, options, pipeline, dry_run, stop_at) is documented with accepted values, defaults, syntax rules, and interactions (e.g. native_semantic/systematic mutual exclusivity, canonical-token requirement).

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 title line plus the numbered WHAT IT DOES list state a specific verb (search) and resource (multi-source academic literature), and the framing as the 'single entry point' distinguishes it from sibling helpers like find_related_articles or analyze_search_query. An agent can immediately tell this is the primary retrieval tool.

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 clear context ('no need to choose between PubMed, OpenAlex, CrossRef') and a rich set of worked examples showing when to add sources, filters, options, or a pipeline. It stops short of explicitly naming sibling alternatives or stating when NOT to use this tool, so it is strong but not fully routing-aware.

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. The description adds one useful behavioral detail beyond that: the response is removed schedule metadata, or an MCP error when no schedule exists (consistent with idempotentHint). It does not state auth/permission needs or whether other schedule config is affected.

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 action, followed by concise Args/Returns sections. No filler; the one-line summary plus parameter and return notes earn their 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?

For a single-parameter mutation with no output schema, the description covers the action, the parameter's meaning, and the return/error behavior, while annotations cover the safety profile. Only permission requirements and interaction with other schedule state are 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 0%, so the schema's 'name' property carries no prose. The description compensates by clarifying the parameter means the 'Saved pipeline name whose schedule will be removed,' disambiguating it from a schedule ID or arbitrary string.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.