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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention any behavioral traits such as read-only nature, rate limits, error conditions, or what the response contains. The description only states what the tool does, not how it behaves or any side effects.

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 concise and front-loaded: two sentences that immediately state the core purpose and value. Every word earns its place, with no redundant or filler 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?

The tool has an output schema, so return value documentation is not a burden on the description. However, the description lacks context about when to use this tool versus simpler search tools, and it does not provide examples or clarify the structure of the query_builder beyond what the schema already states. Given the tool's moderate complexity, the description is minimally sufficient but leaves 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?

The input schema covers 60% of the parameters with descriptions (e.g., query_builder field/term/operator, date_field options). The description adds minimal extra meaning beyond the schema, mentioning 'multiple terms, fields, and Boolean operators' but not detailing the specific parameters or their composition. Since schema coverage is moderate, the description does not significantly compensate for missing parameter details.

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 clearly states the tool's purpose with a specific verb ('Build') and resource ('complex Boolean queries with field-specific search'). It distinguishes itself from sibling tools like global_search and pubmed_search by emphasizing complex Boolean logic and field-specific control.

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 use for complex queries requiring Boolean operators and field-specific search, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or alternatives. The usage context is implied but not directly articulated.

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?

With no annotations, the description carries the burden; it reveals chunking, rate-limit handling, and the return of both successful and failed retrievals. This gives useful behavioral insight beyond the schema, though it omits details like error handling or ordering.

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 two concise sentences, front-loaded with the primary purpose, and contains no filler or redundant 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?

Given the presence of an output schema and full parameter documentation, the description sufficiently frames the tool's role. It could benefit from explicit alternatives or exclusions, but overall it's complete for the tool's complexity.

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 covers 100% of parameters, so baseline is 3. The description adds context that batch_size relates to chunking and rate limits, but doesn't provide any additional parameter-level detail beyond the schema.

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

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

The description clearly states the tool fetches multiple articles, using a specific verb and resource. It implies batch behavior but doesn't explicitly differentiate from siblings like batch_process_articles or fetch_article_summary.

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 notes it handles large batches and respects NCBI rate limits, indicating when to use it (large-scale retrieval with rate-limit management). It doesn't name alternatives or exclusions but provides clear context for usage.

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?

With no annotations, the description carries the burden. It discloses chunked processing and rate limiting, which are useful behavioral traits, but it does not mention whether operations are read-only, require authentication, or how errors are handled. This is partial transparency.

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 two short sentences that are front-loaded with the purpose and add one key detail about handling scale and rate limiting. There is no wasted text.

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 rich input schema (all parameters described, nested objects explained) and the presence of an output schema, the description covers the high-level usage and scale. It could mention the specific operation types, but those are already in the schema, so the description is adequate for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents all four parameters with examples and allowed values. The description adds no additional meaning about parameters, so the baseline of 3 applies.

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

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

The description states it processes large sets of articles with batch operations, but 'process' is a generic verb that does not specify the actual operations (fetch summaries, export BioC, etc.). It identifies the resource (articles) and scale, but lacks a specific action, making it vague and not clearly distinguishing from siblings like batch_fetch_articles.

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 for large datasets ('10K+ articles') and mentions efficiency, which provides some context. However, it does not explicitly state when to use this tool over alternatives like batch_fetch_articles, nor does it give exclusion criteria.

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?

With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It mentions the Entrez History Server, hinting at server-side state, but does not clarify whether the operation is read-only, whether it has lasting side effects, how errors or rate limits manifest, or what happens after execution. This is insufficient for a compound action that 'builds and executes' a pipeline.

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 compact at two sentences plus an example. The first sentence states the core purpose, the second adds the technical mechanism (Entrez History Server), and the example clarifies the intended query pattern. Every element earns its place with no redundancy or fluff.

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?

The tool is complex with a nested parameter structure, but the schema provides rich detail and the description gives one use case. However, the absence of any behavioral caveats (e.g., limits on number of steps, required authentication, or whether results are returned as IDs or summaries) makes it only partially complete. An output schema exists, so return format may be covered there, but broader execution expectations 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?

The input schema already provides 100% parameter coverage, including detailed descriptions for the 'steps' array and 'output_step'. The description adds an illustrative example that demonstrates how to combine search and link operations in the steps parameter, which reinforces the schema's abstract structure with a concrete scenario.

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 clearly states the tool's purpose: 'Build and execute a multi-step search pipeline.' This specifies a concrete action (build and execute) on a specific resource (multi-step search pipeline), and the example ('Find diabetes reviews, then limit to articles linked to HLA genes') distinguishes it from single-step sibling tools like pubmed_search or link_to_databases.

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 on when to use this tool: it is 'Ideal for complex queries' and mentions the efficiency gain from using the Entrez History Server. However, it does not explicitly state when not to use it or mention alternative simpler tools (e.g., pubmed_search for one-step searches), so it lacks 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context by mentioning the batch limit and the four supported ID formats. However, it says nothing about error handling, authentication, or return behavior. Given the tool is a simple read-only conversion, this is acceptable but not rich.

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 two sentences with a bullet list, immediately stating the tool's purpose and then elaborating on formats. Every line contributes to understanding, with no fluff or redundant repetition of schema details. It is excellently structured and easy to scan.

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 low complexity of this tool, the output schema exists, and the parameter schema is fully documented, the description covers the essential information. It lacks a note about how this tool relates to 'resolve_article_identifier', but that gap is more of a usage guideline issue. Overall, it is complete enough for an agent to select and invoke 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?

The input schema has 100% coverage, providing descriptions for all three parameters. The description adds value by giving concrete examples of each ID format (e.g., '37000000', 'PMC7611378'), which helps the agent format inputs correctly. This goes beyond the schema's terse parameter 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?

The description clearly states the tool converts article IDs between formats, using the specific verb 'convert' and identifying the resource (article IDs). It distinguishes itself from siblings by focusing on format conversion, but it doesn't explicitly differentiate from the similarly named 'resolve_article_identifier'.

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 provides context about batch conversion (up to 200 IDs) and the supported formats, which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives like 'resolve_article_identifier' for single-ID resolution. This is an implied usage scenario rather than explicit 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?

There are no annotations, so the description carries the full burden. It honestly describes the fetch/read nature and what data it returns, which implies minimal side effects. However, it does not disclose any operational details such as error behavior, potential rate limits, permissions, or behavior on invalid input. The absence of risky behavior (mutation) earns it a mid-range score.

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 consists of exactly two sentences with no redundant words. The primary action is front-loaded, and the second sentence efficiently lists the key output fields. 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?

The presence of an output schema means return values are already structurally covered, so the description need not explain them in detail. The description gives a solid overview of what the tool returns and implies its scope. It could be slightly more explicit about how this tool fits with siblings like fetch_full_article, but overall it is complete for the tool's simple fetch functionality.

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?

All three parameters (pmid, database, include_full_metadata) have complete schema descriptions, so the baseline is 3. The tool description does not add parameter-specific semantics beyond the schema, nor does it highlight any special parameter interactions or value formatting.

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 clearly identifies the tool as fetching 'detailed article summary and metadata' and enumerates the specific fields returned (title, authors, abstract, MeSH terms, journal details, DOI). This is a specific verb+resource and distinguishes it from search tools, but it does not explicitly compare against fetch_full_article, so sibling differentiation is only implicit.

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 the tool should be used when an article summary or metadata is needed, but it gives no explicit guidance about when not to use it or which alternative to choose (e.g., fetch_full_article for full text). There are no prerequisites, exclusions, or conditional scenarios mentioned.

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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It does so by explaining what BioC output contains (passage segmentation, sentence boundaries) and why it is suitable for NER/relation extraction. It does not discuss error cases or side effects, but for a simple read-only fetch tool, the description is reasonably transparent.

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 concise and front-loaded, with a clear imperative first sentence followed by a compact bullet list. Every line adds useful context about BioC features, with no redundant 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?

The tool has only three optional parameters, an output schema, and a clear purpose. The description complements the schema well by explaining the BioC format's value. However, it does not explicitly note that at least one of pmid or pmcid must be provided, which is a minor gap for an otherwise complete description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage with clear descriptions for pmid ('PubMed ID for abstract in BioC'), pmcid, and format. The description adds no additional parameter-level guidance, so the baseline of 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 description opens with 'Fetch article in BioC format for text mining,' which combines a specific verb, resource, and purpose. This clearly distinguishes it from sibling tools like fetch_article_summary or fetch_full_article by emphasizing the BioC format and NLP use case.

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 states 'BioC provides pre-parsed text ideal for NLP tasks' and lists segmentation/boundaries, giving clear context for when to use this tool. It does not explicitly name alternatives or state when not to use it, but the NLP framing effectively implies the appropriate use case.

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?

With no annotations, the description carries the full burden. It transparently discloses that PubMed does not return full text and that PMC full text is contingent on Open Access status. This covers key behavioral constraints, though it does not detail format-specific behavior or error cases.

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 concise and front-loaded with the main action, followed by necessary caveats. Two short sentences, no redundancy, every sentence provides essential 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?

Given the output schema exists and schema coverage is 100%, the description adequately covers the key decision points: which ID to use and what content to expect. It could mention relationship to siblings or error handling, but it is sufficiently complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds semantic value by pairing PMID/PMCID with expected content types and the Open Access caveat. The format parameter is not elaborated beyond schema, but the description elevates the parameters' practical meaning.

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 clearly states the tool fetches article content, with specific differentiation between PubMed (abstract and metadata only) and PMC (full text if Open Access). This distinguishes it from siblings like fetch_article_summary and fetch_bioc_article.

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 provides clear usage context by mapping PMID to PubMed (abstract) and PMCID to PMC (full text if OA). It does not explicitly name alternative tools or exclusion criteria, but the context is sufficient for selection.

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?

With no annotations, the description must explain behavior, but it only says 'find all publications.' This is misleading because the max_results parameter limits output, and the description omits details about response format, limits, or any side effects. It does not contradict annotations (there are none), but it provides very thin behavioral transparency.

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 a single sentence with no extraneous phrases. Every word contributes to conveying the core function, making it highly concise and well-structured for the purpose it serves.

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 complexity (4 parameters, sibling search tools, no annotations), the description is too minimal. While an output schema exists to explain return values, the description fails to provide guidance on usage context, result limits, or how it differs from other search tools, leaving an agent under-equipped for correct selection and 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?

The input schema already describes all four parameters with 100% coverage, including the meaning of author_name, max_results, and the date range parameters. The description adds no parameter-level semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool finds publications by an author, with a specific verb ('Find') and resource ('publications', though the tool name says 'citations'). It does not explicitly differentiate from sibling tools like pubmed_search or advanced_search, but the author-specific scope makes its purpose distinct.

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 the tool should be used when you need publications by a specific author, but it provides no explicit guidance on when to use this tool versus the many search-oriented siblings (pubmed_search, pmc_search, etc.). There are no exclusions or direct comparisons.

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?

With no annotations, the description must disclose behavioral traits, but it only mentions high-level methods (citation networks, computational similarity). It does not indicate read-only behavior, potential rate limits, result ordering, or how relationship_type affects behavior beyond the schema. This leaves significant room for unexpected behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with the primary purpose front-loaded. The second sentence adds relevant context about the discovery mechanism. There is no redundant or extraneous 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?

The tool is relatively simple with an output schema, but the description lacks guidance on relationship types (similar, cited_by, cites) and when to use each. It also does not clarify typical use cases or constraints. The schema partially compensates, but the description alone is not fully contextually 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 100%, so the schema already explains 'pmid', 'max_results', and 'relationship_type'. The description adds minimal parameter-specific meaning, only hinting at the similarity/citation mechanism. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: finding articles related to a source article. It specifies the resource (source article) and the mechanism (citation networks and computational similarity), which differentiates it from generic search tools like 'pubmed_search' or 'global_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?

The description implies usage when you have a source article and want related literature, but it does not explicitly state when to use this tool over alternatives. No exclusions or alternative tool recommendations are provided, leaving the agent to infer context from the name and schema.

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?

With no annotations, the description carries the behavioral burden and does well by disclosing that it returns hit counts rather than full records, and that it covers 38+ databases. It does not mention rate limits or query syntax, but the core behavior is clearly stated.

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 exactly two sentences, front-loaded with the action, and every clause earns its place. No filler or 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?

Given the tool's simplicity, full schema coverage, and the presence of an output schema, the description provides enough context. It explains what the tool does, what it returns (hit counts), and why it's useful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds the 'all databases' scope but does not add extra meaning beyond the schema's own parameter descriptions for 'query' and 'databases'.

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

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

The description names a specific verb ('Search') and resource ('all NCBI databases'), clearly differentiating it from siblings like pubmed_search or pmc_search that target specific databases. It also states the tool returns hit counts, which clarifies its scope.

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 provides clear context: use this tool to discover data availability across databases, which implies a discovery/overview use case. It does not explicitly name alternatives or when-not-to-use, so it misses the top bar for explicit exclusions.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states what the tool does (finds linked records) without describing any constraints, side effects, return characteristics, or potential limitations such as pagination or database availability. This is a significant gap for a tool that accesses external databases, as the agent cannot anticipate whether the operation is read-only or if any parameters are ignored.

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 extremely concise, consisting of two short sentences that immediately communicate the core function. Every word adds value, with no redundancy or filler. This is an example of efficient, front-loaded writing.

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 simplicity and the fact that an output schema exists (so return values need not be explained), the description is minimally adequate. However, it lacks usage guidance and behavioral transparency, which prevents it from being fully complete. For a simple look-up tool, this is sufficient but not exemplary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% description coverage for both parameters, with clear explanations for 'pmid' and the list of possible 'target_databases' values. The description itself adds no additional semantic detail beyond the schema, but the schema is self-sufficient, so a baseline score of 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 description clearly states the tool's function: 'Find records in other NCBI databases linked to an article.' This specifies a verb and resource, and the second sentence 'Maps from literature to biological knowledge bases' further clarifies the purpose. It distinguishes from sibling tools focused on fetching articles or searching, as this unique cross-linking capability is not offered elsewhere.

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 context ('Maps from literature to biological knowledge bases') but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. There is no mention of when not to use it or what other tools might be better suited, leaving the agent to infer the appropriate scenario from the sibling names.

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?

No annotations are present, so the description must convey behavioral traits. It only mentions the hierarchical nature of MeSH, hinting at hierarchical expansion but not disclosing default behaviors like explode=true, qualifier handling, or date-range filtering. The description does not mention output format, pagination, or any side effects.

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 brief and front-loads the core purpose in the first sentence. The second paragraph adds useful background on MeSH but could be integrated or shortened; overall it remains concise and readable.

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 has 7 parameters and no annotations, the description is insufficiently complete. It fails to specify the searchable database, result types, or any limitations. The presence of an output schema partially compensates, but the description lacks critical contextual information for an agent to confidently select and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers most parameters with descriptions (71% coverage), so the baseline is 3. The description adds no direct parameter details, though the hierarchical indexing note contextualizes search_mode and explode. This does not raise the score above the schema baseline.

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 clearly states the action ('Search') and the resource ('MeSH controlled vocabulary terms'), which distinguishes it from general search tools like global_search or pubmed_search. However, it does not specify the underlying corpus being searched (e.g., PubMed vs PMC), leaving some ambiguity.

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 that MeSH is valuable for standardized retrieval across different terminologies, but does not explicitly state when to choose this tool over alternatives. No exclusions or alternative tool mentions are provided, making the usage context implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It states that the tool 'Searches 7M+ full-text articles in PubMed Central' and emphasizes the full-text nature, which is useful. But it does not disclose potential side effects, rate limits, pagination behavior, or whether results are restricted to open access—information that could matter to an agent. It does make the core behavior clear, so it is not a 2.

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 two sentences long, with the main action front-loaded: 'Search PMC for full-text articles.' The second sentence provides a crucial clarifying contrast with PubMed. There is zero wasted wording, making it exceptionally concise and well-structured.

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 search tool, the description is complete enough: it identifies the resource, distinguishes from PubMed, and the output schema covers return values. It does not elaborate on result formatting or special behaviors, but the output schema and parameter schema fill those gaps. The only minor omission is lack of any mention of access limitations beyond full-text availability, but this is not critical. Overall, it is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage of all five parameters, each with a description, so the baseline is 3. The description does not add any parameter-level meaning; it only provides high-level context about the search scope. Since schema already documents parameters fully, the description adds no additional semantic value beyond that baseline.

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 clearly states the tool's function: 'Search PMC for full-text articles.' It uses a specific verb and resource, and explicitly distinguishes itself from PubMed: 'Unlike PubMed (abstracts only), PMC searches the complete article text.' This effectively differentiates the tool from the sibling 'pubmed_search' and makes its purpose 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 provides clear context for when to use the tool: when full-text article search is needed. It names PubMed as an alternative and contrasts them ('Unlike PubMed (abstracts only)...'), giving explicit guidance about choosing PMC over PubMed. However, it does not mention when not to use the tool or discuss other sibling alternatives, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the burden. It discloses the search scope (34M+ PubMed abstracts), query syntax flexibility, and return content (metadata including abstract and MeSH terms). This adds meaningful behavioral context beyond the schema, though it omits details like rate limits or pagination.

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 extremely concise: two short sentences plus a one-liner about return content. Every sentence provides distinct value, and the core purpose is front-loaded in the first sentence.

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 search tool with an output schema and full parameter documentation, the description is sufficient. It clearly states what it does, what it searches, and what it returns. It lacks explicit alternative guidance, but that is covered under usage guidelines. Overall, complete enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining that the query can be natural language or E-utilities syntax, which goes beyond the schema's examples. It also notes return fields like MeSH terms, aiding expectation of parameter impact.

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 clearly states the tool 'Search PubMed for biomedical literature', which is a specific verb+resource. It distinguishes from siblings like pmc_search by explicitly naming PubMed, but does not explicitly differentiate from other search tools like advanced_search or global_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?

The description provides clear context that this tool is for searching biomedical literature. It mentions support for natural language or E-utilities syntax, implying flexible usage, but does not explicitly state when not to use it or suggest alternative tools.

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?

With no annotations, the description must fully explain behavior. It transparently states that the tool auto-detects the ID type and returns all identifiers, but it does not disclose what happens on invalid input, whether auto_detect_type=false changes behavior, or any error handling details.

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 two short sentences, front-loads the core purpose, and contains no filler. Every word adds 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?

For a simple identifier resolution tool with an output schema present, the description adequately covers the main functionality. However, it lacks any mention of error handling or limitations, and the presence of the similar 'convert_article_ids' sibling suggests a bit more context would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents both parameters with descriptions and 100% coverage. The description adds no significant meaning beyond the schema, though it does reinforce the auto-detection behavior tied to auto_detect_type. This matches the baseline for full schema coverage.

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

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

The description clearly states the tool resolves a single identifier to all available ID formats, using a specific verb and resource. However, it does not explicitly distinguish itself from the similar sibling tool 'convert_article_ids', 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?

The description implies usage when you have a single identifier and need all available ID formats, but it provides no context on when to use this tool instead of alternatives like batch_fetch_articles or convert_article_ids, and no exclusions are mentioned.

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