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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the 1000-item limit, which is useful, but it does not disclose response format, error behavior, or partial-failure semantics. It provides modest value beyond 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 a single, concise sentence that front-loads the verb and includes the key constraint. No wasted words or redundant information.

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

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

For a batch retrieval tool with no output schema, the description is minimal but adequate for basic understanding. It does not explain return value structure or error handling, but the max-1000 limit and read-only nature are clear. Given the simplicity of the operation, this is acceptable but not rich enough for a higher score.

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%, meaning the description does not explicitly document the parameters. The schema itself contains detailed descriptions for author_ids and response_format, but the description merely implies the list of IDs with 'multiple authors' and 'max 1000'. It does not compensate for the low coverage and adds no real semantic value beyond what the schema already provides.

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

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

The description clearly states the action ('Retrieve multiple authors') and adds the key constraint 'single request (max 1000)', which distinguishes it from the sibling tool semantic_scholar_get_author. The verb and resource are 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?

The usage context is only implied by the name and description—it is a batch variant of get_author, but no explicit guidance is given about when to prefer it over repeated single calls or when not to use it. No alternatives are mentioned.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the max 500 limitation but does not disclose potential partial failures, missing IDs, rate limits, or response format. This is acceptable but not rich.

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

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

The description is a single sentence that immediately communicates the core purpose and constraint. There is no wasted wording, and it is 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?

The tool is relatively simple, and annotations cover safety, but the description is sparse. With no output schema, the agent lacks information about return values, error behavior, or what happens if any paper ID is invalid. The max 500 is helpful, but more context could be 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 does not describe any parameter semantics; it only mentions 'multiple papers' which vaguely relates to the paper_ids list. The context signal indicates schema description coverage of 0%, so the description must compensate, but it does not. The schema's internal definitions are not enough per the provided 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: 'Retrieve multiple papers in a single request (max 500).' The verb 'Retrieve' with resource 'multiple papers' is specific, and the max limit distinguishes it from singular fetch (semantic_scholar_get_paper) and search (semantic_scholar_search_papers).

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 fetching multiple papers at once, especially with the 'single request' phrase, but it does not explicitly name alternatives or state when not to use it. It offers only implicit guidance regarding batch retrieval, not clear exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the observed endpoint ignores `limit`, may return up to 1000 papers per page, and returns the full untruncated page so the continuation token skips nothing. No auth or rate-limit info, but this is strong operational disclosure.

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

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

Three tight sentences with the core capability front-loaded and the pagination caveat last. Slight redundancy with the schema on boolean syntax and the ignored `limit` keeps it from being maximally 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?

No output schema exists, so the description carries the return-shape burden and does so partially by explaining the continuation token and full-page return. Combined with the rich nested schema and annotations, an agent has enough to invoke it correctly; exact paper fields returned remain unspecified.

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

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

The schema's nested properties are documented, but the single top-level `params` wrapper is not. The description clarifies the sort capability, boolean query syntax, and the continuation-token semantics of pagination, and flags the `limit` caveat. Some of this (boolean syntax, limit-ignored) duplicates the nested schema descriptions, limiting the added value.

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

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

States a specific verb and resource ("Search papers") plus its distinguishing scope: sorting and cursor-based pagination for large result sets. It contrasts with "regular search" functionality but never names the sibling tool it is contrasted against, so differentiation relies on inference.

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

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

Gives a clear routing condition: use this when you need sorting, boolean query syntax, or paging through a large result set, as opposed to regular search. No explicit when-not-to-use or named alternative is given, but the context is unambiguous.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint), the description discloses that the output is plain text with no response_format option, and lists specific error triggers: unknown ID, paper without citation data, or non-bibtex format. This is valuable behavioral context not covered by 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 three concise, front-loaded sentences: purpose, usage, behavior. Each sentence earns its place with no redundant wording.

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 citation-export tool with one required parameter, the description covers workflow (use after search/match), input requirements, output format, and error scenarios. With annotations covering safety and idempotency, no further context is 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?

The schema already provides detailed descriptions for all parameters, including accepted paper_id formats and the format restriction. The description adds a concrete example ID and reinforces the error on non-bibtex, but doesn't substantially expand parameter understanding 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 opens with a specific verb and resource: 'Export a citation for a paper in BibTeX format.' This clearly distinguishes it from sibling tools like search/get paper. It also states the output format and prerequisite.

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 instructs to use it after obtaining a paper ID from semantic_scholar_search_papers or semantic_scholar_match_paper, giving clear upstream context. However, it does not mention exclusions or alternative downstream 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint. The description adds that publications are optional, which is useful, but it doesn't detail related behaviors such as default limits or response structure. No contradiction with 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 a single, front-loaded sentence with no filler. It states the core action and a key option efficiently, earning its place without unnecessary detail.

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

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

There is no output schema, and the description omits important context such as the required author_id, how to control the optional publications (include_papers, papers_limit), and the default response format. For a tool with multiple parameters and no output schema, this is insufficiently 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% at the top level, and the description never mentions any parameters. While the nested schema has some parameter descriptions, the tool description itself does not compensate for the low coverage, leaving the agent to infer parameter meaning solely from 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 uses a specific verb 'Get' with a clear resource 'author profile' and notes an optional publications list. This distinguishes it from sibling search tools, though it doesn't explicitly name alternatives. The purpose is clear and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives like semantic_scholar_search_authors or semantic_scholar_get_paper. It doesn't mention that an author_id is required or that this is for retrieving a specific existing author rather than searching.

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 cover safety (readOnly/idempotent/openWorld), but the description adds substantial operational context the annotations cannot: a 5-minute in-memory cache, a not-found error on unknown IDs, client-side request intervals (1.0s unkeyed / 1.1s authenticated), automatic retry with backoff on 429/502/503, and Markdown-by-default output. This is exactly the kind of behavior an agent needs to set retry expectations and pacing.

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

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

Front-loaded with purpose and accepted IDs, then returns, then flags/pagination, then cache/rate-limit behavior. Dense but well ordered; the rate-limit and backoff detail is somewhat peripheral to selecting or calling the tool but does earn its place for an agent that must pace requests.

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

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

No output schema exists, so the description carries the return-value burden and does so: it lists title, abstract, authors, venue, year, citation counts, TLDR, and OA PDF link, plus the shape of paginated citation/reference output (citations_page.next). Error, caching, and format behavior are all covered, leaving nothing an agent needs to invoke it 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?

With schema description coverage reported at 0%, the description compensates well by naming the accepted ID prefixes (DOI/ARXIV/PMID/CorpusId), the 1-100 per-page bounds on citation/reference listings, the independent offsets for each direction, and response_format='json'. It omits only the deprecated api_key parameter and its env-var override behavior, which the schema itself documents.

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

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

States a specific verb+resource ('Get paper details') and immediately enumerates the accepted identifier forms, so the agent knows exactly what this fetches. It also explicitly routes multi-paper retrieval to semantic_scholar_bulk_papers, distinguishing it from the sibling it most closely overlaps with.

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

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

Gives a clear condition for choosing the sibling: 'To fetch many papers at once use semantic_scholar_bulk_papers,' and explains the optional include_citations/include_references toggles. It stops short of stating when to prefer this over search_papers or match_paper, so it's strong but not fully exclusionary.

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

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

Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, covering safety and side-effect expectations. The description adds behavioral context by stating it returns a match score, which is not in the annotations. This is helpful for the agent to know what output to expect. It does not discuss edge cases like no match or ambiguous matches, but the strong annotation coverage reduces the need for further disclosure.

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

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

The description is two short sentences, front-loaded with the primary intent and return value. Every word is purposeful, with no redundancy or filler. It is an excellent example of concise, structured description.

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 (one required parameter, no output schema, strong annotations), the description covers the essential purpose and return type. It does not explicitly state how to handle edge cases like no match or ambiguous titles, but these are likely predictable for a title-matching tool. The presence of response_format and api_key parameters is handled by the schema, so the description need not repeat them.

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

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

The tool description provides no parameter information, and schema_description_coverage is 0%. Although the input schema includes rich descriptions (e.g., query is 'Paper title to match'), the rubric requires the description to compensate for low coverage. Since it does not mention any parameters or how to fill them, the description adds no value beyond what the schema already offers. This is a clear 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 uses a specific verb and resource ('Find the single best paper matching a title string') and clearly distinguishes itself from sibling tools: it returns a single best match rather than a list (unlike search_papers) and operates on a title string rather than an ID (unlike get_paper). This is concise and unambiguous.

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

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

The description implies when to use this tool: when you have a title string and want the single best matching paper. It does not explicitly name alternatives, but the phrase 'single best paper' contrasts with search tools that return lists, providing clear context. No exclusions are mentioned, but given the straightforward use case, this is sufficient.

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

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

Annotations already mark the tool as readOnly, openWorld, and idempotent. The description adds valuable behavioral context: results are steered toward positives and away from negatives, malformed IDs raise an error before making requests, and the response format can be markdown or JSON. It stops short of discussing auth or rate limits, but the additional context is substantive.

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

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

The description is tightly written in four sentences, immediately stating the purpose, followed by usage guidance, an example, parameter ranges, and output format. There is no fluff—every sentence contributes essential information.

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

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

Given the complexity of a multi-seed recommendation tool, the description covers the central behavior, parameter constraints, error handling, and return format. It omits the deprecated api_key parameter, but the schema explains it. The tool has no output schema, so the description effectively fills the gap by stating what is returned (papers, markdown or JSON).

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

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

The input schema already provides descriptions for all fields, so the baseline is 3. The description enhances parameter understanding by showing an example with specific ID formats, reaffirming the 1-100 positive and 1-100 negative limits, and noting the limit/default/response_format options. This adds practical value beyond the schema's static 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 verb and resource: 'Get recommendations using multiple positive and negative example papers.' It immediately distinguishes itself from sibling tool semantic_scholar_recommendations by stating it is for 'more than one example,' making the purpose unmistakable.

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 directs when to use this tool: 'Use instead of semantic_scholar_recommendations when steering with more than one example.' It also provides a concrete example and clarifies input limits, giving clear guidance on when and how to invoke 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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context beyond those annotations: author ordering, limit bounds, default values, and Markdown-vs-JSON output options. No contradiction with 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 compact—three sentences—and front-loaded with the core purpose. Every sentence earns its place by adding either differentiation, parameter detail, or output behavior, 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 read-only tool with one required parameter and no output schema, the description adequately covers return contents, output format, author ordering, limit behavior, and ID formats. Minor omissions like error handling or rate limits are acceptable given the tool's simplicity.

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?

Although context reports low schema description coverage, the description adds meaningful parameter context: a concrete paper_id format example, the 1-1000 limit with default 100, and response_format options. The schema also provides detailed per-parameter descriptions, so the two complement each other 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?

The description clearly states the tool's verb and resource: 'Get full author profiles for a paper's authors.' It also explicitly distinguishes itself from the abbreviated author list in semantic_scholar_get_paper and connects to semantic_scholar_get_author via returned author IDs.

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 clear contrast with semantic_scholar_get_paper, implying when to use this tool over that one, and includes a concrete example paper_id. However, it does not explicitly enumerate exclusion cases or alternative tools for related scenarios, so it stops short of full when/when-not 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?

Given the readOnlyHint and idempotentHint annotations, the description still adds significant new context: error handling (unknown seed raises not-found), rate limiting details (1.0-second unkeyed interval, 1.1-second authenticated default, configurable quotas), automatic retries on 429/502/503 with backoff, and return format defaults. This is exactly the kind of operational context annotations cannot convey.

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

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

The description is front-loaded with the core purpose, then branches into options, alternatives, error behavior, and operational details. Every sentence adds concrete value; no 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?

For a tool with no output schema, the description covers all critical aspects: what it returns (up to limit similar papers in Markdown or JSON), how to control scope (from_pool), when to use an alternative, error conditions, and rate-limit/retry behavior. Nothing essential for correct invocation is missing.

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

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

Schema coverage is low (0% per context signals, though the schema itself does include some descriptions), so the description must carry the burden. It explains the purpose of paper_id, from_pool, response_format, and mentions limit. It doesn't fully describe the api_key parameter or the exact format for paper_id, but provides enough functional meaning.

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

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

States a specific verb+resource ('Get paper recommendations based on a seed paper') and clarifies scope immediately. It also distinguishes itself from the sibling semantic_scholar_multi_recommend by explaining that multi_recommend should be used for steering with several examples.

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 tells the agent when to use this tool (one seed paper) vs the alternative (semantic_scholar_multi_recommend for multiple positive/negative examples). It also explains the effect of from_pool options, leaving little to inference.

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

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

Annotations already cover read-only/idempotent behavior, so the description adds value by disclosing Markdown default output, response_format='json' option, and pagination limits (max 100, default 10). It also warns about name ambiguity, offering extra operational context beyond the annotations.

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

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

The description is compact and well-structured: it opens with the core purpose, then supplies an example, caveats, alternatives, and paging/output details. Every sentence carries load, with no fluff.

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

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

The description covers primary usage, pagination, output formats, and points to relevant sibling tools. It does not detail the response structure, but given the schema and annotations, it is sufficient for selecting and invoking the tool correctly.

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

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

The schema already contains descriptive text for each parameter, so the description's example and mention of offset/limit and response_format add only modest value. The concrete query example and clarification of default response format help, but the schema does most of the heavy lifting.

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

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

The description states 'Search for academic authors by name' with a concrete example ('Yoshua Bengio'). It distinguishes from sibling tools by explicitly naming semantic_scholar_paper_authors for a different use case (listing authors of a specific 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 clearly says when to use this tool (search by name) and when to use alternatives: semantic_scholar_get_author for confirming identity and semantic_scholar_paper_authors for listing paper authors. It also provides pagination guidance and response format selection, fully covering usage context.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: relevance ranking, the 200M+ corpus, per-call page cap of 100, unchanged query forwarding, and default Markdown vs output. Minor gaps remain (no rate-limit or auth notes), so a 4 rather than a 5.

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

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

Front-loaded with the core action, then filters, then query-syntax caveat, then routing to siblings, then output format. Dense but every sentence carries decision-relevant information; 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?

No output schema exists, and the description covers the return contract ('Returns Markdown by default, response_format=json for raw JSON'). Combined with annotations carrying the safety profile and the description covering pagination and routing, an agent has everything needed to call this 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?

Reported schema description coverage is 0% at the top level, yet the description enumerates the filter surface (year, field-of-study, publication-type, open-access, citation-count) and explains offset/limit paging and response_format. It does not mention the deprecated api_key parameter, but it compensates well for the coverage gap on the parameters that matter for search 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?

States a specific verb+resource ('Search for academic papers') and immediately qualifies the mechanism ('relevance-ranked plain-text search over 200M+ papers'). It also names the sibling it is not (bulk_search, snippet_search, match_paper), so an agent can distinguish it from alternatives without opening a schema.

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

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

Explicitly routes the agent: bulk_search for sorted or very large result sets, snippet_search for full text, match_paper for a known title. It also states the query is forwarded unchanged and that boolean/phrase syntax belongs to bulk_search, which is a precise when-to-use-not constraint.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context beyond annotations with the explicit rate-limit warning ('heavily rate-limited without an API key') and clarifies the return format ('text snippets with context'). This is meaningful additional 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 compact: two purposeful sentences plus a note. It front-loads the core action and return type, then a key caveat. Every word earns its place; there is no redundancy or padding.

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

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

With 8 parameters and no output schema, the description is under-specified. It does not explain result formatting, pagination, how to scope searches (e.g., by paper IDs or fields), or any usage examples. The rate-limit note is helpful but leaves too many operational gaps for a tool of this 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 reported as 0% at the top level, yet the description provides no parameter-level guidance. It only indirectly relates to the api_key parameter via the rate-limit note. The description fails to compensate for the lack of schema parameter descriptions, leaving filters like year, field_of_study, and paper_ids 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 states a specific verb ('Search') with a clear resource ('paper full text') and return type ('text snippets with context'). The title 'Search Paper Full Text' aligns, and it distinguishes from siblings like semantic_scholar_search_papers by focusing on full-text snippet retrieval rather than metadata 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 clear context that this tool is for searching within full text and returns snippets, implying when to use it over sibling metadata search tools. However, it does not explicitly name alternatives or state when not to use it, so it lacks the exclusionary guidance seen in higher-scoring examples.

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

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

Annotations already cover the safety profile with readOnlyHint, openWorldHint, and idempotentHint, which lower the burden. The description adds value by specifying the exact components checked (server health, API connectivity, key status), providing more detail than a generic 'check status.' It does not disclose return format or potential error conditions, but the annotations handle the critical safety aspects.

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, direct sentence that immediately conveys the tool's purpose without any unnecessary words or repetition. It is front-loaded and every word contributes meaning.

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 (no parameters, no output schema), the description covers the core functionality well by listing three specific status areas. However, it does not describe the response structure, which could be useful for an agent deciding how to interpret the result. Still, for a low-complexity tool with strong annotations, this is adequate.

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 input schema is trivially complete. With no parameters to describe, the baseline for this dimension is 4, and the description does not need to add parameter-specific 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 uses a specific verb and resource: 'Check server health, API connectivity, and key status.' This clearly distinguishes it from the sibling tools, which are all focused on searching or retrieving papers/authors. There is no ambiguity about the tool's role as a status/health check.

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 does not explicitly state when to use this tool versus alternatives, but the sibling context makes it obvious that this is the only status-related tool. The usage is implied rather than directly stated, and there is no guidance on prerequisites or scenarios where this should be called (e.g., before other API calls).

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