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

The description extensively discloses nontrivial behavioral details: the drain cursor advances, has_more/check_start/last_checked semantics, truncation behavior, cursor reset conditions, and not-found errors. These go far beyond the annotations, which only indicate non-read-only and non-idempotent 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?

Although the description is long, every sentence contributes operational detail: purpose, parameter behavior, cursor mechanics, prerequisites, error cases, and return summary. It is front-loaded with the core purpose and the rest 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 the single optional parameter, no output schema, and stateful behavior, the description is remarkably complete. It explains how the tool mutates internal state across calls, what the client can expect in terms of pagination, error semantics, and the response summary.

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?

Even though the schema already describes the topic parameter with 100% coverage, the description adds crucial semantic nuance: omission runs all watches, a topic string must match exactly, and calling with a nonexistent topic yields a clear error. This meaningfully extends 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: 'Check all saved topic watches for newly published papers since the last check.' It clearly distinguishes itself from sibling tools like watch_topic and search_papers by centering on alerting for saved watched topics, not general search or watch creation.

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

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

The description gives clear operational context: when to use it (checking saved watches for new papers) and a prerequisite ('Use watch_topic to register topics before calling'). It lacks explicit comparisons to alternatives, but the intended usage 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 readOnlyHint and openWorldHint annotations, the description reveals concrete behavior: results are bounded by default to stay within the unauthenticated quota, an API key can raise the limit, and persistent rate limits return status=rate_limited instead of failing hard. These are valuable, non-obvious behavioral details from the agent's perspective.

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 front-loaded: the first sentence states exactly what the tool returns, and the second covers the important operational constraints. There is no filler or repetition of structured metadata.

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 no output schema, the description provides enough about the return set ('papers citing' and 'papers referenced') and the special status behavior. It could also mention how max_citations applies to each citation/reference grouping, but the core context needed to select and invoke the tool 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?

The input schema already fully documents both parameters, including the default of 50 for max_citations. The description does not add significant new parameter-level semantics beyond reminding the caller about quota/rate-limit context, so the baseline for high schema coverage 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 states a clear verb and resource: 'return papers citing an arXiv paper and papers that it references' using Semantic Scholar's citation graph. It names both the input kind (arXiv paper) and the operation, making the tool separable from sibling tools like list_papers or search_papers at a glance.

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 for citation and reference graph traversal, which is a clear use case, but it does not explicitly contrast it with sibling tools like export_citations or search_papers. The operational context about rate limits is useful, but the 'when to use this instead of that' guidance is only implied, not stated.

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 annotations only say readOnlyHint=false and openWorldHint=true, so the description carries the burden for behavior. It discloses meaningful side effects: it stores locally, permits overwriting cached versions, and can return truncated paginated responses. It also explains fallback behavior between HTML and PDF conversion, which annotations cannot capture.

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 front-loads the core action before diving into edge cases. Every sentence earns its place; the pagination, cache overwrite, and full-text options are all tightly packed without rambling.

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 there is no output schema, the description adequately covers what an agent needs for correct invocation: return length cap, truncation behavior, continuation semantics, and cache invalidation. The operational contract is complete enough to use the tool without additional research.

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 documents all parameters with 100% coverage, so the baseline is 3. The description adds value beyond schema by explaining the bounded default (~12,000 chars), the interaction between start and next_retrieval, and the real-world use at force=true. This raises it slightly above baseline.

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

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

The description states a specific verb ('download'), a precise resource ('a paper from arXiv'), and the delivered output ('text content'). It clearly explains retrieval strategy (HTML first, PDF fallback) and local storage, making the tool's purpose distinguishable from simple reading siblings like read_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 gives clear operational guidance: how to handle truncated results with start and return_full_text, and when force=true is needed to overwrite a cached paper. It does not explicitly route away from siblings like read_paper or search_paper_text, so it lacks explicit exclusions, but the usage context is otherwise clear.

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 annotations (readOnlyHint, openWorldHint), the description adds significant behavioral context: uses authoritative metadata, never model-generated fields, preserves version suffixes, deterministic keys, and returns status/error per paper. No contradictions 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 two sentences, front-loaded with the main purpose. Every sentence provides value: first sentence defines the action and data source, second covers edge cases and limitations. No 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?

Given the simple one-parameter input, no output schema, and annotations present, the description covers all essential aspects: purpose, data source, behavior (deterministic keys, version handling), return content, and format limitation. Complete for this tool's complexity.

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

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

The single parameter 'paper_ids' is fully described in the input schema (format, constraints). The description adds context about using authoritative metadata but does not add new parameter-level semantics beyond schema. Schema coverage is 100%, so baseline 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 it exports BibTeX citations using authoritative arXiv metadata. The verb 'export' and resource 'BibTeX citations' are specific, and the scope (arXiv papers, authoritative metadata) differentiates it from siblings like download_paper or get_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 description states 'BibTeX only; RIS/CSL-JSON are not yet supported,' providing a key limitation. It implies when to use this tool (when BibTeX is needed) but does not explicitly state when not to use it or list alternative tools. The guidance 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?

The readOnlyHint and openWorldHint annotations already cover the safety profile. The description adds extra behavioral context by explicitly stating it fetches metadata without downloading the paper, enumerating the returned fields, and advising usage as a relevance-screening step. There is no contradiction with 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 three sentences, each with a distinct purpose: what it does, when to use it, and what it returns. There is no filler; it is front-loaded and 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?

For a simple metadata-fetching tool with one parameter, readOnly annotations, and no output schema, the description covers invocation context, return fields, and conditional usage. Nothing important is missing for an agent to call 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?

The single parameter paper_id is fully described in the schema with a type and example. The description merely mentions 'by arXiv ID,' which adds no meaning beyond the schema. With 100% schema coverage, 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 opens with a precise verb and resource: 'Fetch abstract and metadata by arXiv ID,' and immediately differentiates itself by noting 'without downloading the paper,' which distinguishes it from the sibling download_paper. Listing the returned fields (title, authors, abstract, categories, published date, PDF URL) makes 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?

The description gives explicit usage context: 'Use before download_paper to assess relevance' and 'After compact search, use for one full abstract; skip if search used abstract_mode=full.' This provides both when-to-use and when-to-skip guidance, clearly distinguishing it from alternate flows.

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 mark readOnlyHint as false, and the description aligns by disclosing caching and processing side effects. It adds useful behavioral context beyond the annotations: the operation downloads, processes, caches, and returns bounded source, and it tells the agent the result is bounded rather than unbounded. It does not detail what 'safely process' entails, but this is a meaningful disclosure for a side-effecting tool.

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

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

Two sentences with no filler. The first sentence front-loads the core behavior and constraints, and the second gives a crisp usage directive. Every piece of text earns its place, and the key differentiator ('bounded', 'use section tools') appears immediately.

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 annotations are sparse and there is no output schema, the description provides the essential behavior (returns bounded LaTeX source), the caching/processing side effects, and a usage pointer to section tools. It does not describe the output format or error conditions, but the schema fully documents the parameters and the core purpose is clear enough for correct invocation.

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

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

Schema description coverage is 100%, so all four parameters (paper_id, start, max_chars, return_full_text) are already documented. The description does not need to repeat parameter details. It adds only a high-level 'bounded' concept, which is already reflected in max_chars and return_full_text, so it stays at the baseline for high schema coverage.

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

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

The description names a specific resource ('original LaTeX source'), a clear action set ('Download, safely process, cache, and return'), and a key constraint ('bounded'). It also distinguishes itself from section-level tools by explicitly directing targeted reading to section tools, helping an agent separate this from sibling tools like get_paper_latex_section and read_paper_section.

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 tells the agent to use section tools for targeted reading, which is a clear exclusion that prevents misuse. However, it does not explicitly state when to choose this tool over download_paper or read_paper, nor does it name specific section tools, leaving some inference to the agent.

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 meaningful behavioral traits beyond the annotations: results are bounded, matching is whitespace/case normalized, and macros are expanded. While readOnlyHint is false, the description's 'Return' language does not explicitly contradict that annotation, and the added normalization/expansion context is valuable.

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

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

The description is a single, front-loaded sentence with no filler. It packs the core purpose and key matching behaviors into minimal words, making it easy for an agent to parse quickly.

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 is adequate for selecting the tool, but with no output schema and only terse behavioral notes, it leaves some gaps: it does not describe the return structure, how 'bounded' interacts with max_chars/return_full_text, or what happens when a section is not found. The schema compensates partially, but the description alone is not fully self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds useful semantics for section_id by mentioning title/outline ID and normalization, but it does not add significant meaning for start, max_chars, or return_full_text 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 states a specific verb ('Return'), a specific resource ('one bounded LaTeX section'), and the selection mechanism ('by outline ID or title'). It also adds useful matching semantics ('whitespace/case normalized; macros expanded'). This clearly distinguishes it from siblings like get_paper_latex and list_paper_latex_sections.

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 a single bounded LaTeX section is needed, but it gives no explicit guidance about when to use this tool instead of related tools such as get_paper_latex, read_paper_section, or list_paper_latex_sections. There are no stated exclusions or alternative-selection conditions.

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 readOnlyHint=true annotation, the description adds 'paginated', 'Stable hierarchical section IDs', and the markdown context. These are meaningful behavioral details. It does not disclose failure modes, but the read-only nature is already annotated and there is no contradiction.

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

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

Two short sentences with zero filler. The core behavior is front-loaded, and the second sentence adds the most actionable routing hint an agent needs. Every word 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?

With a fully documented input schema, a read-only annotation, and a clear description of the returned outline and its IDs, the tool is fully specified for correct invocation. The pointer to read_paper_section completes the usage contract without needing an output schema.

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 every parameter is already well documented. The description adds a light link to pagination semantics but no deeper parameter detail, which is acceptable given the high schema coverage baseline.

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

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

The description has a specific verb ('Return'), a precise resource ('heading outline for a downloaded paper (markdown)'), and distinguishes itself from section content retrieval by explicitly pointing to read_paper_section. It is immediately clear what the tool produces and how it differs from its siblings.

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

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

The description provides a clear usage clue by saying 'use read_paper_section to fetch one', signaling that this tool is for outlines, not content. It does not exhaustively enumerate all alternatives, but the routing guidance is sufficient for a heading-list 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?

Annotations are sparse: readOnlyHint is false (implying possible side effects, but the tool appears read-only), and openWorldHint is true (suggesting external effects, but none are described). The description provides no insight into behavior beyond the basic function, such as whether it may access external resources, handle missing LaTeX, or have performance implications. It does not contradict annotations, but it does not add meaningful 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?

The description is a single, concise sentence that front-loads the core purpose. It contains no fluff and is easy to scan. It earns its place by being clear and direct without extraneous information.

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

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

Given the tool's complexity (3 params, no output schema), the description is minimally acceptable. The schema covers parameters well, but the description lacks details on the output format (e.g., how headings are structured) and edge cases (e.g., papers without LaTeX). For a tool that returns a list of headings, an agent might need more context, but it is not severely deficient.

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?

Parameter descriptions in the schema cover all three parameters (paper_id, start, max_sections) with reasonable details, achieving 100% coverage. However, the description itself adds little beyond the schema; it doesn't explain how start and max_sections affect the outline or provide examples. The baseline of 3 is appropriate since the schema does 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 clearly states the tool returns a compact outline of headings from LaTeX source, which is specific and distinguishes it from sibling tools like get_paper_latex_section (which likely fetches a single section) and get_paper_latex (which likely returns the full source). The verb 'list' and resource 'headings' are precise.

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 for obtaining a structural overview of a paper's LaTeX source, but it does not explicitly state when to prefer this over get_paper_latex or get_paper_latex_section, nor does it mention when not to use it (e.g., for papers without LaTeX source). The sibling names provide some context, but the description itself lacks direct 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?

Beyond the readOnlyHint annotation, the description explicitly says this does not do a live re-fetch, reads from local metadata only, returns an empty list when nothing has been downloaded, and describes the compact mode. These are meaningful behavioral disclosures that help the agent predict behavior without invoking the tool.

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

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

The description is concise, well-structured, and front-loaded with the core action. Every sentence adds value: what is listed, source of data, return fields, compact behavior, empty-list behavior, and workflow placement. No filler or redundancy.

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

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

Given the simple parameter set, readOnlyHint annotation, and absence of an output schema, the description covers what an agent needs to know: what is returned, the data source, the compact option, the empty-list edge case, and the intended workflow. No critical information 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 100% (the compact parameter is fully documented in the schema). The description restates the default and compact behavior but does not add new meaning beyond the schema. Baseline 3 is appropriate because the schema already carries the parameter semantic burden.

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—'List all papers that have been downloaded and stored locally via download_paper'—and explicitly distinguishes it from live re-fetching. It also names the exact fields returned, making the tool's purpose unmistakable and distinct from sibling search/read tools.

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

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

The description gives clear workflow context: 'search_papers -> download_paper -> list_papers -> read_paper', which tells an agent when in the workflow this tool applies. It does not explicitly name when not to use it or point to alternatives like search_papers for live results, but the 'no live re-fetch' phrasing and workflow chain effectively convey the intended 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?

The annotations already indicate this is read-only, and the description reinforces that by noting it does not update last_checked and does not check for new papers. This adds meaningful behavioral clarity beyond what the annotation alone provides.

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

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

The description is concise and well-structured, leading with the core purpose and then adding behavioral notes and sibling references. Every sentence earns its place with no redundant 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?

For a zero-parameter listing tool, the description fully covers what is returned, what it does not do, and how it relates to sibling tools. Nothing essential is missing for an agent to select and 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?

The tool has zero parameters, so there is no parameter behavior to describe. The description appropriately focuses on the semantics of the operation itself, which is sufficient given the empty input schema.

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

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

The description clearly states the tool lists all saved topic watches and explicitly notes it does not check for new papers, which distinguishes it from check_alerts. It also enumerates the returned fields, making its purpose precise 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 gives explicit usage context: use this to inspect saved watches, not to poll for updates. It also names sibling tools for related actions (unwatch_topic and check_alerts), which helps route the agent correctly.

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 adds substantial behavioral detail beyond the readOnlyHint annotation: chunking at ~12,000 characters, continuation via is_truncated and next_start, the return_full_text opt-out, and the failure condition when the paper has not been downloaded. It also covers the typical workflow context, making the behavior predictable.

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 every sentence contributes useful guidance: what the tool reads, how chunking works, how to continue or override truncation, the failure precondition, and the intended workflow. The critical behavior is front-loaded and there is 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?

Despite having no output schema, the description covers the important response behaviors (Markdown, truncation, continuation token) and the prerequisite download step. For a paginated reader tool with no output schema, this provides enough contextual information for an agent to call 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?

Schema coverage is already 100%, but the description adds meaning beyond the schema by explaining the default 12,000 character bound, the fact that start should come from a prior truncated response, and that return_full_text=true retrieves the entire remaining paper. This is exactly the kind of cross-parameter context an agent needs.

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: read the text content of a previously downloaded paper and return it in markdown format. It also distinguishes this tool from download_paper by making the download prerequisite explicit, and the scope is specific enough to separate it from section or abstract readers.

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 tells the agent when the tool can be used: only after download_paper has been called, and it even provides the workflow search_papers -> download_paper -> read_paper. It does not explicitly contrast this tool with sibling alternatives such as read_paper_section or get_paper_outline, which is the only gap.

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 readOnlyHint annotation already covers the safety profile, so the description only needs to add meaningful context. It does add clarity about section boundaries and markdown output, but it does not describe behavior like truncation, the effect of return_full_text, or what happens when the section is not found.

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

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

The description is two short sentences with no filler. The key idea is front-loaded, and the scoping detail about sibling and parent sections adds useful information without 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 read-only tool with fully documented parameters, the description provides enough context: a single markdown section, selected by outline ID or title, without extra surrounding sections. An explicit pointer to sibling alternatives would improve completeness, but the description is not inadequate.

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 input schema already explains all parameters. The description repeats the meaning of section_id as outline ID or unique title, but it provides no additional semantic value beyond what the schema already states.

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

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

The description clearly identifies the action (return), the resource (one bounded markdown section), and the selector (outline ID or unique title). It also differentiates from full-paper or outline-related siblings by stating that sibling and parent sections are not included.

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 for retrieving a single section rather than an entire paper, but it does not explicitly state when to choose it over alternatives like read_paper, get_paper_outline, or get_paper_latex_section. The boundary statement is useful but not a full usage guideline.

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 the tool is not read-only and not destructive, so the description need not restate those. It adds useful scoping (local, downloaded papers), but it does not disclose the default behavior of clear_existing (default true) or potential side effects like deletion of the existing index before rebuild. This is a moderate addition 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 entire description is a single sentence that directly states the action and scope without unnecessary words. It is concise and well-structured.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the basic function. However, it omits important context such as the default clear_existing behavior, expected use cases, and potential time cost, making it minimally adequate but lacking full completeness.

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

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

The schema fully describes the only parameter, clear_existing, including its type and default value. The description adds no further parameter-level details, so it does not compensate beyond the schema's 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 uses the specific verb 'Rebuild' and identifies the resource 'local semantic index' for 'downloaded papers', which clearly defines the tool's scope. This distinguishes it from siblings like search_papers and semantic_search, which operate on the index rather than rebuild it.

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 no guidance on when to use this tool or alternatives. It does not mention prerequisites (e.g., after adding new papers) or contrast with other maintenance operations. Users are left to infer the appropriate 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 indicate readOnlyHint=true, and the description aligns by stating this is a search operation. It goes beyond annotations by disclosing arXiv rate limiting (~3s between requests), retry behavior for transient 429/503 errors, persistent rate limits returning status=rate_limited, and pagination behavior via next_start. It also documents default abstract_mode and truncation 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 dense but well-organized, with key behavioral details front-loaded. It covers many aspects (syntax, categories, dates, sorting, defaults, pagination, rate limits) without excessive verbosity. Some details like the rate-limit note could arguably be moved to a 'Notes' section, but overall it's efficiently structured and every sentence provides actionable information.

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

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

Given the tool has 8 parameters, no output schema, and a rich behavioral profile, the description is quite complete. It covers query construction, pagination, result metadata fields, and error/rate-limit behavior. It doesn't explicitly describe the full response shape beyond those fields, but given the lack of an output schema, this is a minor gap. The description leaves little room for an agent to call incorrectly.

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 all parameters are individually documented. The tool description adds value beyond the schema by explaining the overall query behavior (unprefixed terms match title+abstract, not authors) and by reinforcing the pagination contract (pass next_start with same abstract_mode). The description doesn't introduce new parameter dimensions but meaningfully supplements the schema.

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

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

The description clearly states the tool's function: searching arXiv by query with optional filters and pagination. It explicitly covers the search syntax, categories, date range, sorting, and output controls. This distinguishes it from sibling tools like semantic_search, get_abstract, and list_papers, which serve different retrieval purposes.

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

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

The description provides explicit usage guidance including query syntax tips (prefer quoted phrases, field prefixes), category recommendations, date format expectations, and default/limit values. It also directs use of get_abstract after compact search rather than after abstract_mode=full, giving clear when-to-use context. Sibling differentiation is implicit through this comprehensive guidance.

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

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

Given annotations only provide readOnlyHint=true, the description adds valuable non-obvious behaviors: suppression of high-overlap near-duplicates, preference for section-diverse hits, and the use of bounded substring matching. It does not fully describe the output format or error conditions, but what it provides goes clearly 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 tightly written in three sentences with no wasted repetition. The core purpose is front-loaded, then the deduplication/diversity behaviors are added, and finally the technology-focused scoping is stated. Each sentence contributes useful selection and invocation 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 read-only search tool, the description covers the main behaviors: scope to downloaded papers, substitution search, bounded results, section offsets, and near-duplicate suppression. It does not explicitly describe failure behavior for missing downloads or give a detailed return shape, but with no output schema and a simple matcher, the provided context is largely sufficient.

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

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

The schema already covers all 4 parameters at 100%, including case-insensitive substring behavior and default values for max_passages and passage_chars. The description adds context about bounds and diversity but does not need to restate parameter details; the baseline 3 applies.

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

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

The description states a specific action — searching a downloaded paper for bounded matching passages with section/source offsets — which clearly defines what the tool does. It also differentiates via 'substring search' and 'no Torch' from semantic_search and search_papers siblings, making the tool's specific role apparent.

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

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

The description gives clear context: it is for substring search within a single downloaded paper, implying use when the agent needs exact lightweight matching rather than semantic similarity or cross-paper search. However, it does not explicitly name alternatives or state when not to use the tool, so it stops slightly short of full usage routing.

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 annotations already establish read-only and local-only behavior, and the description adds important operational context beyond them: empty results when no papers are downloaded, plus the required pro dependency installation command. This is valuable behavioral information for an agent deciding whether the tool is available and what preconditions apply.

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 efficient and front-loaded. It leads with the core scope, then the important failure condition, then the prerequisite workflow, and finally the installation dependency. Each sentence adds genuine information without 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 search tool with no required parameters and only three well-documented schema properties, this description covers the critical information: preconditions, empty-result behavior, supported query modes, and the needed setup command. No output schema is present, but return-value shape is not a blocker for correct invocation.

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

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

The schema already describes all three parameters with 100% coverage, so the description is not required to explain them. It adds value by giving a concrete free-text example and clarifying that query and paper_id are the two supported semantic-search modes.

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

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

Clearly states a specific operation — semantic similarity search — and scopes it to papers already downloaded locally via download_paper. It identifies two query modes (free-text or paper_id) and is immediately distinguishable from sibling tools like search_papers and search_paper_text.

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 explains when the tool returns empty results, recommends search_papers to discover arXiv papers, then download_paper to add them to the local index before semantic_search. This gives the agent a clear workflow and names the alternative 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation is known. The description adds value beyond that by disclosing the exact-match requirement and the explicit not-found error behavior, which are behavioral details not present in 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?

Three short sentences, each carrying unique value: the main action, the matching constraint, and the error/fallback behavior. Ends with a pointed pointer to list_watches, with zero filler 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?

For a single-param delete tool, the description covers the core behavior, the error path, and the recommended pre-use step. The lack of an output schema is partially offset by the not-found error description; the only minor gap is the success return shape, which is not critical given the low 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 coverage is 100%, so the schema already documents the topic parameter well. The description reinforces the exact-match concept and the relationship to watch_topic, but adds no new parameter syntax, formatting, or constraint 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?

States the verb 'Delete' with a precise resource ('saved topic watch') and the exact matching mechanism. This clearly distinguishes it from siblings like list_watches (inspect) and watch_topic (create), so an agent knows which tool to pick.

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 concrete guidance: 'Use list_watches to inspect saved watches before deleting,' which is a practical pre-step and names the relevant sibling. It stresses the exact-match prerequisite but doesn't explicitly cover when-not-to-use scenarios relative to other siblings like check_alerts, so it stops at clear context with no exclusion list.

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 only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining the mutation profile — and it does so richly. It discloses the last_checked seeding side-effect ('first check does not dump historical matches'), the upsert semantics, and the subtle update behavior for categories ('omit categories to preserve existing filters; pass categories: [] to clear them'). This goes well beyond what annotations provide and flags exactly the behaviors an agent could not infer from the schema alone.

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?

Seven sentences, and every one earns its place: purpose, check_alerts behavior, first-check seeding, query syntax, upsert semantics, category-update gotcha, and integration pairing. The most decision-relevant information is front-loaded, and the length is justified by the tool's genuinely subtle stateful semantics. There is zero filler 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 stateful tool with no output schema and only three boolean annotations, the description covers nearly everything an agent needs: lifecycle behavior, first-run nuance, update semantics, query syntax, and the companion tool. The only notable gap is that it describes what check_alerts returns but never states what watch_topic itself returns on success (acknowledgment, watch object, etc.), which the absence of an output schema makes more consequential.

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 schema already documents topic syntax, category update semantics, and max_results default. The description adds some value by providing two concrete query examples with field specifiers and boolean operators, and it reinforces the categories-preservation rule. But it largely restates what the schema already says and adds nothing new about max_results, so it does not rise above the baseline.

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

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

The opening verb-resource pair 'Save or update a persistent research topic watch' is specific and precise, and the tool's role is further differentiated from siblings by explaining it 'returns only papers published since the last check' when polled via check_alerts. It also distinguishes itself from search_papers by noting the shared query syntax while making clear this is a persistent standing alert, not a one-off search. The upsert behavior ('same topic string updates the existing watch rather than creating a duplicate') removes any ambiguity about what calling this tool does.

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 integration context ('Pair with check_alerts to poll for new papers') and explains when the tool behaves differently on first use versus updates, which helps the agent choose correctly. It references search_papers for query syntax, implicitly distinguishing one-off searches from standing alerts. However, it never explicitly states 'use search_papers instead for a one-off search' or names when NOT to use watch_topic, so the exclusion logic is left slightly to inference.

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