ScholarFetch

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 states it reads the best abstract and lists allowed engine values. It does not disclose fallback behavior if no abstract is found, whether it queries all engines simultaneously, or explicitly confirm it is a read-only operation beyond the word "Read."

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 clear front-loading of purpose. The second sentence covers parameter usage without redundancy. Every sentence earns its place, and the engine list is necessary for correct invocation.

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

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

Given the tool has 5 optional parameters, no annotations, and an output schema, the description covers the essential invocation patterns and engine constraints. It doesn't explain precedence when both DOI and author parameters are provided, or error behavior, but the output schema likely covers return values. The context is adequate for the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the two usage modes (DOI vs author_name + candidate_index + paper_index), and details the `engines` parameter with a comma-separated list of accepted values. It leaves `candidate_index` and `paper_index` somewhat implicit, but referencing "after author_papers" provides useful context.

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 with a specific verb+resource combination: "Read the best abstract available for a paper." It distinguishes itself from siblings like scholarfetch_article_text (full text) and scholarfetch_search (search) by focusing specifically on abstract retrieval.

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 usage paths: "Use with a DOI or with author_name + candidate_index + paper_index after author_papers." This gives clear context for when to use which parameters. However, it does not explicitly state when NOT to use this tool or alternatives, though the pipeline reference implies after author_papers.

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, but the description discloses key behavioral traits: source priority (Elsevier first), fallback order (Springer OA, Europe PMC, arXiv PDF, generic PDF URLs), and the condition that text must be recoverable. It does not mention error handling or empty results, but this is still substantial disclosure beyond the basic purpose.

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 concise sentences, front-loaded with the main purpose, followed by usage and engine specifics. No wasted words; 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?

Given an output schema exists to define return values, the description covers the main usage and engine options. It does not address mutual exclusivity of DOI vs author_name or behavior when neither is provided, but for a 5-param optional tool, it is reasonably complete and well-contextualized.

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 must compensate. It explains the DOI-or-author-combo and the engines parameter with allowed values. However, candidate_index and paper_index are not individually explained beyond being part of the combination, leaving ambiguity about their meaning and allowed range.

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 full paper text when machine-readable content is recoverable, and explicitly distinguishes it from siblings like scholarfetch_abstract by specifying input combinations (DOI or author+indices) and engine fallback order. The verb 'read' plus resource 'full paper text' is specific and unambiguous.

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

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

Provides explicit usage scenarios: use with a DOI or author_name + candidate_index + paper_index, and clarifies the engines parameter syntax with a valid subset. It gives clear context for when to use (when machine-readable content is recoverable) but does not explicitly state when not to use or name alternative tools.

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

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

No annotations are provided, so the description carries the burden. It does disclose a constraint on the engines parameter and indicates the output includes a stable candidate_index. However, it does not describe ranking behavior, error handling, or any side effects. With no annotations, this is acceptable but not comprehensive.

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

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

Two sentences, front-loaded with the primary purpose, and every clause earns its place. No filler or redundancy. The key usage guidance and a critical constraint are included without extra verbosity.

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 tools' purpose and usage are well covered, and the output schema exists so return values are not the description's burden. However, with no annotations and no parameter descriptions for limit, the description is slightly incomplete for a tool of moderate complexity. Still, the guidance is enough for an agent to select and call 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 description coverage is 0%, so the description must add meaning. It gives context for `name` (human author name) and `engines` (must include openalex), but `limit` is not explained beyond its schema default. The description adds some value but does not fully compensate for the lack of parameter descriptions.

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

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

The description opens with a specific, actionable verb phrase: "Disambiguate a human author name into ranked identity candidates." This clearly distinguishes the tool from siblings like scholarfetch_search (which searches literature) and scholarfetch_author_papers (which fetches papers for an existing author identity).

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

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

Explicit usage guidance is provided: "Use this before scholarfetch_author_papers when the name is ambiguous and you need a stable candidate_index." This names the sibling tool and states the precise scenario where the tool is needed. It also adds a critical constraint: if engines is passed, it must include openalex, guiding parameter choice.

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 behavioral burden. It discloses deduplication, filter support, and engine constraint, but lacks details on edge cases (e.g., behavior when both author_id and author_name are provided) and any mention of output structure or pagination. This is adequate but not rich on behavioral traits.

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 dense and information-packed, with the main purpose front-loaded. Each sentence adds value, but the filter list and engine note make it slightly long. It is still concise given the complexity, 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?

For a tool with six optional parameters and an output schema, the description provides good context: traversal purpose, filter syntax, and engine requirement. It does not cover all conceivable edge cases (like parameter conflicts), but it gives enough for an agent to invoke it correctly in most scenarios. Slightly incomplete due to lack of limit semantics.

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 author_id, author_name, candidate_index usage, filters syntax, and engines constraint. However, it does not describe the 'limit' parameter, which remains ambiguous. Overall, it adds significant semantic meaning beyond the raw schema, though one param is left undocumented.

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

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

The description clearly states the tool's function: 'Expand one author into a deduplicated paper list.' It uses a specific verb ('expand') and resource ('author into paper list'), and explicitly distinguishes itself as the 'main author->paper traversal tool' from sibling tools like scholarfetch_author_candidates. This makes its purpose unambiguous.

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

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

The description provides explicit usage instructions: when to use author_id vs author_name plus candidate_index, specifically mentioning the prior use of scholarfetch_author_candidates. It also gives a complete list of supported filters and a critical constraint for the 'engines' parameter, which effectively communicates when and how to use the 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?

With annotations absent, the description carries the burden. It discloses the output types and the engines parameter behavior (comma-separated subset), but does not mention potential side effects, rate limits, error handling, or whether it performs network calls. The description provides some behavioral context but lacks depth.

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, followed by necessary engine instructions. Every word earns its place, with no redundant or incidental content.

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

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

An output schema exists, so return values need not be detailed. The tool is simple with only one required parameter. However, the description lacks explicit context about when to use this tool versus siblings, and does not mention what happens if the DOI is invalid or not found. Overall it is reasonably complete for a lookup tool but has minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'engines' parameter with a concrete list of valid values, but for 'doi' it only says 'known DOI' without defining format or validation. The description adds partial meaning but does not fully compensate for the missing 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 function with a specific verb ('Enrich') and resource ('one known DOI'), and lists the types of output (metadata, reading links, full-text availability signals). This distinguishes it from sibling tools like search or abstract.

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 phrase 'one known DOI' implies the tool is for when you already have a DOI, but it does not explicitly mention when not to use it or suggest alternatives like scholarfetch_search for finding DOIs. The engines parameter guidance is useful but does not cover when to choose this tool over siblings.

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 responsibility for behavioral disclosure. It does not mention side effects, whether the operation is read-only, rate limits, or expected return behavior. It only gives usage modes and engine list, which is not enough given zero annotation support.

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 three sentences, front-loaded with the core action, and every sentence adds necessary information: purpose, usage modes, and engine constraints. There is no redundant or filler content.

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

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

The description gives a good high-level overview and engine guidance, but there is ambiguity around parameter combinations and precedence, especially since all parameters are optional. The output schema covers return values, so that gap is acceptable, but the input semantics are incomplete.

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 two invocation groups (DOI vs author_name + candidate_index + paper_index) and acceptable engine values, but does not define the meaning or format of individual parameters like candidate_index or paper_index.

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 'Expand a paper into its references', which is a specific verb+resource. It also identifies itself as 'the main edge-expansion tool for traversing the literature graph', distinguishing it from sibling tools that handle other operations like abstracts or search.

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

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

It provides explicit usage modes: 'Use with a DOI or with author_name + candidate_index + paper_index', and engine selection instructions. It positions the tool as the main expansion tool, implying when to use it, though it doesn't explicitly say when not to use 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?

There are no annotations, so the description must carry behavioral disclosure. It reveals that the reading list is 'in-memory' (implying transient state) and that the tool operates on a 'named' collection. However, it does not disclose whether adding a duplicate paper overwrites or appends, what happens when a collection doesn't exist, or what the return value indicates. With 9 parameters and no annotations, more behavioral detail would help, but the 'in-memory' and 'reuse' hints provide some 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 three sentences, with the main purpose front-loaded. Each sentence contributes: the first states what it does, the second explains input modes, and the third gives usage advice on collections. There is no fluff or repetition; it is appropriately 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 has 9 parameters, no schema descriptions, no annotations, but an output schema is present, the description covers the core semantics well. It explains the three input modes and the collection reuse pattern, which are the most critical aspects for correct usage. It does not explain the 'engines' parameter or return value details, but the output schema may cover returns. For a comprehensive tool like this, the description is complete enough for most usage scenarios, though some parameters remain under-specified.

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 three ways to specify a paper: paper_json, DOI, query+result_index, and author_name+candidate_index+paper_index. This directly maps to the schema's parameters and explains their combined meaning. It also clarifies the 'collection' parameter's purpose via 'Reuse the same collection name.' However, the 'engines' parameter remains unexplained, and the exact format of paper_json is only hinted at ('copied from another ScholarFetch tool result'). Still, the description adds significant semantic value over 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 the action: 'Add one paper to a named in-memory reading list on the MCP server.' The verb 'Add' and resource 'paper to reading list' specify exactly what the tool does, and this distinguishes it from sibling tools like saved_remove, saved_clear, and saved_list. It also adds the 'in-memory' and 'named' qualifiers, which further clarify the tool's role.

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

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

The description gives concrete guidance on when to use it and how: 'Best input is paper_json copied from another ScholarFetch tool result, but DOI, query+result_index, or author_name+candidate_index+paper_index also work.' This explicitly outlines three alternative usage modes and prioritizes the recommended one. It also provides advice on the collection parameter ('Reuse the same collection name'). It doesn't explicitly contrast with sibling 'remove' or 'clear' tools, but the workflow context is clear enough.

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 destructive nature ('Clear all papers') and qualifies the scope with 'in-memory' and 'named', which adds context beyond the tool name. However, it does not mention irreversibility or error handling, and since no annotations exist, the description carries the full burden. Still, it is sufficiently explicit for a simple clear 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?

Two short sentences, front-loaded with the action, no redundant information.

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

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

For a single-parameter clear operation, the description covers the action, scope, and a relevant use case. The existence of an output schema reduces the need to describe return values. Minor gaps include lack of explicit parameter guidance, but overall it's 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 has one parameter (collection) with no description, and the description's 'named reading list' hints at the collection parameter but does not explicitly map it. With 0% schema coverage, the description partially compensates by implying the list name, but it doesn't explain default values or valid 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 the tool's function with a specific verb ('clear') and resource ('all papers from a named in-memory reading list'), which distinguishes it from sibling tools like saved_remove and saved_list.

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 provides a use case ('Useful when restarting a research branch') but does not explicitly contrast with alternatives like saved_remove or mention when not to use it. The context is clear but lacks explicit exclusions.

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

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

With no annotations, the description carries the burden of exposing behavior. It discloses format/style constraints and the `include_references` condition, but does not mention whether the operation is read-only, what happens with an empty list, or any side effects. It adds some behavioral context but not comprehensive 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 three sentences, front-loaded with the primary purpose, and every sentence adds specific usage information. There is no fluff 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?

While the output schema exists and the core parameters are covered, the description does not explain what 'current reading list' means, nor does it address the `collection` and `engines` parameters. This leaves ambiguity for a tool with 5 optional parameters and no other annotation.

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 `format`, `style`, and `include_references` with valid values and conditional logic, adding real meaning. However, `collection` and `engines` are left entirely undocumented, leaving 2 of 5 parameters unexplained.

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 exports the current reading list in multiple formats (citations, abstracts, BibTeX, full-text corpus), distinguishing it from siblings like saved_list or saved_add by the export action. It uses a specific verb and resource.

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 valid values for `format` and `style`, and gives guidance for using `include_references` with `fulltext`. It does not explicitly name alternative tools, but the context of exporting the whole reading list versus per-article tools is implied.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It notes the list is 'in-memory' and 'currently saved', indicating an ephemeral, read-only state, but it does not explicitly state that the tool causes no side effects or that it does not modify the list.

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 core action, and contains no redundant information. 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?

The tool is simple with one optional parameter and an output schema, so return structure is covered elsewhere. However, the description fails to compensate for the missing parameter semantics and does not fully articulate the read-only nature, leaving 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?

The schema has one parameter 'collection' with 0% schema description coverage, and the description does not explicitly explain this parameter. It only mentions a 'named' list, which hints at the connection but does not clarify that 'collection' is the list name, its valid values, or its default behavior.

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 lists papers saved in a named reading list with the verb 'List' and resource 'papers currently saved in a named in-memory reading list'. It distinguishes from siblings like saved_add, saved_remove, and saved_export by focusing on inspection/listing.

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 context for use: 'Use this to inspect the working set before exporting or removing items.' This tells the agent when to invoke it, though it lacks direct exclusions or mentions of alternative tools.

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

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

The description discloses the 'in-memory' nature and that it removes exactly one paper. But with no annotations, it does not address what happens when no matching paper is found, whether both DOI and title are provided, or whether removal is permanent (especially given the in-memory context).

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

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

One sentence, tightly constructed with no filler. Verb, object, and method are all 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?

The description gives a clear idea of the tool's function but leaves out edge cases. Since an output schema exists, return values are covered, but the description does not clarify required inputs (schema says all optional, while description implies DOI or title is needed) or behavior when the list or paper is missing.

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

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

The schema has no per-parameter descriptions (0% coverage), but the description explains that doi and title serve as alternative identifiers and 'named' list corresponds to the collection parameter. It doesn't clarify that all parameters are optional or the default behavior, but adds significant meaning beyond the bare schema.

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

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

The description uses a specific verb ('Remove') and resource ('paper from a named in-memory reading list'), and clarifies the identification method ('by DOI or exact title'). It clearly distinguishes from sibling tools like saved_add, saved_clear, and saved_list.

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 clearly implies when to use: to remove a single paper from a specific in-memory collection. However, it does not explicitly mention alternatives or exclusions (e.g., use saved_clear to remove all papers) or explain prerequisites like the list must already exist.

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 reveals that results are deduplicated and can be inspected, saved, expanded via references, or used for author exploration, which adds useful context beyond a simple 'search' and implies read-only 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 concise and front-loaded, with two sentences that pack in purpose, outcomes, and parameter guidance. Every clause adds value, and the engine list is efficiently embedded.

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 usage, result handling, and key parameter specifics, while the output schema handles return details. It misses only minor aspects like limit semantics and pagination, which are minor given the default value and typical search behavior.

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 explains that query can be keywords, a DOI, or a person name, and provides an explicit comma-separated subset for engines, effectively compensating for the schema's lack of descriptions. However, it does not mention the limit parameter, leaving it unexplained despite the 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?

The description clearly states the tool's action: 'Start a research traversal' from keywords, DOI, or person name. It distinguishes itself from sibling tools by positioning this as the entry point for research exploration, while other tools like doi_lookup or author_candidates handle more specific steps.

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 provides implied usage context (use to begin research) and gives explicit guidance on the engines parameter, including a list of allowed values. However, it does not explicitly mention when not to use this tool or name alternatives, such as using scholarfetch_doi_lookup for direct DOI lookup.

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