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

The description discloses that the tool downloads a PDF and returns the file path, and includes an example. However, it does not mention error handling (e.g., if paper not found), whether files are overwritten, or any internet requirement. With no annotations, the description carries the full burden and could be more 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 well-structured: a single sentence for purpose, followed by clear parameter documentation, return type, and an example. No unnecessary 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 tool's simplicity and the absence of annotations or output schema, the description covers the main functionality. However, it could be slightly more complete by mentioning what happens when the paper is not available or when save_path is not provided.

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 description adds meaningful detail beyond the schema titles: it explains the format for paper_id and the default and purpose of save_path. Since schema description coverage is 0%, this is valuable.

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 action ('Download PDF from arXiv') and includes a helpful note about arXiv being free and available. It effectively distinguishes from sibling tools that download from other sources.

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 arXiv papers but does not provide explicit guidance on when to use this tool over sibling download tools for other sources. No exclusions or alternative recommendations are given.

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 fully disclose behavioral traits. It mentions 'free and open access' but omits critical details like error handling on invalid DOIs, rate limits, or confirmation that the operation is read-only and idempotent. The return value is only generically described as 'Path to downloaded PDF'.

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 and well-structured: a one-line purpose, followed by clearly labeled Args and Returns sections. No unnecessary words or repetitions.

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 simplicity of the tool (2 params, no output schema), the description covers the essentials: purpose, parameters, and return value. However, it lacks context on error scenarios, authentication needs, or network requirements, which would be helpful for reliable agent usage.

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 0% schema coverage, the description compensates by naming both parameters and providing a concrete DOI example for paper_id. For save_path, it clarifies it as 'Directory to save PDF'. This adds meaningful guidance beyond the schema, though an example path format would further improve usability.

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 'Download PDF from bioRxiv (free and open access)', identifying the action (download), resource (PDF), and source (bioRxiv). The DOI example further specifies the target, distinguishing it from sibling download tools for other repositories.

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 downloading bioRxiv PDFs but provides no explicit guidance on when to choose this tool over alternatives (e.g., read_biorxiv_paper) or when not to use it. No exclusions or context about prerequisites are given.

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 fully carries the burden of behavioral disclosure. It transparently states the tool does not download PDFs, returns an error message, and that save_path is unused. This is comprehensive for a tool whose main function is to redirect users.

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, well-structured with clear sections (bolded headings for what CrossRef does not do, what it is, and a numbered list of alternatives). Every sentence adds value, and the use of all caps for key points aids readability without being wasteful.

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 (it is a 'negative' tool that doesn't perform its apparent function), the description is fully complete. It explains what it does, what it doesn't, and provides a clear fallback strategy. No output schema is needed because the return is an error message, which is sufficiently described.

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. It adds meaning for both parameters: paper_id is a DOI, and save_path is explicitly indicated as unused. However, it could elaborate on the DOI format or save_path expected type (though it's unused). Still, it provides essential context 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 clearly states that CrossRef does not support direct PDF downloads and that the tool's purpose is to return an error message explaining alternatives. It distinguishes itself from sibling download tools by explicitly stating it is not for downloading.

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 explicit usage guidance: when to use this tool (never for actual downloading) and when to use alternatives (download_arxiv, download_scihub, download_semantic) in a recommended order. It also explains that save_path is unused, preventing misconfiguration.

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?

Despite no annotations, the description notes 'always free' and alludes to saving to disk. However, it does not disclose potential behaviors like overwriting existing files, required permissions, or error 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 description is brief and front-loaded, with a separate args/returns/example section. It is efficient but could benefit from a more structured format like bullet points.

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 no output schema, the description includes return type. However, it lacks details on file naming behavior, overwriting policy, or error scenarios, which are important for completeness.

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 0% schema description coverage, the description compensates by explaining the 'paper_id' format with an example ('2024/123') and clarifying that 'save_path' is a directory for saving. This adds meaning 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 it downloads PDF from IACR ePrint, distinguishing it from other download tools. The phrase 'always free' adds useful context.

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 example usage but lacks explicit guidance on when to use this tool versus other download tools (e.g., download_arxiv). No mention of 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?

With no annotations provided, the description must fully convey behavioral traits. It states the return value (path to downloaded PDF) but omits potential failure modes, authentication needs, or side effects. The description is adequate but lacks depth for a tool with no annotations.

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

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

The description is concise, starting with the core purpose, then listing arguments in a clear format, and finally stating the return value. Every sentence serves a purpose with no 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?

For a simple download tool with no output schema and minimal schema coverage, the description covers the main inputs and output. It does not explain error handling or edge cases, but for its intended use, it is sufficiently complete. Slight improvement could be made by noting required parameters.

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?

Given 0% schema coverage, the description compensates well by explaining paper_id as a medRxiv DOI with an example and save_path as a directory to save PDF. This adds meaningful context beyond the schema's type definitions, though the optional nature of save_path is not explicitly clarified.

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 'Download PDF from medRxiv' which identifies the specific verb (download) and resource (PDF from medRxiv). It also notes it's free and open access, distinguishing it from potentially paywalled sources among sibling tools like download_pubmed.

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 when to use (when needing to download a PDF from medRxiv) and gives an example DOI format, but does not explicitly state when not to use or mention alternative tools like read_medrxiv_paper for viewing abstracts. Usage context is implicit.

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?

Fully discloses tool behavior: returns error message, arguments are unused. No annotations provided, but description compensates completely.

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?

Concise with clear structure using bullet points and emphasis. Front-loaded with key message. Minor improvement possible for readability.

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?

Complete for a tool that does nothing but return an error. Describes return value and alternatives. No output schema needed.

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?

Adds meaning beyond schema: paper_id is PMID (unused), save_path is unused. Compensates for 0% 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?

Clearly states PubMed does not support PDF downloads and that the tool returns an error message with alternatives. Distinguishes from siblings by naming alternative 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?

Explicitly instructs when to use this tool (actually when not to) and provides ordered alternatives: download_scihub and download_semantic.

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?

The description fully discloses that the parameters are unused and that the tool returns an error message with alternatives. Since no annotations are provided, the description carries the entire burden and does so transparently.

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 a clear note, an ordered list of alternatives, an args section, and a returns section. Every sentence adds value without 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 that this tool does not perform a real download, the description completely covers its behavior, limitations, and alternatives. No output schema exists, but the return value is described sufficiently.

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?

Despite 0% schema description coverage, the description adds crucial meaning: both parameters are explicitly stated as unused. This is vital for the agent to understand that the tool ignores its 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 clearly states that the tool does not directly download PDFs because RePEc is a metadata index. It explicitly mentions the verb 'download' and the resource 'RePEc', and distinguishes itself from siblings like download_arxiv by explaining the limitation.

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 explicit alternatives ordered by priority: first visiting the paper URL, then using download_scihub. It tells the agent exactly when to use this tool (to get alternatives) and when to use others, which is perfect 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?

No annotations are provided, so the description carries full burden. It discloses the age limitation (pre-2023) and that it's for paywalled papers not on arXiv. However, it does not mention potential issues like regional blocks or download success rates, which would be useful for an agent. Still, the disclosed constraints are valuable.

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 sections for purpose, usage guidelines, args, returns, and example. It is concise yet comprehensive, with no unnecessary words. Every sentence 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?

Given the tool's complexity (simple download with two parameters), no output schema, and rich sibling set, the description covers all necessary aspects: what it does, when to use, parameters, return value, and example. The workflow integration with search_crossref adds completeness.

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 add meaning. It explains the 'doi' parameter with examples and format, and 'save_path' with default value and purpose. This fully compensates for the absent 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?

The description clearly states the tool's purpose: 'Download paper PDF via Sci-Hub using DOI (for older papers only).' It specifies the resource (paper PDF), action (download), and constraint (older papers only), distinguishing it from sibling tools that cover different sources or paper ages.

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 explicit guidelines: use when you have a DOI, paper is before 2023, behind a paywall and not on arXiv, and after searching CrossRef. It also outlines a workflow: search_crossref -> get DOI -> download_scihub. This clearly differentiates from 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?

With no annotations, the description fully carries the burden, disclosing it is open-access only, may not have PDF, and explaining the paper_id prefix formats. It also notes return type ('Path to downloaded PDF, or error').

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-structured with priority list, parameter descriptions, and return info. Slightly verbose with 'DOWNLOAD PRIORITY' header but each sentence 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?

Given no output schema, description explains return value and error case. Covers complexity with ID formats and priority logic adequately.

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 description compensates by explaining paper_id format (prefixed options like DOI, ARXIV, PMID) and save_path as directory. However, save_path could clarify if optional or 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 clearly states it downloads PDFs via Semantic Scholar, specifies open-access only, and positions it as a last resort. It distinguishes from siblings by providing a prioritized download order with specific tool names.

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 explicitly provides a download priority list with alternatives (download_arxiv, download_scihub) and explains when to use this tool as last resort. This is comprehensive 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?

No annotations provided. Description mentions return format (dict or empty dict) and citation count, but lacks info on rate limits, authentication, or error 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?

Well-structured with summary, usage conditions, args, returns, and example. No unnecessary sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but describes return type. Includes example. For a simple lookup with one parameter, sufficiently 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?

Adds meaning beyond schema by giving parameter description and example DOI format. Schema coverage is 0%, so description compensates well.

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?

Clearly states 'Get paper metadata from CrossRef using its DOI.' Distinguishes from sibling tools like search_crossref and download_crossref.

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 THIS TOOL WHEN' section with three scenarios. Does not explicitly name alternative tools but implies when not to use.

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?

Despite having no annotations, the description thoroughly explains the tool's behavior: it fetches metadata from an IDEAS paper detail page and returns structured information. It does not mention rate limits, authentication, or potential side effects, but for a read-only scraping tool, the description is sufficiently 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 well-structured with clear headings and bullet points, making it easy to scan. Every section (purpose, usage, args, returns, example) is concise and informative, with no unnecessary words.

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 description covers all necessary aspects: purpose, input format, return values (including a detailed list of fields), and a concrete example. Without an output schema, it fully explains what the tool returns, making it contextually complete 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?

The input schema only provides title and type for the single parameter with 0% coverage. The description compensates exceptionally well by providing multiple examples of valid inputs (both URL and RePEc handle) and explaining the expected format, adding significant meaning 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 that the tool gets detailed paper information from RePEc/IDEAS, specifying that it fetches complete metadata including abstract, authors, keywords, and JEL codes that may be missing from search results. This distinguishes it from sibling tools like search_repec, although it does not differentiate from the similarly named read_repec_paper.

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 a 'USE THIS WHEN' section with three explicit scenarios: when you have a URL/handle from search results and need the abstract, when you want complete author information, and when you need JEL codes. While it does not explicitly state when not to use it or name alternatives, the guidance is clear and contextually appropriate.

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?

The description discloses that it downloads from arXiv, saves a PDF, and returns Markdown text. However, with no annotations, it does not mention potential side effects like network access, file overwriting, or error handling beyond the provided example.

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, well-structured with Args, Returns, and Example sections, and every sentence adds value. It is front-loaded with the main purpose.

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 retrieval tool with no output schema and no annotations, the description covers the basics but lacks guidance on when to use this tool over siblings and does not mention any limitations like rate limits or paper size constraints.

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?

Despite 0% schema description coverage, the description adds meaning by explaining paper_id with an example format and save_path as a directory with a default value. It lacks clarity on save_path's exact usage (directory vs. full path) but is otherwise helpful.

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 verb (download and extract), resource (arXiv paper), and output (Markdown). It distinguishes itself from sibling tools by naming 'arXiv' but does not explicitly state when to prefer this over similar tools like read_biorxiv_paper.

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 is provided on when to use this tool versus its siblings (e.g., download_arxiv, search_arxiv). The description lacks any context about prerequisites or appropriate use cases.

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?

Discloses side effect of saving PDF to directory and return format (Markdown). But no annotations exist; description doesn't mention read-only nature, error handling, or network usage.

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?

Concise with three lines plus structured Args/Returns. No unnecessary words, front-loaded with main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param tool with no output schema or annotations, the description covers inputs, output format, and side effects. Lacks error handling and differentiation from siblings, but overall sufficient.

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?

Adds meaning to both parameters: paper_id is DOI, save_path is save directory. This compensates for 0% schema coverage. However, optionality of save_path is not clarified.

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 verb 'download and extract' and the resource 'bioRxiv paper'. However, it does not distinguish from siblings like 'download_biorxiv' (which might only download PDF) or other read_* tools, missing specificity.

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 tool over siblings (e.g., download_biorxiv, read_arxiv_paper). Lacks context on 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?

Discloses that the tool returns an error message explaining alternatives, and notes that save_path is unused, providing full behavioral transparency despite no 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 key limitation, followed by structured alternatives list, parameter explanation, and return description. Every sentence adds value without 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?

Covers purpose, limitations, alternatives, parameters, and return behavior completely for a tool that returns an error. No output schema needed.

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?

Adds crucial meaning beyond schema: explains paper_id as DOI with example, and clarifies save_path is unused, compensating for 0% schema description 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?

Description explicitly states that the tool does not support direct paper reading, only metadata, which clearly distinguishes it from sibling tools like read_arxiv_paper and read_scihub_paper.

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 instructions for alternatives in a numbered list, telling the agent when not to use this tool and what to use instead.

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 full burden. It mentions downloading and extracting, and returns Markdown, but does not disclose side effects like temporary file deletion, caching, authentication needs, or error handling for missing papers.

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 with a single purpose sentence followed by structured Args, Returns, and Example sections. It is front-loaded and efficient, though the Args section could be slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return format (Markdown). However, it omits information about network dependency, error handling, and idempotency. For a simple read tool, it is marginally adequate but not 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 coverage is 0%, so the description compensates by providing format examples (e.g., '2024/123' for paper_id) and clarifying save_path as a directory. This adds significant meaning beyond the schema's minimal titles.

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 downloads and extracts full text from IACR papers. It distinguishes from sibling tools like download_iacr by specifying 'extract full text' and returning Markdown format.

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 is provided on when to use this tool vs alternatives like read_arxiv_paper or download_iacr. The description lacks explicit when-to-use or when-not-to-use statements.

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 behavioral disclosure. It mentions downloading and extracting but does not indicate whether the operation is read-only, idempotent, or requires internet access. The side effect of saving a PDF (via save_path) is implied but not explained in terms of local modification.

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, using a clear Args/Returns structure that is well-organized and front-loaded. Every sentence provides essential information without 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?

For a simple tool with two parameters and no output schema, the description covers the core purpose and parameters. However, it lacks usage context, behavioral details, and error handling information. It is minimally viable but has clear gaps given the absence of annotations.

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 coverage is 0%, but the description adds meaningful context: it specifies that paper_id is a medRxiv DOI and save_path is a directory for saving the PDF. This adds value over the bare schema titles. However, the optionality and default behavior of save_path are not clarified.

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 downloads and extracts full text from medRxiv papers, with a specific verb and resource. It distinguishes from sibling tools like download_medrxiv (which likely only downloads PDF) by explicitly including extraction to Markdown.

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 is provided on when to use this tool versus alternatives such as download_medrxiv or other read_* tools. There is no mention of prerequisites, context, or conditions that would help an agent decide to use this 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?

No annotations provided, but the description fully discloses behavioral traits: parameters are unused, tool returns an error message. No contradictions.

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?

Very concise: three short paragraphs covering inability, alternatives, parameter descriptions, and return value. No extraneous 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 tool's simple nature (error returner with no output schema), the description is complete. It explains purpose, usage, parameters, and return value adequately.

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%, but the description compensates by explaining that paper_id is an unused PMID and save_path is unused. Adds meaning beyond the schema's type definitions.

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 explicitly states that PubMed does not support direct paper reading, and the tool's purpose is to return an error message with alternatives. It clearly distinguishes from siblings by naming specific alternatives (read_scihub_paper, read_semantic_paper).

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 (PubMed doesn't support) and when-not-to-use (use alternatives instead). Offers a ranked list of alternatives with conditions, guiding the agent effectively.

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?

The description transparently discloses that the tool does not read a paper and returns an error message with alternatives, fully explaining its behavior without any annotations.

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

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

The description is extremely concise, well-structured with a clear title, alternatives list, and parameter notes. Every sentence provides essential information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that solely returns an error with alternatives, the description is completely informative. No output schema is needed as the behavior is fully described.

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 description states that both parameters are unused, which adds meaning beyond the input schema (which has 0% description coverage). This clarifies that the tool ignores its arguments.

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 that the tool does not support direct paper reading, and its purpose is to return an error with alternatives. It distinguishes itself from siblings like read_scihub_paper.

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 explicitly provides an ordered list of alternatives to use instead of this tool, giving clear when-to-use and when-not-to-use 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?

Describes the download and text extraction process, output format (Markdown with metadata), and error handling. No annotations, but description covers key behavioral aspects without contradiction.

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-structured with sections for use, workflow, args, returns, and example. Every sentence is informative, no 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?

Complete coverage for a tool with 2 parameters and no output schema: purpose, usage guidelines, parameters, return format, and example workflow.

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?

Despite 0% schema description coverage, the description explains parameters: doi with example, save_path with default. Adds meaning beyond raw 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 specifies 'Download and extract full text from paper via Sci-Hub (older papers only)', providing a specific verb and resource. It distinguishes from siblings by mentioning Sci-Hub and date restriction.

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 lists 'USE THIS TOOL WHEN' conditions: need full text, paper before 2023, want to analyze. Includes workflow referencing search_crossref, guiding proper 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?

No annotations provided, so description carries full burden. It notes open-access only and returns Markdown text, but lacks details on failure modes, rate limits, or why it's a last resort beyond a simple statement.

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-structured with clear sections (DOWNLOAD PRIORITY, Args, Returns). Purpose is front-loaded. One small efficiency: the priority list is slightly verbose but essential for guidance.

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 no annotations and no output schema, the description covers purpose, priority rule, arguments, and return format. It's sufficient for an agent to decide when to use and how to call, though more on fallback behavior would improve completeness.

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 description must compensate. The Args section explains paper_id accepts various prefixed IDs and save_path for directory, but doesn't elaborate on formats or behavior when save_path is null.

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 reads a paper via Semantic Scholar and is open-access only. It distinguishes from siblings by providing a download priority list that names alternative tools and conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'use as LAST RESORT' and gives a prioritized list with specific conditions (arXiv vs. pre-2023), telling the agent exactly when to use this tool versus 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?

With no annotations, the description carries the burden. It discloses that arXiv contains preprints not yet peer-reviewed, and implies PDF availability via download_arxiv. It does not mention rate limits or auth, but adds value beyond 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?

Well-structured with sections, concise sentences, and an example. Every part adds value without 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?

Covers purpose, conditions, workflow, parameters, and return structure. Lacks mention of sorting or pagination, but given the tool's simplicity, it is mostly 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 0%, so description compensates by describing query as 'Search terms in any supported field' and max_results as 'Number of results (default: 10)', plus an example. It could be more detailed on query syntax, but adequate.

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 it searches preprints on arXiv, a major open-access preprint server. It distinguishes from sibling search tools by specifying the content type and referencing the workflow with related 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?

Explicitly lists when to use this tool (searching for preprints, need free full-text, specific fields) and when not to (peer-reviewed papers, directing to search_crossref or search_semantic). Provides clear 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?

No annotations provided, so description carries full burden. It discloses the category-based query behavior and that results are 'recent preprints' but does not mention rate limits, pagination, or whether the tool is read-only. Does not contradict any 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?

Well-structured with USE THIS, DOMAIN, NOTE, WORKFLOW sections. The example and category list add value. Could be slightly tightened (e.g., reduce redundant phrases) but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations or output schema, the description covers purpose, usage, parameter semantics, and integration with sibling tools. It lacks detail on return format and behavioral traits like rate limits, but is largely complete for a search 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 coverage is 0%, but description adds thorough semantics: explains that query is a category name, provides a list of common categories, sets default for max_results, and includes an example. This compensates fully for the lack of 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?

The description specifies 'Search biology preprints on bioRxiv', naming the resource and domain. It distinguishes from sibling search tools like search_arxiv or search_pubmed by focusing on bioRxiv, and notes category-based 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 states when to use ('cutting-edge biology research', 'latest findings'), and critically highlights that search is by CATEGORY not keyword. Provides a workflow linking to sibling tools and lists example categories.

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 burden. It mentions indexing 150M+ works and typical result fields. However, it does not disclose any behavioral traits such as rate limits, authentication requirements, or potential missing data (e.g., abstracts). For a read-only search tool, the transparency is adequate but could be more thorough.

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-organized with a main purpose, usage list, additional context, parameter details, and an example. It is front-loaded and each section adds value. Could trim the example slightly, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 0% schema coverage, the description provides robust context: database size, result fields, parameter usage, and an example. It explains the return format (list of dicts) and key fields. This is sufficient for an agent to understand 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?

Schema coverage is 0%, so description must compensate. It explains 'query' and 'max_results' with examples and default/max values. However, 'kwargs' is described as optional filters with examples (filter, sort, order), but the schema defines it as a required string. This mismatch may confuse agents. The description adds value but introduces potential misinterpretation.

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 searches academic papers in CrossRef, distinguishing it from siblings that target specific repositories (e.g., search_arxiv, search_pubmed). It uses specific verbs like 'search', 'find', 'verify', and explicitly mentions CrossRef as the largest DOI citation database, covering all publishers not just preprints.

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 THIS TOOL WHEN' section provides explicit scenarios: finding papers by DOI, searching across publishers, getting metadata, verifying DOIs. It implies alternatives exist (e.g., preprint-specific searches) but does not explicitly state when not to use it. This is clear guidance though slightly incomplete.

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 reveals web scraping usage, rate-limiting risks, and absence of PDF support. However, it lacks details on exact rate limits or error behavior on blocks.

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-organized with sections, bullet points, and an example. Every sentence adds value without 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 no output schema, the description details the return structure (list of dicts with specific fields) and includes an example. It also covers usage, limitations, and alternatives, making it highly complete for a search tool with two parameters.

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%, but the description gives meaningful explanations for both parameters: 'query' as any academic topic, and 'max_results' with advice to keep small. This fully compensates for the schema gap.

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 searches academic papers on Google Scholar with broad coverage, distinguishing it from specialized sibling search tools like search_arxiv or search_pubmed.

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 includes a dedicated 'USE THIS TOOL WHEN' section with three explicit criteria, provides limitations (rate limiting, no PDF download), and suggests alternative tools for full-text access in order.

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 discloses that papers are free, open access, and outlines the workflow (search then download/read). It does not mention rate limits or authentication, but it is reasonably transparent for a search tool.

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 sections for purpose, usage, domain, workflow, args, returns, and example. Every sentence adds value, and the critical information is 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 no output schema, the description details the return format (list of dicts with fields). It also connects to sibling tools via workflow, making the tool's role in a larger process clear.

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?

Despite 0% schema description coverage, the description explains each parameter (query, max_results, fetch_details) with examples and defaults, fully compensating for the lacking schema metadata.

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 searches cryptography papers on IACR ePrint Archive, with a specific verb and resource. It distinguishes from sibling tools by explicitly limiting domain to cryptography.

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 THIS TOOL WHEN' section explicitly lists when to use, and the 'DOMAIN: Cryptography ONLY' provides a clear exclusion. However, it does not explicitly mention alternative sibling tools like search_semantic or search_arxiv for non-cryptography needs.

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

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

No annotations exist, so the description must disclose behavioral details. It mentions that results are 'recent' and provides a workflow, but does not state whether the operation is read-only, what happens on error, or any rate limits. The description is adequate but not thorough.

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 (summary, usage, domain, workflow, args, returns, example). While slightly verbose, it front-loads essential information and earns its length through clarity.

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 description explains purpose and usage adequately for a simple tool, but it lacks details on the return structure (e.g., fields in the list) and error handling. Given no output schema, more specificity would improve completeness.

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 coverage is 0%, so the description fully carries the burden. It adds concrete examples of category names and explains that 'query' is a category name, not a keyword, which significantly aids understanding 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 clearly states it searches medical preprints on medRxiv and specifies the domain and categorical search mechanism, which distinguishes it from sibling tools like search_arxiv or search_pubmed.

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 lists when to use (for clinical/medical research, latest studies) and implies when not to (by category, not keyword). The workflow and domain list provide additional context, though it stops short of naming alternative tools for keyword searches.

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 fully discloses behavioral traits: limitation to metadata/abstracts, a suggested workflow for full text, and the return format (list of paper dicts with specific fields). It is transparent about what the tool does and does not do.

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-organized with sections (USE THIS TOOL WHEN, DOMAIN, LIMITATION, WORKFLOW) and bullet points. Every sentence provides essential information 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?

Given the tool has 2 parameters, no output schema, and no annotations, the description is highly complete. It covers purpose, usage guidelines, limitations, workflow integration, parameter details, return format, and an example. No gaps remain for an agent to select and 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 0%, so the description must compensate. It explains the query parameter with examples (e.g., 'cancer immunotherapy') and specifies max_results as number of results with default 10. An example usage is also provided, adding clarity 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 it searches biomedical literature on PubMed, specifies the database, and includes domain fields. It distinguishes from siblings like search_arxiv and search_medrxiv by naming PubMed and biomedical focus.

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 THIS TOOL WHEN' section explicitly lists appropriate use cases (medical research, peer-reviewed papers) and includes a limitation (metadata only) and a workflow for full text using download_scihub. This provides clear when-to-use and when-not-to-use 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?

No annotations provided, so description carries full burden. Discloses limitation 'RePEc provides metadata only, not full PDFs.' Describes search syntax and coverage but does not mention authentication or rate limits. Honest about return type.

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-structured with sections (USE THIS TOOL, COVERAGE, SEARCH SYNTAX, LIMITATION, Args, Returns, Example). Front-loaded with purpose. Slightly verbose but each section 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?

Given 8 parameters (0% schema coverage), no output schema, and no annotations, the description is remarkably complete. Covers all parameters, return format, and usage examples. No gaps for an agent to infer.

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 description compensates fully. Provides detailed parameter descriptions, defaults, enum-like options for search_field, sort_by, doc_type, and series. Even includes example calls.

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?

Description clearly states it searches economics papers on RePEc/IDEAS. Lists specific coverage (NBER, Fed, World Bank, top journals) and distinguishes from sibling tools (e.g., search_arxiv, search_pubmed) by discipline focus.

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?

Has an explicit 'USE THIS TOOL WHEN' section listing four conditions (economics research, working papers, JEL classification, policy analysis). Does not explicitly state when not to use, but sibling tool names imply alternatives for other fields.

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 full burden. It conveys read-only search behavior implicitly through 'Search papers' and return format. It lacks explicit statements about safety (e.g., no side effects) but is clear enough. Adding 'This tool does not modify any data' would justify a 5.

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

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

The description is well-structured with headers (USE THIS TOOL WHEN, COVERAGE, WORKFLOW, Args, Returns, Example). It is front-loaded with purpose, each section is concise and value-adding, with no redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 params, no output schema, and many sibling tools, the description covers purpose, usage guidance, parameters with examples, return format, and integration workflow. It is complete enough for an agent to select and use 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 fully. It explains 'query' as 'any topic, any field', 'year' with format examples like '2020-2023', and 'max_results' with default value. This adds crucial meaning beyond the bare schema types.

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 explicitly states 'Search papers on Semantic Scholar - general-purpose academic search engine.' It contrasts with sibling tools by emphasizing cross-discipline coverage ('ALL academic fields'), distinguishing it from domain-specific searches like search_arxiv or search_pubmed.

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 THIS TOOL WHEN' section lists specific use cases (cross-discipline search, citation metrics, year filtering, open-access PDFs). It also provides a workflow linking to download_semantic and download_scihub, giving clear decision criteria versus sibling download tools.

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