Source Library

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover safety. The description adds behavioral context: the summary is 'multi-paragraph... often answering the question without further searching' and lists return fields (summary, chapter list, edition metadata, etc.), which is helpful. No contradictions. Slight gap: does not mention pagination or error handling, but annotations cover the main concerns.

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

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

The description is dense and well-structured, with bold emphasis on key directives. It front-loads the purpose and then lists return values and workflow. Each sentence adds value, though the pipeline exposition could be slightly more compact. Still efficient for the information conveyed.

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 required parameter, no nested objects, no output schema), the description is fully adequate. It covers the tool's purpose, return content, and integration with sibling tools, leaving no ambiguity about what the tool does and how it fits into the broader system.

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 (book_id) with 100% schema description coverage (schema states 'The book ID'). The description adds no additional semantic information about the parameter beyond what the schema already provides. 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 clearly identifies as a discovery tool for books ('READ PIPELINE step 1 — DISCOVER. START HERE for any named work or author.') and specifies it returns summary, chapter list, edition metadata, DOI, page counts, and IIIF manifest. It distinguishes from siblings by explicitly naming subsequent tools (get_book_text, get_quote, etc.) and their roles in the pipeline.

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 states 'START HERE' and provides a step-by-step usage sequence: after get_book, use get_book_text to read a chapter or page range (step 2), then get_quote/get_quotes for citations (step 3), and search_within_book for passages. It also notes that the summary often answers the question without further searching, guiding when to stop.

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 safe read operation; description adds critical details about truncation behavior and budget limits, which are not in 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?

Well-structured, front-loaded with purpose and steps. Every sentence adds value, no redundancy. Efficient use of text.

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 usage order, param selection, truncation, and rate limits. Lacks explicit output structure details beyond truncated/truncation_note, but format param partially addresses this. Very good overall.

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 params with descriptions. Description adds value by recommending chapter over from/to, specifying chunk size (50 pages), and explaining truncation_note usage. Provides context 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 'Read a book's text.' and positions it as step 2 in a pipeline, distinguishing it from siblings like get_book (step 1) and get_quote/get_quotes (step 3).

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 guidelines: call get_book first, prefer chapter param, handle truncation using truncation_note, hand page numbers to get_quote/get_quotes. Also mentions budget limits and authentication.

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 and idempotent. Description adds context on retrieving exact text, citation apparatus, and rendering format including citation_link. Minor gap on error 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?

Compact but includes purpose, usage rule, and output formatting. Every sentence contributes value; slightly verbose with blockquote 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?

Covers purpose, usage, and output format. Siblings and annotations provide additional context. Missing error handling but adequate for a simple read 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%, so baseline is 3. Description does not add new parameter details beyond what the schema provides.

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

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

Clearly states it is for getting verbatim text of a single page with citation apparatus. Distinguishes from sibling get_quotes for multiple pages.

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 'ALWAYS use before putting text in quotation marks' and directs to get_quotes for multiple pages, providing clear when-to-use and 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds that each entry carries its own citation_link and the 25-page limit, which are useful behavioral details beyond annotations. 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, front-loaded with purpose, and every sentence adds unique value (purpose, usage modes, limit). No redundancy or filler.

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

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

With no output schema, the description compensates by stating entries contain verbatim text and citation_link. It covers constraints and usage modes. Could be more explicit about what 'verbatim text' includes (e.g., page number), but sufficient for agent 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 parameter descriptions exist. The description adds semantic value by clarifying that from/to is inclusive, pages is exclusive from from/to, and the max 25 pages constraint. This aids correct invocation.

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 retrieves verbatim text and citation links for several pages of a single book in batch, and positions it as step 3 of a READ PIPELINE (CITE). It distinguishes from siblings like get_quote (single quote) and get_book_text (full text) by specifying batch and multi-passage dossier use.

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 (to assemble a multi-passage dossier), how to specify pages (array or from/to range), and a max limit (25 pages). However, it does not explicitly state when not to use or mention alternative tools like get_quote for single quotes, though it is implied by the batch nature.

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, idempotent, and non-destructive behavior. The description adds value by specifying the return fields (title, author, language, year, translation progress) and the constraint of no content matching, without contradicting annotations.

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

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

The description is two concise sentences plus a line for alternatives. It is front-loaded with purpose, every sentence adds value, and there is no redundant or irrelevant text.

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

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

Despite no output schema, the description lists return fields. It covers filtering scope and alternatives. It does not mention pagination defaults beyond the limit parameter (which has a schema description), but overall it is sufficiently 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 description coverage is only 40%, but the description explains the filtering metadata (author/title, language, category, translation recency) and maps 'translation recency' to the sort parameter. It adds context for the two undocumented parameters (category and language) 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 the tool browses/filters the catalog by metadata (author/title fragment, language, category, translation recency) and explicitly excludes content/topic matching. It distinguishes from siblings by naming alternative tools for different use cases.

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: 'PICK THIS to see WHAT EXISTS by an author or in a tradition.' It also tells when not to use it, pointing to search_library, search_translations, and search_concept for other needs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral details: uses cosine similarity on Gemini embeddings, similarity calibration thresholds (0.70+ strong, 0.55-0.70 worth reading, below 0.55 conceptual drift), snippet_type restriction (only 'translation'), and cross-cultural search tips.

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 every sentence adds value. It front-loads the core purpose, then provides usage guidance and tips. Could be slightly more concise, but efficient for the complexity of the tool.

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

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

Given the complexity of a semantic search tool with 8 parameters and no output schema, the description covers key aspects: what it returns, when to use, similarity scoring, filtering options, and cross-cultural strategies. Missing details on exact output structure, but sufficient for an AI agent to use appropriately.

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 each parameter. The description adds contextual value beyond schema: explains max_per_book for diversifying results, suggests using full sentences as query, gives examples of language filters (e.g., exclude_languages to surface non-Western). It also adds global behavioral notes (calibration, snippet type) that are not tied to specific parameters.

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

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

The description clearly states the tool returns quotable passages matched by meaning using semantic similarity, and explicitly distinguishes it from siblings like search_translations, search_library, and get_book.

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 says 'PICK THIS when the modern term won't literally appear in historical texts' and gives examples. It also tells when to use alternatives like search_translations for exact words, search_library for book listing, and get_book for specific authors.

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's 'Search' verb aligns. The description adds context like image counts but does not disclose pagination, rate limits, or auth requirements, which are not critical for a read-only search tool.

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

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

The description is a single, front-loaded sentence that conveys core functionality and key filtering options without superfluous 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?

With 9 parameters, no output schema, and only basic annotations, the description provides a high-level view but lacks details on parameter combinations, result format, and limits (e.g., max results 50 is in schema but not repeated). Adequate but not fully comprehensive.

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 low (33%), but the description mentions several parameters (type, subject, figure, symbol, year) and provides example queries. However, parameters like 'book_id', 'year_from', 'year_to' are not explained, requiring users to infer from the schema.

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

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

The description clearly states 'Search 110,000+ historical illustrations... artworks' with specific examples ('woodcut, engraving, emblem, diagram') and distinguishes from sibling tools like 'search_concept' and 'search_within_book' by focusing on image content.

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 lists filterable dimensions (type, subject, figure, symbol, year) and implies use for historical image searches. However, it does not explicitly state when not to use this tool or mention alternatives, though sibling tools provide 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 significant context beyond annotations: describes search scope (titles, authors, subjects, translated text), pagination details (total_matches, offset), and explicitly says it does not return passages. 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?

Concise single paragraph with front-loaded key message, all sentences add value, 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?

Covers all critical aspects: what is returned, scope of search, usage guidance, pagination, and query tips. Adequate for an agent to use without output schema.

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

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

Schema coverage is 88%, but description adds query tips (single words, quoted phrases) and pagination explanation that enhance 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 it returns a list of books, not passages, and distinguishes it from sibling tools like search_translations and get_book. It uses specific verbs and resource.

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

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

Explicitly tells when to pick this tool (discover works on a subject) and when to use alternatives (search_translations, search_concept, get_book, list_books). Also provides query tips.

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, destructiveHint=false, idempotentHint=true. Description adds snippet types (translation/ocr vs summary) and response structure (total_matches, returned, offset), providing useful 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?

Description is well-structured with clear sections: purpose, alternatives, query tips, cross-cultural tips. It is slightly verbose but every sentence adds value; front-loading of purpose aids quick understanding.

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 9 parameters (1 required) and no output schema, the description covers purpose, usage, parameter tips, response format, and cultural considerations. It is fairly complete, though output schema would further reduce ambiguity.

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 78% with descriptions for most parameters. Description adds query interpretation details (e.g., multi-word queries match all terms, double quotes for exact phrase) and language filtering guidance, enhancing parameter semantics significantly.

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 it returns quotable passages (page-level snippets + citation URLs) matched by keyword/term. It distinguishes from siblings by naming search_concept, search_library, search_within_book, and get_book as alternatives.

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 when to use (find quotes/evidence) and when not (e.g., use search_concept if modern word won't appear). Provides query tips and cross-cultural advice for term selection.

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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds that it runs parallel keyword and semantic search, merges results, and returns OCR and translation snippets with page numbers. 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?

Well-structured with arrows and line breaks, front-loads the core action. Each sentence adds value, though slightly verbose. Could be more concise without losing 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?

Given no output schema, the description explains return values (OCR/translation snippets with page numbers). Covers internal process, speed, and scope. Complete for a 2-parameter 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%, so baseline is 3. The description adds minimal parameter-specific detail beyond the schema; it implies query can be literal or conceptual, but this is more about behavior than parameter semantics. No additional syntax or constraints are provided.

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 searches inside one book, requires book_id, runs keyword and semantic search in parallel, and merges results. It distinguishes from siblings by specifying when to use it (after obtaining a candidate book) and contrasts with global tools like search_library.

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 'PICK THIS once you have a candidate book' and 'To find the book first, use search_library or search_concept (then pass its book_id here).' Also notes it's faster than global re-search, providing clear 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 are sparse, but the description provides key behavioral details: citations are references not copied text, the library re-renders canonical quotes, and the submission goes for review rather than being instantly public. This adds meaningful context beyond the structured fields.

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 fairly concise at three sentences, front-loaded with the primary purpose. It balances necessary detail (citations structure, comparison to submit_feedback) without being verbose. A slight trim would be possible but not necessary.

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 no output schema and moderate complexity (5 params), the description covers the tool's purpose, when to use, behavioral notes, and key parameter semantics. It does not explain what happens after submission (e.g., success response), but with good annotations and a clear use case, this is minimally sufficient for an agent.

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 60%; the description explains the citations array structure (book_id, page, note) and emphasizes it's an ordered list. However, it omits any description for the 'name' and 'email' parameters, relying solely on schema. While the critical parameter is well covered, the missing explanation for optional fields limits the score.

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

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

The description clearly states the action ('Share a research dossier') and the specific components (title, summary, citations). It distinguishes this tool from siblings like submit_feedback by noting both go to the team for review, preventing misuse.

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 to use this when the user has assembled a thesis backed by passages across books and wants to contribute. Also compares to submit_feedback, giving clear context for when to choose this over other 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 indicate not read-only and not destructive, and the description aligns with 'submit' as a write operation. However, no additional behavioral context like authentication needs or data handling 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?

The description is a single, concise sentence that front-loads the purpose without 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?

For a simple feedback tool with no output schema and low complexity, the description is sufficient but could benefit from mentioning any constraints or response 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?

With only 33% schema coverage (only 'message' has a description), the description does not add meaning for other parameters like 'name' or 'email', failing to compensate for the low 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 explicitly states 'Submit feedback, bug reports, or feature requests to the Source Library team,' using a specific verb and resource, and clearly distinguishes from sibling tools which are all read/search oriented.

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

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

The description implies usage for providing feedback, but lacks explicit guidance on when to use this tool versus alternatives or any prerequisites, such as authentication or rate limits.

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