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

Beyond annotations (readOnlyHint=false, destructiveHint=false), description discloses mutation, auto-save to library, idempotency, and API key requirement. 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?

Every sentence is informative: action, addressing method, nesting, mutation note, idempotency, authorization. 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?

Covers purpose, parameters, side effects, idempotency, and authorization. Output schema exists, so return values are not required. Complete for a mutation tool.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning: get-or-create by name, nesting with '/', and that collection_id or collection_name are alternatives. Adds value beyond 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?

Clearly states verb (Add), resource (paper to collection), and addressing method (by id or name, with get-or-create by name). Distinguishes from siblings like create_collection and remove_from_collection.

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 context on when to use (adding paper), mentions get-or-create behavior, auto-save, idempotency, and required API key. Does not explicitly state when not to use, but context is 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 readOnly=true and destructive=false. Description adds 'Read-only', API key requirement, usage limits, and citation format. No contradictions.

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 fairly long but every sentence adds value. Front-loaded with core purpose, then usage details and limitations. Not overly verbose.

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 output schema present, description doesn't need return values. It covers purpose, scope, limitations, and contrast well. Could mention citation format earlier, but overall 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 coverage is 100%, so description adds only marginal value (e.g., clarifying collection options). Baseline of 3 is appropriate; no significant new semantics beyond 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 answers a question using only saved papers with inline citations, distinguishing it from find_gaps. The verb 'answer' and resource 'library/collection' are specific.

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

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

Provides explicit when to use (synthesis over library) and contrasts with find_gaps. Mentions optional scoping and limitations (free vs Pro). Lacks explicit 'when not to use' but sibling context is 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?

Description adds significant value beyond annotations: it states read-only, idempotent, no watermark advancement, safe to call repeatedly. Annotations only had readOnlyHint=true and destructiveHint=false; description enriches with operational details.

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

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

Three concise sentences pack essential information: purpose, scoping, behavioral safety. No fluff; every sentence earns its place.

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

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

Covers key aspects: return shape, optional scoping, idempotency, auth requirement. Output schema exists so no need to describe return values. Adequate for a read-only list tool with good annotations.

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

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

With 100% schema coverage, description adds the mutual exclusivity of watch_name and watch_id and the default behavior of 'all watches'. This clarifies parameter usage beyond schema descriptions.

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

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

The description clearly states the tool pulls new matching papers since last digest delivery, specifying the verb 'pull' and resource 'watches'. It distinguishes from siblings like 'list_watches' by focusing on new results.

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

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

It provides clear context for when to use ('in-session anything new on my watches?') and notes that it does not advance watermark, implying repeated safe calls. It explains scoping options but doesn't explicitly contrast with sibling tools.

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

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

Annotations already indicate readOnlyHint and destructiveHint, but the description adds important behavioral details: returns specific edge fields, default window_years=10, result capped at 500 edges sorted by papers_count DESC. There is no contradiction with annotations.

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

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

The description is concise (two sentences), front-loads the purpose before details, and contains no unnecessary words. Every sentence adds value.

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

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

Given that the output schema exists (covering return fields), the description adequately explains the purpose, parameters, behavioral constraints, and use cases. No gaps are present.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes beyond schema by advising to 'Get author IDs via the find_author tool' for author_ids, and clarifying the window_years' default and maximum values, which adds practical context.

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

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

The description clearly states the tool's purpose: 'Find the co-authorship neighborhood of one or more authors.' It specifies the action ('find') and resource ('co-authorship neighborhood'), and distinguishes from sibling tools like 'find_author' and 'search_papers' by focusing on relationships between authors.

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 use cases: 'AC reviewer triage, disambiguating researchers, expanding an author seed.' While it doesn't explicitly state when not to use the tool, the given contexts are clear and helpful for an AI agent to decide when to invoke this 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?

Discloses mutation (MUTATES), get-or-create idempotency, and folder derivation from name. Annotations already hint non-read-only and non-destructive; description adds concrete details like 'never errors on duplicate' and auth requirement.

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, front-loaded with clear purpose, no unnecessary words. Each sentence adds critical information: function, mutation, idempotency, nesting, and auth.

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 one parameter, annotations, and an output schema, the description covers all necessary context: behavior, naming rules, auth, and duplicate handling. No gaps.

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

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

Single parameter 'name' is fully described; schema coverage is 100% but description adds value by explaining nesting convention with '/', which is not evident from schema alone.

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

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

The description clearly states the tool creates a new named collection, specifies mutation behavior, and distinguishes from siblings like list_collections and add_to_collection by explaining get-or-create and nesting.

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

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

Provides explicit usage context: when to create a collection, behavior on duplicates, nesting with '/', and required auth key. Implicitly suggests when not to use (e.g., if you need to list collections, use sibling).

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 mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description explicitly states 'MUTATES' and explains idempotency via get-or-create by name. It also discloses daily evaluation, email digest integration, and requirement for SF_API_KEY, providing full behavioral context beyond annotations.

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

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

The description is well-structured with clear segments, bullet points, and front-loaded purpose. While somewhat lengthy, the complexity of the tool (11 parameters, nested objects) justifies the length. Every sentence adds value, and the structure aids readability.

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, the description covers purpose, behavior, prerequisites (API key), forms, idempotency, and references to sibling tools. The input schema has full parameter descriptions, and an output schema exists. No gaps remain for an agent to make informed decisions.

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 with individual descriptions. The description adds significant value by explaining the relationship between criteria and single-selector seeds, detailing the collections relation (e.g., similar floor notes), and providing strategic usage hints. However, most parameter meaning is already in the schema, so the incremental value is moderate.

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

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

The description clearly states the tool creates a standing watch that is evaluated daily and surfaces matches via email and check_watches. It specifies the verb ('create'), resource ('watch'), and scope ('standing watch evaluated daily'), distinguishing it from sibling tools like update_watch, delete_watch, and check_watches.

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 guidance on when to use the tool, including two forms (v2 structured vs legacy), recommending structured form, advising preview_watch before creation, and noting get-or-create behavior. It mentions alternatives like update_watch and preview_watch, but does not systematically list all when-not scenarios (e.g., if you only need to read, use list_watches). Still, it offers substantial contextual 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?

Annotations already indicate destructiveHint=true, but description adds idempotency detail and auth requirement, which are valuable beyond annotations. 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?

Three sentences, each essential: purpose, idempotency, alternative tool, auth. No wasted words, 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?

Output schema exists, so return values not needed. The description covers purpose, idempotency, alternative, auth. Complete for a simple deletion tool.

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

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

Schema descriptions already cover both parameters (name and watch_id) with mutual exclusivity. The tool description adds minimal new info ('addressed by watch_id OR name') over the 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 'Delete a watch' with specific verb and resource. It distinguishes from sibling tools like update_watch by noting that update_watch should be used for modifications instead of delete-and-recreate.

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 states idempotent behavior (deleting non-existent watch is no-op) and advises using update_watch for changes. Also notes auth requirement (SF_API_KEY).

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 valuable behavioral context beyond annotations: cost ($0.0001/call), rate limits (30/min), auth constraints (403 for free), model (Gemini Flash), and vector dimension. No contradiction with annotations (readOnlyHint=true, destructiveHint=false).

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?

Single dense paragraph with no fluff, front-loaded with core action, and efficiently uses every sentence to convey purpose, use cases, and constraints.

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 2-param tool with output schema, the description covers purpose, usage, auth, cost, rate limits, and even a workflow example. No gaps identified.

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 good descriptions, but the description adds context on HyDE workflow and default task_type purpose, enhancing understanding beyond the schema.

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

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

The description clearly states 'Embed a text string into a 768-dim Gemini Flash vector' and explains the HyDE retrieval use case, distinguishing it from sibling tools which are different actions (search, collections, etc.).

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 to use each task_type (RETRIEVAL_DOCUMENT for HyDE, RETRIEVAL_QUERY for direct queries) and mentions authentication requirements (Pro-only, SF_API_KEY). Could be more explicit about alternatives, but sibling tools are clearly different.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds significant behavioral context beyond that: character limits for each mode, number of table captions, coverage percentage, and expected latency ('may take a few seconds'). This provides a comprehensive understanding of the tool's 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 four sentences long, front-loaded with the core purpose, and every sentence adds value. No redundant or vague phrases. It efficiently covers purpose, modes, specifics, coverage stats, and performance.

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 moderate complexity (two modes, character limits, table captions) and the presence of an output schema (so return values are handled elsewhere), the description is complete. It addresses parameters, behavior, limitations (coverage percentage), and timing, leaving no major gaps.

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

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

Schema coverage is 100% (both parameters described in schema). The description adds meaning by specifying the default value for 'sections' ('results'), providing details on returned characters and table captions per mode, and clarifying the content of each mode. This goes beyond the schema's enum values.

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 verb 'Extract' and the resource 'paper content from an arXiv paper's LaTeX source', making the purpose immediately obvious. It distinguishes itself from sibling tools which are about collections, watches, searches, and other operations, not content extraction.

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 explains two modes with specific use cases ('results' for lean results, 'all' for full paper) and mentions that ~62% of arXiv papers have LaTeX source, implying when the tool may not work. However, it does not explicitly exclude other use cases or mention alternatives, so a 4 is appropriate.

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

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

Describes matching methods (embedding similarity for topics, fuzzy matching for names) and details the return structure for both modes. Annotations already indicate readOnlyHint, and description adds behavioral context without 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?

Single coherent paragraph, front-loaded with mode distinction, efficient wording, no redundancy. Every sentence adds value.

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

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

Given the tool's two modes, four parameters, and existence of an output schema, the description adequately covers both modes' usage, return values, and parameter constraints without being overly verbose.

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%, baseline 3. Description adds value by explaining mode-specific applicability of parameters (e.g., field and limit for q-mode only) and providing examples, but does not add deep semantic nuance beyond 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 it is a two-mode tool (search by topic/name or lookup by ID), replaces two other tools, and distinguishes its function from siblings like co_author_graph.

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

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

Explicitly instructs to provide exactly one of q or id, and notes that field and limit apply only to q-mode. Also mentions that IDs come from q-mode or co_author_graph.

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 declare readOnlyHint=true and destructiveHint=false, and the description reinforces 'Read-only.' It explains the backend process: 'derives the niche, runs lineage + recent-novelty search, subtracts your saved set.' No contradictions, and additional context (API key requirement, Pro feature) is provided.

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

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

Five well-structured sentences front-load the purpose and then detail usage. Every sentence adds essential information; no unnecessary words or repetition.

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

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

Given the tool has 5 parameters (none required), high schema coverage, and an output schema exists, the description covers the key behavioral aspects: seed specification, scope, limit, API key requirement, and Pro feature. Slight deduction for not mentioning the output schema explicitly, but the description is still complete enough for correct tool use.

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 baseline is 3. The description adds value by explaining mutual exclusivity of seed parameters ('Provide exactly one seed') and clarifying the scope enum values ('foundational,' 'frontier,' 'both'). This goes beyond the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Find important work you HAVEN'T saved, for a collection or topic — a 'what am I missing?' analysis.' It precisely identifies the two output buckets (foundational_gaps and frontier_gaps) and distinguishes this tool from siblings like search_papers or list_library by focusing on missing works.

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

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

Provides explicit usage constraints: 'Provide exactly one seed: collection_name OR collection_id OR topic.' It mentions the need for SF_API_KEY and that it's a Pro feature. While it doesn't explicitly state when not to use it or list alternatives, the guidance is clear and actionable.

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=true and destructiveHint=false. The description adds valuable behavioral details: sorting by citing-paper rank_score, default response shape (lean 12-field vs full 28-field with verbose), and the interaction between fields and verbose. No contradictions.

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 distinct purpose: main action, direction explanation, response shape details. Front-loaded with the primary purpose, no fluff.

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

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

Given the complexity (citation graph, directions, sorting, response shape options) and the presence of an output schema covering return values, the description provides sufficient context. It could mention rank_score's meaning, but overall it's complete enough.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds semantic value beyond the schema by specifying the sorting order (by rank_score), clarifying the direction enum values, and explaining the verbose/fields default behavior.

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

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

The description clearly states the tool retrieves the citation graph for a paper, and distinguishes between 'citing' and 'cited_by' directions. It uses a specific verb ('get') and resource ('citation graph'), and implicitly differentiates from sibling tools like search_papers or co_author_graph.

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

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

The description explains when to use each direction ('citing' = references, 'cited_by' = citations) and how to get more fields (verbose=true). It does not explicitly mention when not to use this tool or alternatives, but the context is clear enough for typical use.

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, destructiveHint), it discloses ranking blend (0.6 citation count, 0.4 semantic similarity), that it's cheap retrieval with no synthesis, and no LLM calls made. No contradiction with annotations.

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

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

Four sentences, well-structured with main action first, then ranking details, use case, and alternative. No unnecessary 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?

Covers purpose, usage, behavior, parameters, and alternatives. Tool has output schema, so return value explanation is not needed. Complete for a tool of this complexity.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds little beyond schema: it reinforces topic specificity and limit for candidate count, but does not introduce new parameter meaning beyond what's in 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?

Description clearly states the tool returns candidate foundational papers for a research topic, using specific verb 'returns' and specifying 'candidate foundational papers'. It distinguishes from siblings by contrasting with the /field-guide skill that provides synthesis.

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

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

Explicitly tells when to use (bootstrap a literature survey, get fast landscape sense) and when to use alternative (for synthesized report, use /field-guide). Also notes it requires no Pro API key, implying low cost.

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=true, destructiveHint=false), the description adds behavioral traits: explains the three-tier structure (niche_roots, field_level, discipline) and states 'No Pro key and no LLM calls required'. No contradiction with annotations.

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

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

The description is detailed and front-loaded with the core purpose, then elaborates on the tiers and usage. It is slightly wordy but every sentence adds value. Could be trimmed slightly without losing clarity.

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

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

Given the complexity (4 parameters, output schema exists, annotations present), the description is fully adequate. It explains the output tiers, evidence, usage, and alternatives. No gaps remain for correct tool 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 the schema already documents all parameters. The description provides context on how parameters like scope and generality_ceiling affect the niche analysis, but this is supplementary rather than essential for understanding parameter 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 explicitly states it returns foundational work for a paper's niche via the citation graph, with three tiers. It distinguishes itself from the sibling tool get_field_orientation by noting that tool is topic-anchored and retrieval-only.

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 advises using the tool to trace prior art/lineage for a paper or find canonical methods a niche is built on. It mentions the complementary relationship with get_field_orientation, providing context, though it does not explicitly state when not to use it.

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

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

Annotations indicate read-only safety; description adds batch limits, NULL handling for older papers, behavior of verbose and fields parameters, and bibtex mode restrictions.

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?

While well-structured and informative, the description is verbose, repeating replacement tool mentions and listing many fields inline. Could be tighter.

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

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

Covers all aspects: batch limits, format options, default/verbose shapes, field selection, edge cases (NULL for older papers), and relationship to siblings.

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

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

Schema coverage is 100%, but description adds significant meaning: default vs verbose shapes, specific field names, impact score interpretation, and bibtex behavior.

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

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

The description clearly states the tool gets full details for papers by arXiv ID, distinguishes from siblings like fetch_fulltext and search_papers, and explains replacement of removed 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?

Explicit guidance on single vs batch, bibtex mode, verbose vs default, and field selection. Notes bibtex is single-paper only and suggests fetch_fulltext for full text.

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 a non-read, non-destructive write. The description adds valuable behavioral details: idempotent, no un-like behavior, and that it calibrates a personalized feed. 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?

Two sentences, each packed with essential information. No fluff. Front-loaded with the primary purpose, followed by behavioral and guidance details. Efficient structure.

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 parameter, the description covers purpose, behavior, usage boundaries, and a prerequisite (API key). With output schema present (though not detailed here), the description is complete and 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?

Input schema has 100% description coverage with a clear description for the single parameter 'arxiv_id'. The tool description does not add additional parameter-level meaning beyond what the schema provides, 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?

Clearly states the verb ('like a paper') and resource ('paper'), and distinguishes from sibling 'save_paper' by explaining the difference in function (taste vs bookmark). Also frames it as a calibration signal for the For You feed. Purpose is specific and well-differentiated.

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 states that the operation is INSERT-only and idempotent (liking twice is a no-op, never un-likes). Distinguishes from save_paper with clear when-to-use guidance. Also notes the requirement for SF_API_KEY, providing essential usage context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds 'Read-only' (redundant) and mentions 'with paper counts' which adds minor context. Not substantial 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?

Three sentences, each adds value. First sentence core action, second read-only, third usage context and requirement. 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?

For a 0-parameter tool with output schema, description covers purpose, usage guidance, and return detail (paper counts). Sufficient for agent to select and invoke.

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

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

No parameters, schema coverage 100%. Baseline 4 applies. Description doesn't need to add parameter info.

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 'List the authenticated user's collections (named groups of saved papers) with paper counts.' Specifies verb and resource, and distinguishes from siblings like create_collection and add_to_collection.

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 says 'Use before add_to_collection to see existing collections.' Provides a specific use case and mentions prerequisite 'Requires SF_API_KEY'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds 'Read-only' consistency and 'Requires SF_API_KEY' for authentication. Discloses ordering behavior 'newest first'.

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

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

The description is two concise sentences plus two short phrases, totaling 33 words. Every sentence adds value and it's 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?

With output schema present, description doesn't need to explain returns. Covers purpose, usage, authentication, and ordering. Complete for a simple list tool with good annotations.

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 descriptions for both parameters. The description does not add meaning beyond the schema, so 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 clearly states the verb 'list', the resource 'the authenticated user's saved papers (their library)', and the ordering 'newest first'. It distinguishes from siblings like save_paper, unsave_paper, etc.

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 says 'Use this to review a reading list or to see what's already saved before saving more.' Provides clear context for when to use, though lacks explicit when-not-use statements.

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 destructiveHint false, so the agent knows it's safe. The description adds value by explicitly stating 'Read-only' and listing the returned fields, but does not discuss potential pagination, rate limits, or other behavioral details. Given annotation coverage, 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 four short sentences, each adding distinct value: what is listed, read-only status, usage advice, and authentication requirement. No redundancy or fluff. Front-loaded with the core purpose.

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 no parameters but has an output schema, the description effectively covers what the tool returns (listing fields), when to use it (before create_watch), and prerequisites (SF_API_KEY). The presence of an output schema means return values are covered. This is complete for a list tool with good annotations.

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

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

The tool has zero parameters, and the description does not need to explain parameters. According to guidelines, 0 parameters warrants a baseline score of 4. The description adds no parameter info, which is appropriate.

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

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

The description clearly states the tool lists watches with specific fields (name, definition, last_evaluated_at, pending_hits). The verb 'list' and resource 'watches' are unambiguous. It also distinguishes from sibling tool create_watch by suggesting its use beforehand.

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 advises using this tool before create_watch to see existing watches, providing a direct usage context. It also notes the requirement for SF_API_KEY. However, it does not mention when not to use it or compare with other siblings like check_watches or preview_watch.

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 destructiveHint. The description adds crucial context: match_count saturation at 200, return fields, default ranking, impact model, and read-only behavior. No contradictions.

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 detailed and front-loaded with the core purpose. Though slightly lengthy, it is well-organized and every sentence adds important context, making it effective for agent comprehension.

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 nested parameter, output schema exists, and complexity of ranking options, the description is fully complete. It covers limitations, ranking behavior, ties to create_watch, and how to interpret results, leaving no gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the criteria object's role, default recency_days, and the relation field's note about collections and similar predicate, going beyond schema definitions.

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

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

The description clearly states the tool's purpose: dry-run a structured filter without creating a watch, positioning it as part of a tuning loop. It differentiates from sibling create_watch by emphasizing preview and iteration.

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 explains when to use: iterate before saving with create_watch. It provides guidance on using sample scores to tune, avoiding reliance on match_count, and notes read-only and API key requirement.

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

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

Annotations already mark the tool as destructive (destructiveHint=true) and not read-only (readOnlyHint=false). The description adds value beyond annotations by explicitly stating it is a mutation ('MUTATES'), noting idempotency, requiring SF_API_KEY, and clarifying the exact effect (paper stays in library). This extra context earns a score above the baseline of 3.

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

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

The description is extremely concise: two sentences that efficiently convey purpose, addressing method, mutation effect, idempotency, and authentication requirement. Every word 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?

Given the tool's complexity (3 parameters, output schema exists), the description covers core operation, side effects, idempotency, and auth. It does not explain error handling or behavior when collection/paper does not exist, but these are minor gaps given the clear behavioral context and sibling differentiation.

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

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

The input schema provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description adds important semantic information: that collection_name and collection_id are alternatives ('OR'), implying at least one should be provided, which is not enforced by the schema. This clarifies usage beyond the schema alone.

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 that the tool removes a paper from a collection, and specifies that it can be addressed by collection_id OR collection_name. It also explicitly notes that the paper stays in the library, distinguishing it from sibling tools like unsave_paper that remove from the library entirely. This provides a specific verb and resource with clear 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 provides clear context on what the tool does and that it is idempotent. It implicitly guides usage by stating the paper stays in the library, suggesting when not to use it (if removal from library is intended). However, it does not explicitly name alternative tools or give when-not-to-use guidance, missing a small opportunity for clearer differentiation.

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 that the tool mutates the library, affects personalization (strongest signal in For You feed and email digest), and is idempotent. This adds context beyond the annotations (readOnlyHint=false, destructiveHint=false). 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?

Four sentences, each adding value: purpose, mutation effect, idempotency, alternative tool. No unnecessary words, well 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 simple single-parameter tool with an output schema, the description provides complete context: purpose, behavior, idempotency, auth requirement, and sibling alternative.

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 only parameter (arxiv_id) is fully described in the input schema (100% coverage). The description does not add extra details about the parameter beyond what the schema provides, 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 the tool saves a paper to the user's library (bookmark). It distinguishes from the sibling add_to_collection, which also saves but additionally files into a collection.

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 when to use this tool vs. add_to_collection, mentions the requirement for SF_API_KEY, and notes idempotency, providing clear usage 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?

The description discloses behavioral traits beyond annotations: default semantic search may miss canonical papers, impact_pct is only computed for last ~90 days, absorption of find_similar and find_citations_about, and ranking intricacies. Annotations only provide readOnlyHint=true and destructiveHint=false, so the description adds substantial 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 long but well-structured with bolding and bullet points, front-loading the main purpose. While verbose, every sentence earns its place given the tool's complexity (27 parameters). Could be slightly more compressed, but structure aids readability.

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

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

The description covers all major aspects: search modes, ranking, filtering, absorbed tools, caveats, and cross-references between parameters. With an output schema present and no required parameters, the description is fully complete for an AI agent to use correctly.

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

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

Schema description coverage is 100%, baseline is 3, but the description adds significant meaning beyond schemas: explains relationships between parameters (e.g., has_code + min_stars for adoption), caveats for impact_min, and how sort options relate to impact notions. This extra context fully justifies a 5.

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

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

The description clearly states the tool's purpose: 'Search Scholar Feed's 600k+ CS/AI/ML paper corpus.' It specifies verb+resource and distinguishes from siblings by mentioning absorbed tools (find_similar, find_citations_about) and referencing get_foundational_lineage as an alternative for canonical roots.

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 extensive guidance: when to use semantic vs keyword search, when to use different sort options (impactful vs trending vs community), caveats about canonical papers, and pairing with other tools like get_foundational_lineage. It also warns about impact_min dropping older papers and clarifies distinct impact notions.

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 destructiveHint=true, but description adds idempotency, side effect of removing from all collections, and auth requirement (SF_API_KEY). This provides crucial context beyond the annotations.

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

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

The description is comprehensive and well-structured, with each sentence adding value. It could be slightly more concise, but it effectively front-loads the key purpose and side effects.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema (as indicated), the description covers all necessary aspects: mutation, idempotency, side effects, alternative tool, and auth requirement. It is complete and self-contained.

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 the parameter with 100% coverage, so the description does not need to add much. It mentions 'arXiv ID' which aligns with the schema, but no additional format or constraints are provided. 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?

Clearly states 'Remove a paper from the authenticated user's Scholar Feed library', specifying the exact verb and resource. Distinguishes from sibling tools like remove_from_collection by noting the difference in 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?

Explicitly tells when to use this tool (to un-save a paper) and when not (to keep in a collection, use remove_from_collection). Also notes idempotency, which helps in decision-making.

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?

Mentions mutation, clearing pending hits on criteria change, ranking defaults, and min_impact_pct. Adds value beyond annotations which are minimal. 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?

Description is front-loaded with main purpose, then details. It is fairly long but every sentence adds necessary behavioral context. Slightly verbose but acceptable.

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 complex nested schema and behavioral nuances, the description covers side effects, ranking logic, prerequisites, and tuning advice. Output schema exists, so return values are not needed.

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

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

Schema coverage is 100%, baseline 3. Description adds extra meaning: explains side effects of changing criteria, ranking behavior, and tuning with preview_watch, enhancing understanding beyond 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 'Update an existing watch in place' with specific actions: rename, change novelty_min, or retarget filter. It distinguishes itself from sibling tools like create_watch and delete_watch.

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 context on addressing by watch_id or name, prerequisites (SF_API_KEY), and hints to use preview_watch first. Does not explicitly state when not to use or alternatives, 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.