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

Despite lacking annotations, the description transparently discloses the specific outputs (mean, median, max, counts of highly cited papers), which is the core behavioral context. It does not mention side effects, but this is a read operation by nature, and the description covers the essential 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 sentences, front-loaded with the primary 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?

With one parameter, an output schema, and a clear description of the computed statistics, the tool is sufficiently specified. The description doesn't explain edge cases, but the presence of an output schema and the simplicity of the operation make it complete enough.

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 fully documents the single 'name' parameter as 'Cache name' (100% coverage). The description adds no additional parameter semantics beyond what the schema provides, so the 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 uses a specific verb 'Get' and identifies the resource as 'citation statistics for cached papers'. It clearly distinguishes from sibling tools like cache_top_cited (which lists papers) and cache_stats (which likely provides general cache stats).

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 aggregated citation statistics are needed, but does not explicitly contrast with alternatives like cache_top_cited or cache_stats. The context is clear from the name and description, but no when-not-to-use guidance is provided.

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 the two main behaviors: fetching full metadata and saving to disk cache. It also implies the mutating nature via 'Create.' Yet with no annotations, it does not mention potential side effects like overwriting an existing cache by the same name, network dependency, or rate limits, limiting transparency to a mid-range.

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

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

Three short sentences, each with a distinct purpose: the tool's action, the mechanism, and the usage recommendation. No filler or redundant details.

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 the output schema exists, return values need no explanation. The description covers the creation flow, the source of data (query), and the destination (disk cache). It could mention overwrite behavior or resource implications, but for a moderate 3-param tool, it's reasonably 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 baseline is 3. The description does not add any per-parameter meaning beyond the schema; it merely restates the 'search query' concept and 'paper cache' concept. No additional semantics for 'name' or 'limit' are provided.

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 'Create a paper cache from search query', a specific verb+resource statement. It further explains it 'Fetches full metadata for papers matching query and saves to disk cache', which clearly distinguishes it from sibling tools like cache_list or cache_stats, and from search_works which presumably does not create a cache.

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 final sentence, 'Use this to build a reusable paper collection for a research topic,' gives clear guidance on when to employ this tool. However, it does not explicitly state when not to use it or mention 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?

With no annotations, the description carries the full burden of disclosing behavior. It merely says 'Export cache to file' without mentioning whether the operation is read-only, if it overwrites files, requires specific permissions, or has side effects. The lack of detail leaves the agent unsure about consequences.

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 a single short sentence. It is easy to parse and front-loaded with the primary action. However, it may be too terse for a tool with four parameters, lacking necessary elaboration while remaining appropriately brief.

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 four parameters and no annotations, the description is incomplete. It does not explain supported formats, how the 'fields' parameter behaves, typical usage examples, or any caveats. The presence of an output schema helps, but the description still leaves significant gaps in context.

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 all parameters with descriptions (100% coverage), so the baseline is 3. The description itself adds no additional meaning about parameters beyond what the schema already provides, but the schema is sufficient for basic understanding.

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 uses a specific verb and resource ('Export cache to file'), making the core action clear. However, it does not mention any distinguishing details from sibling tools like cache_list or cache_stats, though 'export' is a distinct operation. The purpose is easily inferred.

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. There is no mention of prerequisites, typical use cases, or scenarios where another cache tool would be more appropriate. The description simply states what it does without context.

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

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

With no annotations, the description carries the burden of disclosing behavior. It reveals the return format (JSON array of cache info) and the verb 'list' strongly implies a read-only operation. It does not mention side effects or errors, but for a parameterless list this is adequate.

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 no extraneous words. The primary action is front-loaded ('List all available caches'), and the return details are concisely listed on a second line.

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

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

For a zero-parameter list tool, the description is complete: it states the purpose and the exact return fields. No output schema is provided, but the description compensates by listing them. No additional context is needed for such a simple operation.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly focuses on the return value rather than parameter details, since none exist.

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 uses a specific verb+resource construction: 'List all available caches.' This clearly distinguishes it from sibling tools that focus on stats, plots, or exports. The added return info (name, path, paper_count, size) reinforces the 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 implies usage for discovering available caches but does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons with siblings are provided, so it relies on the user to infer context.

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

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

Annotations are absent, so the description must disclose behavioral traits. It only states the output is an HTML graph, but does not mention whether it reads/writes files, makes network calls, requires a pre-existing cache, or has any side effects. Minimal behavioral context is provided.

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 that front-load the main purpose. It contains no redundant or extra words, making it both informative and efficient.

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

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

For a simple plotting tool, the description covers the core function but lacks context about prerequisites (e.g., needing an existing cache) and how it relates to sibling cache_* tools. An output schema exists, so return values are likely covered, but the overall context is thin.

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

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

Schema coverage is 100%, so the input schema fully documents all parameters (name, output, max_nodes). The description adds no extra meaning beyond the schema, 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 clearly states a specific action and resource: 'Generate citation network visualization' and 'Creates interactive HTML graph showing citation relationships.' This distinguishes it from sibling visualization tool cache_plot_scatter by explicitly focusing on a network graph.

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. It does not mention the cache prerequisites, compare with cache_plot_scatter, or exclude any 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?

With no annotations, the description carries the transparency burden. It discloses two key behaviors: 'Saves plot to file' and 'returns top cited papers.' This reveals side effects (file output) and return behavior, which is more transparent than many tool descriptions. However, it doesn't mention whether it overwrites files or requires an existing cache, but for a plotting tool this is adequate.

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

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

Two short sentences, front-loaded with the primary purpose, and no filler. Every sentence adds value: the first states the plot type, the second describes the output and return behavior. This is highly 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?

Given the tool is simple with 3 parameters and an existing output schema, the description covers the essential aspects: what it does, what it saves, and what it returns. It doesn't explain the output format or error cases, but the output schema fills that gap. The description is sufficient for an agent to select and invoke this 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 100%, so all parameters already have descriptions. The description adds minimal new parameter-level meaning beyond confirming the 'top_n' relates to top cited papers and output file path is for saving the plot. It does not further clarify formats or constraints beyond the schema, 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 clearly states the tool creates a 'year vs citations scatter plot' and explicitly mentions the side effect of saving to file and returning top cited papers. This is specific, and it distinguishes from sibling 'cache_plot_network' which would be a different plot type. The verb 'Generate' and resource 'scatter plot' make the function 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 implies usage for creating a scatter plot of citations over time, but it doesn't provide explicit guidance on when to use this tool versus alternatives like cache_plot_network. No when/when-not conditions or alternative recommendations are mentioned, so it earns a 3 for implied 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 are provided, so the description carries the transparency burden. It discloses the behavioral trait of returning minimal data to reduce context usage, which informs the agent about output size. It does not explicitly state read-only behavior, but 'query' implies non-mutating. This is adequate but not exhaustive.

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

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

Two sentences, no waste. The first sentence states the purpose, the second explains the benefit and gives action. Perfectly concise.

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 query tool with 9 parameters and an output schema, the description covers the essential aspects: purpose, behavioral trait (minimal data), and usage instruction. It lacks explicit alternative comparison, but the core is present. A 4 is fair.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by instructing 'Specify only fields needed,' which directly relates to the `fields` parameter and explains its purpose. This elevates the score to 4.

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 'Query cached papers with field filtering,' providing a specific verb, resource, and scope. It distinguishes from sibling cache tools by emphasizing field filtering and minimal data return.

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 says 'Specify only fields needed,' giving clear guidance on how to use the tool to minimize context usage. It implies when to use this tool (when needing selective cached paper data) but does not explicitly name alternatives or exclusions, so a 4 is 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds a useful performance trait ('without loading full data') implying a lightweight, non-destructive read, but it does not state the absence of side effects, permissions needed, or any error behavior. 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 sentences, front-loaded with the main purpose, and every word adds value. No redundancy or filler.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description sufficiently explains the return scope. It lacks usage-versus-sibling context, but the core information for invocation and expected results is present.

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% for the single parameter 'name' with 'Cache name'. The description adds no extra semantics beyond the schema, so it meets the baseline for a well-documented parameter without further elaboration.

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 a specific resource ('cache statistics') and lists concrete outputs (year distribution, top journals, citation stats). It does not explicitly distinguish from sibling tools like cache_citation_summary, but the composed detail provides enough 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?

The description provides no guidance on when to prefer this tool over alternatives such as cache_citation_summary or cache_top_cited. It lacks context about typical use cases or explicit exclusions, leaving the agent to infer from the name alone.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the operation without adding context. It does not specify the sorting order, what 'top' means, whether the cache must already exist, or any error handling. The description adds little beyond the function name.

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 concise sentence with no filler words. It is front-loaded with the action. However, it is so brief that it sacrifices useful context; this under-specification is penalized in other dimensions but the structure itself is clean.

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 existence of an output schema, the description is minimally adequate for the core operation. However, it fails to situate the tool among siblings, and does not explain when to use it over cache_citation_summary or cache_stats. The lack of usage context makes it incomplete for an agent deciding which tool to invoke.

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 fully describes all parameters (n, name, year_max, year_min) with default values and descriptions, covering 100% of the schema. The description adds no parameter-specific information, so the schema serves as the primary source. 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 'Get top cited papers from cache' specifies the action (get), the object (top cited papers), and the resource (cache). It clearly distinguishes from sibling tools like cache_stats or cache_citation_summary by focusing on 'top cited' papers. While it doesn't explicitly name alternatives, the specific phrasing is sufficient to identify the tool's purpose.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, use cases, or alternative tools. The agent is given no context for selection, which is especially problematic given the many cache-related sibling 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, whether it modifies the database or file, or what happens when citations are missing. The phrase 'against the local database' implies comparison but lacks explicit behavioral detail.

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

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

A single sentence with no redundant words, front-loaded with the action and resource. It is appropriately sized for the information it conveys.

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 output schema exists and likely covers return values, but the description lacks details about prerequisites (e.g., file format expectations), the exact nature of the check (existence vs. metadata validation), and whether any side effects occur. It is adequate but has clear gaps.

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

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

Schema description coverage is 100%, and the description adds no extra meaning beyond what the schema already provides for file_path, validate_metadata, and suggest_enrichment. Baseline of 3 applies since the schema fully documents each parameter.

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

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

The description uses a specific verb ('Check'), identifies the resource ('citations in a BibTeX file'), and defines the scope ('against the local database'). This clearly distinguishes it from sibling tools like check_citations that might operate on citations in other contexts.

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 the user has a BibTeX file to validate, but it does not explicitly state when to prefer this tool over alternatives such as check_citations or provide any exclusions. No clear guidance on when not to use it.

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 of disclosing behavioral traits. It does state the tool checks existence and metadata completeness, which is useful. However, it does not clarify whether the operation is read-only, whether it has side effects, whether it requires network access, or what happens when metadata is incomplete. This is a modest disclosure but leaves notable gaps.

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 main action and then the specific detail. Every sentence earns its place, and there is no redundancy or filler.

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

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

The description covers the core functionality (DOI existence and metadata validation) but omits mention of the 'suggest_enrichment' feature, which is a distinguishing capability of the tool given the parameter exists. With an output schema present, return values are covered, but the high-level description leaves out a notable feature, making it incomplete for a user trying to understand the tool's full purpose.

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 fully describes all three parameters with 100% coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain how 'validate_metadata' or 'suggest_enrichment' behave beyond their schema descriptions, nor does it relate them to the description's mention of 'metadata completeness'.

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 a specific verb ('check') and resource ('citations against the local CrossRef database'), and explains the two main actions (validate DOIs exist, check metadata completeness). It is more specific than a tautology and distinguishes from sibling tools like search_by_doi (which finds DOIs) and enrich_dois (which improves metadata). However, it could more explicitly differentiate from check_bibtex, so not a perfect 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 the tool is used to validate DOIs against a local database, but it provides no explicit guidance on when to use it versus alternatives such as search_by_doi, check_bibtex, or enrich_dois. Since sibling tools are listed in context, the description misses an opportunity to state exclusions or preferred scenarios.

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 burden of behavioral disclosure. It indicates a read operation ('Fetch') and specifies the output format ('full Markdown content'), but does not disclose error behavior, prerequisites, or any side effects. This is adequate 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 a single, front-loaded sentence that directly states the action and output. No unnecessary words or repetition.

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

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

For a simple read tool with one parameter and an output schema present, the description adequately covers the necessary context. It names the kind of content and implies the source; no additional details are critical for 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 parameter description already explains the `name` field clearly (without `.md`, example). The tool description adds no additional parameter meaning beyond the schema, 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 uses a specific verb ('Fetch') and resource ('full Markdown content of one crossref-local skill page'), clearly distinguishing it from the sibling tool crossref_local_skills_list that presumably lists pages. It precisely identifies the tool's function and 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 clearly implies usage for retrieving a single skill page's content, but it does not explicitly state when to use it versus the listing tool or mention any alternatives. It provides clear context but no exclusions or alternative 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?

With no annotations, the description carries the transparency burden. It discloses the return format ('JSON string with success, package, skills') and the exhaustive scope ('every skill page'). No side effects or permissions are mentioned, but none are expected for a listing operation.

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 and well-structured: a one-sentence purpose followed by a Returns section outlining the output format. Every sentence provides useful information with no filler.

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

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

Given the tool's simplicity, an output schema, and the description's clarity, it is complete. The agent knows exactly what the tool does, what it returns, and that it takes no arguments.

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

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

The tool has zero parameters and the schema fully covers this (no properties). The description adds no parameter details, but none are needed, so the baseline of 4 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 action ('List the names') and the specific resource ('every skill page shipped by crossref-local'). This distinguishes it from sibling tools like crossref_local_skills_get, which likely retrieves a single skill's content.

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 usage context is implied (enumerate available skills), but there is no explicit guidance on when to choose this over sibling tools or any exclusions. The description does not mention alternatives such as crossref_local_skills_get.

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 burden of behavioral disclosure. It explains that the tool adds metadata fields like citation_count and references, which is useful, but it does not mention whether it performs network calls, validates DOIs, or has error conditions. It is not misleading, but it lacks depth about side effects and limitations.

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

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

The description is well-structured and front-loaded with the main purpose. Each sentence serves a clear role: stating function, clarifying when to use, and giving a workflow example. It is concise without wasted 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 provides a clear usage workflow and lists the enriched fields, and an output schema exists so return value details are not needed. It lacks only minor context about error handling or edge cases, but overall it is well-rounded for a simple enrichment 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 schema already covers the single parameter 'dois' with a rich description and example. The tool description adds little beyond the schema's existing coverage, 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 clearly states the tool's purpose with a specific verb and resource: 'Enrich DOIs with full metadata including citation counts and references.' It also distinguishes itself from the sibling search() by explicitly listing what search() returns versus what this tool adds.

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 explicit usage context: 'Use this after search()' and provides a typical workflow with steps. It also contrasts with the alternative search() tool, making it clear when to use this tool versus sibling 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 provided, the description carries the transparency burden. It discloses the output format (JSON string) and specifies the data fields returned, which gives a clear picture of behavior. However, it does not explicitly note side-effect-free/read-only status, though 'report' implies it. This is a minor gap.

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

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

The description is front-loaded with purpose and usage guidance. The 'Returns:' section is slightly redundant with the opening list but clarifies the output type. The inclusion of example user queries adds value. It is concise enough, though a bit more trimming could make it tighter.

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 simple (no parameters, low complexity). The description fully covers what the tool does, when to use it, and what it returns. An output schema exists, but the description still adds contextual value. It is complete for the tool's scope.

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

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

The tool has zero parameters, so the description does not need to explain parameter meaning. The schema coverage is 100% (vacuously). The score reflects the baseline of 4 for no-parameter tools.

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 uses a specific verb ('Report') and identifies the exact resource ('local CrossRef database status'). It enumerates the reported elements (path, work count, FTS5 index size, citation-graph edge count, access mode), which distinguishes it from all sibling tools. There is no ambiguity about its function.

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 states when to use the tool, including example user queries and the practical scenario of confirming DB usability before a search. It provides clear contextual triggers, satisfying the 'when-to-use' requirement even though no alternatives are needed because the tool is unique.

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 states only that the tool 'Get detailed information' but does not disclose what 'detailed information' includes, whether the operation is read-only, any rate limits, or what happens with non-existent DOIs. The description is too minimal to set expectations about side effects or response characteristics.

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, concise sentence that conveys the core purpose without any waste. It is front-loaded and easy to parse, which is ideal for an AI agent scanning tool descriptions.

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 4 parameters and an output schema, and the description is a minimal one-liner. While it clearly states the core function, it does not explain the optional parameters' purpose or the relationship to sibling tools. However, because the schema covers parameters and the output schema exists, the description is minimally viable for a simple lookup tool. More context about caveats or alternatives would elevate 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 input schema provides detailed descriptions for all four parameters (doi, save_path, as_citation, save_format), with 100% coverage. The description itself adds no parameter-level detail, but since the schema already documents each parameter clearly, the baseline of 3 is appropriate. The description does not need to repeat schema information.

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: 'Get detailed information about a work by DOI.' It uses a specific verb ('Get') and a resource ('a work by DOI'), distinguishing it from sibling tools like search_works (which likely searches by query) and enrich_dois (which likely enriches a list of DOIs). This is a clear, non-tautological statement of purpose.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or scenarios where another sibling tool would be preferred. Given the sibling tools include search_works, enrich_dois, and cache-related tools, the lack of usage context leaves the agent to infer when this tool is 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?

No annotations are present, so the description carries the burden. It discloses FTS5 index usage and query syntax, but does not mention potential file-writing side effects via save_path or output format behavior. Enough for a safe search operation but incomplete.

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

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

Two sentences, directly front-loads the search purpose, then adds FTS5 details. No filler, every sentence earns its place.

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

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

Covers core search functionality but omits guidance on save_path behavior, output formats, or pagination beyond schema descriptions. Given no annotations, a bit more would help, but schema is thorough.

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%, but baseline is 3. The description adds FTS5 boolean operators and exact phrase support to the query parameter, going beyond schema examples. Other parameters remain standard.

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 the tool searches academic works by title, abstract, or authors, and differentiates from sibling search_by_doi by focusing on full-text FTS5 search. Includes specific query syntax, making it a distinctive search tool.

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

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

Description implies use for keyword-based full-text search with FTS syntax, but does not explicitly state when to use this vs. siblings like search_by_doi or cache_query for exact lookups. No exclusions or alternative recommendations are provided.

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