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

Discloses the timestamp update side effect, the incremental nature of results ('subsequent calls only return newer papers'), and the return structure. Annotations indicate readOnlyHint, and the description does not contradict this; it clarifies the side effect is metadata-only. This goes beyond surface-level description.

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?

Four concise sentences, each adds critical information. No redundancy, front-loaded with the main purpose, then covers parameters, side effects, prerequisites, and output. Efficient and 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 read-only tool with one optional parameter and no output schema, the description covers prerequisites (watch_topic), behavior (timestamp update), and return value (summary + metadata). The context is complete for an agent to use 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?

Only one parameter, fully described in schema. The description adds value by explaining the exact matching requirement ('must match the topic string used in watch_topic exactly') and the behavioral difference between omitting vs. providing it. Coverage is 100%, so the description enriches but doesn't need to compensate.

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 specific language: 'Check all saved topic watches for newly published papers' with clear scope. It distinguishes itself from siblings by focusing on saved watches rather than general search or retrieval. The optional topic parameter is explained with behavior.

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

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

Provides clear when-to-use guidance: 'Omit to run all watches, pass a topic to check only that watch.' Also explicitly directs users to call watch_topic first. It lacks an explicit alternative tool comparison but the contextually relevant usage is well covered.

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 openWorldHint, so the bar is lower. The description adds value by specifying that it returns both citing and referenced papers, which is not in the annotations. It doesn't mention pagination or output format, but with annotations covering safety, this is adequate.

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

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

The description is a single, direct sentence with no filler. Every word contributes to conveying the tool's function, making it highly concise and front-loaded.

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

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

Given the tool's simplicity (one parameter, read-only, open-world), the description is sufficient. It could specify the return format (e.g., list of paper objects), but that is not critical given the context. A 4 reflects minor additional detail that could be helpful.

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% with a clear description for paper_id, so the schema already documents the parameter. The tool description does not add any extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Return') and a clear resource ('papers citing an arXiv paper and papers that it references'), explicitly distinguishing this tool from siblings like search_papers (search) or read_paper (content access). It unambiguously states the tool's scope.

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

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

The description clearly indicates when to use the tool: when citation or reference information is needed. It does not explicitly contrast with alternatives or say when not to use it, but the purpose is self-evident given the sibling 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 indicate readOnlyHint=false and openWorldHint=true, but the description adds specific behavioral details: it stores the paper locally (a side effect), tries HTML first then falls back to PDF, and supports start/max_chars pagination. This goes beyond the annotations to clarify the tool's non-read-only nature and practical behavior.

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

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

The description is two sentences, front-loaded with the main purpose, and each sentence earns its place by covering core behavior, fallback strategy, storage side effect, and pagination. No redundant or filler content.

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

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

For a tool with no output schema, the description adequately states the return type ('text content'), explains side effects (local storage), and covers pagination for large papers. It lacks details on error behavior, rate limits, or output format nuances, but the openWorldHint annotation mitigates this, making the description reasonably complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minimal value by mentioning 'start/max_chars pagination,' but this concept is largely already stated in the schema (e.g., 'Zero-based character offset' and 'Maximum raw paper characters'). It provides no new details about paper_id beyond what's in 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+resource: 'Download a paper from arXiv and return its text content.' It clearly distinguishes from siblings like read_paper by mentioning it stores the paper locally and uses HTML/PDF fallback extraction, making the tool's unique purpose evident.

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 clear context on when to use this tool (for downloading and obtaining text content with pagination) but does not explicitly compare it to alternatives like read_paper. It implies usage for full paper retrieval and handling large papers, which is a clear situational context, yet lacks explicit 'when not to use' guidance.

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

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

With readOnlyHint=true already providing the safety profile, the description adds context by emphasizing the tool does not download the full paper and returns listed metadata fields. This goes beyond annotations and helps the agent understand the tool's behavior, though it does not cover error cases or rate limits.

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

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

The description is concise and well-structured: a clear opening sentence, usage guidance, return summary, and a workflow tip. Every sentence adds value, with no wasted words 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?

For a simple one-parameter tool with good annotations, the description is complete. It explains the purpose, usage context, returned data, and workflow placement, leaving no significant gaps. The lack of an output schema is mitigated by the explicit list of returned fields.

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

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

Schema coverage is 100% and the single parameter paper_id is well described. The description only restates that the tool fetches by ID, adding no extra syntax or format details beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Fetch') and identifies the resource ('abstract and metadata of an arXiv paper by ID'), clearly distinguishing it from download_paper by explicitly stating it does NOT download the full paper. It also names the metadata returned, making its 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 explicitly tells the agent when to use this tool: 'Use this before download_paper to assess relevance and save tokens.' It also provides a concrete workflow (search_papers -> get_abstract -> download_paper -> read_paper), making the usage context and alternatives very 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?

The description discloses the edge case of an empty list when no papers are downloaded, and clarifies that only arXiv IDs are returned, not full text. With minimal annotations (readOnlyHint only), this adds valuable behavioral context without contradiction. It sets expectations for the response format and the need to call read_paper for content.

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 very concise, using three short, information-dense sentences plus a workflow arrow. Every sentence adds value with no redundancy or fluff.

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

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

For a zero-argument tool with no output schema, the description covers everything an agent needs: what is listed, the output format, edge case behavior, and the surrounding workflow context. No further details are required.

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?

There are zero parameters, so the schema fully documents the interface. The baseline for no parameters is 4, and the description adds no parameter-specific details because none are needed. It doesn't detract, hence a 4.

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

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

The description clearly states the tool lists downloaded papers and explicitly notes the return type (arXiv IDs only) and differentiates from related tools by directing to read_paper for content. The workflow arrow further situates the tool in the pipeline, leaving no ambiguity about its purpose.

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

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

The description explicitly provides a workflow (search_papers -> download_paper -> list_papers -> read_paper) and tells the user when to use an alternative ('use read_paper to access content'). This serves as both when-to-use and when-not-to-use guidance, going beyond a simple definition.

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 provide readOnlyHint=true, and the description adds substantial behavioral context: it returns markdown, supports start/max_chars pagination for large papers, and fails with a clear error if the prerequisite download is missing. This goes well beyond annotation-only information.

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 sentences, each contributing: purpose, return format and pagination, and prerequisite workflow. Information is front-loaded and there is no redundancy.

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

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

The tool is moderately simple, but with no output schema, the description compensates by stating return format (markdown) and pagination. It lacks details on what the markdown includes (e.g., figures, references) but is otherwise complete for the workflow.

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

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

Input schema covers 100% of parameters with clear descriptions for paper_id, start, and max_chars. The description mentions pagination but adds no new meaning beyond the schema; it is a fair baseline given full 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?

‘Read the text content of a paper’ clearly states the verb and resource. It explicitly distinguishes from siblings like download_paper (which fetches) and get_abstract (which reads only the abstract), and specifies the markdown output and pagination support.

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 says to call download_paper first and gives a workflow: search_papers -> download_paper -> read_paper. It also warns about failure if the paper is not downloaded, making the usage context crystal 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?

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?

Adds behavioral details beyond annotations: default sort is relevance, rate limiting is auto-handled, and on rate limit error wait 60 seconds. Aligns with readOnlyHint and openWorldHint. No contradiction, but lacks explicit statement about output format (no output schema exists).

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?

Description is long but well-organized with clear sections (Query Construction, Advanced Patterns, Category Filtering, etc.). Each section adds value, though some examples could be trimmed without loss. Front-loads purpose effectively.

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 search tool with 6 parameters and no output schema, the description is exceptionally complete: covers query optimization, category catalogs, date ranges, sort options, rate limits, and research tips. Provides all necessary context for effective usage.

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

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

Schema covers 100% of parameters, but description massively enriches semantics: detailed query syntax with quoted phrases, OR, ANDNOT, field-specific searches, category code expansions with meanings, date format examples, and optimal parameter usage patterns. Far exceeds schema descriptions.

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

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

Description clearly states 'Search for papers on arXiv with advanced filtering and query optimization' – a specific verb+resource with explicit scope. It distinguishes from siblings like get_abstract and read_paper by emphasizing search and filtering.

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?

Extensive guidelines cover query construction, field-specific searches, category filtering, date filters, sort selection, and rate-limiting behavior. It gives explicit advice on when to use relevance vs. date, and when to use category filters, making tool selection and invocation 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?

Annotations already indicate read-only and closed-world hints, but the description adds critical context: it only searches the local downloaded collection, returns empty results if no downloads exist, and requires pro dependencies with an install command. This goes beyond the annotations and provides valuable behavioral expectations.

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: the first sentence states purpose, the second flags a critical limitation, and the third provides workflow and installation context. Every sentence earns its place with no redundancy or fluff.

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

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

For a read-only search tool with no output schema and high-quality annotations, the description covers purpose, scope, limitations, prerequisites, and usage workflow. It is complete enough for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, so parameter descriptions already provide clear semantics. The description adds an example query and frames query vs. paper_id as alternatives, but does not significantly extend beyond the schema. It meets the baseline for a covered schema without adding substantial new 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?

The description clearly states the tool performs semantic similarity search over papers already downloaded locally via download_paper, using specific verbs and identifying the resource. It distinguishes itself from siblings by contrasting with search_papers (arXiv-wide search) and download_paper (fetching 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?

Usage guidance is explicit: the tool only searches the local collection, returns empty if no papers are downloaded, and provides a concrete workflow (use search_papers, then download_paper). It also states the pro dependency prerequisite. This clearly explains when to use it versus alternatives.

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

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

The description adds meaningful behavioral detail beyond annotations: it is persistent, returns only new papers since last check, and updates existing watches. It also explains the query syntax compatibility with search_papers. This goes beyond the minimal readOnly/destructive hints provided.

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

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

The description is concise and well-structured. It front-loads the core purpose, then adds usage context, examples, and an important behavioral caveat (update vs duplicate). Every sentence contributes essential 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?

Given that this is a stateful tool with no output schema, the description does a good job explaining the persist-and-poll workflow, query syntax, and update behavior. It lacks explicit error conditions or return format, but the 'returns only papers published since the last check' covers the key output behavior.

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

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

The input schema fully describes all three parameters, but the description adds value by explaining the 'same query syntax as search_papers' and giving concrete examples. It also clarifies the update semantics of the topic parameter, which is not in 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+resource: 'Save or update a persistent research topic watch.' It clearly distinguishes from sibling tools like check_alerts (which polls) and search_papers (which performs one-off searches) by framing it as a standing alert mechanism.

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

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

It explicitly explains when to use it (to create a standing alert) and pairs it with check_alerts. It also clarifies that calling with the same topic updates rather than duplicates. It does not explicitly say when not to use it versus search_papers, but the context is clear.

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