Zipp

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

No annotations are provided, so the description carries full burden. It explains the filtering criteria (time and importance score) and the nature of results (market-moving). It does not mention auth or rate limits, but such details are not expected for a simple read tool. It adds value beyond the schema.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. No wasted words, perfectly concise.

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 (2 parameters with defaults, output schema exists), the description covers the core filtering and usage guidance well. However, it omits any mention of the parameters, which slightly reduces completeness. The existence of an output schema means return value explanation is not required.

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

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

Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not explain the 'lang' or 'limit' parameters, which would help an agent set them appropriately. The description should have compensated for the low coverage but did not.

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 provides breaking news filtered by last 24 hours and importance score ≥ 75, and it distinguishes itself from the sibling 'get_latest' by noting lower volume but higher impact. This is specific and actionable.

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 context when to use this tool (for most important news) and contrasts it with 'get_latest'. However, it does not explicitly mention when not to use it or alternative scenarios beyond that phrase.

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?

No annotations are provided, so the description bears full responsibility. It discloses that the tool returns full details including HTML body and FAQ, and that omitting date returns the latest published digest. It does not mention potential size of the response or any side effects, but for a read-only 'get' tool, this is sufficient.

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

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

The description is two sentences long, front-loading the most important information. Every sentence serves a purpose with no redundant words.

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

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

Given the complexity (3 parameters, 1 required), a clear description, and an existing output schema, the description covers all necessary context for an agent to use the tool correctly. It also references the sibling tool for discovery, completing the usage picture.

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 has 0% description coverage, so the description adds critical meaning. It explains what each parameter does: editor_slug identifies the editor, date_or_slug can be a date in YYYY-MM-DD format or a slug, and omitting it yields the latest digest. It also notes lang default is en-US.

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 full details of a single Editor Digest, listing included fields (title, standfirst, HTML body, etc.). It distinguishes itself from the sibling tool get_digests by indicating that get_digests is for discovering editors and dates.

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 instructions are given: pass editor_slug and optionally a date_or_slug (YYYY-MM-DD format) or omit for the latest digest. The description also directs users to get_digests for discovering editors and dates, providing clear when-to-use guidance.

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

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

With no annotations, the description carries the full burden. It discloses the read-only nature (listing, no mutation), ordering behavior, and output fields. It does not mention any side effects or permissions, but the operation seems safe.

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 front-load the purpose and detail the output, with 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?

The description covers the output well and there is an output schema. However, the complete absence of parameter documentation leaves a notable gap, especially given the tool's simplicity. It is adequate but not thorough.

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

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

The description mentions no parameters despite the schema having 'lang' and 'limit' with defaults. With 0% schema coverage, the agent receives no guidance on how these affect results (e.g., language filtering, pagination).

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 defines the tool as listing daily Editor Digests with specific fields (editor, headline, standfirst, sentiment, tickers) and ordering (newest-first). It distinguishes from 'get_digest' by noting that function retrieves the full body.

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 this tool is for browsing digest summaries and that 'get_digest' is for full content. However, it does not explicitly state when not to use it or provide alternatives for other time frames.

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 'No time window' and filtering logic, but lacks details on pagination, limit behavior, or authorization. With no annotations, this is adequate but not rich.

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

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

Two sentences, front-loaded with key information, every sentence adds value with 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?

With an output schema, return values are covered. Purpose and usage are well specified, but parameter documentation is missing, leaving a minor gap.

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 0%, and description does not explain parameters (lang, limit). This leaves the agent guessing about their meaning despite the tool being simple.

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 editor-picked feature stories with 'is_featured=TRUE', distinguishing it from siblings like recency-sorted news 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?

Explicitly says 'Use when the user wants curated highlights rather than recency-sorted news', providing clear context and implicit differentiation from 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?

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as read-only nature, authentication needs, or rate limits. The description focuses on output content rather than 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?

A single, well-constructed sentence that efficiently conveys the tool's purpose and a usage hint for a sibling tool. 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?

The description is reasonably complete for a simple retrieval tool, especially considering an output schema exists (though not shown). The only missing piece is explanation of the 'lang' parameter, but the default value softens the impact.

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

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

The description explains the 'slug' parameter as the identifier, but does not mention the 'lang' parameter or its default value. With 0% schema description coverage, the description should compensate more for undocumented 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 retrieves full details of a single guide by slug, listing specific fields (title, HTML body, FAQ pairs, etc.), and distinguishes itself from sibling tools by directing users to 'get_guides' for discovering slugs.

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 suggests using 'get_guides' to find slugs, providing a clear prerequisite. However, it does not explain when to choose this tool over other sibling tools like 'get_post' or 'search', leaving some ambiguity.

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

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

With no annotations, the description carries the full burden. It discloses ordering (newest-first), filtering capability (free-text category), and what each item contains (links). It also tells the agent to call get_guide for full content. Missing details on pagination, lang/limit defaults, and total count, but covers essential 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?

Two sentences that efficiently convey purpose, content type, ordering, filtering, and a chaining instruction. Every sentence adds 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?

For a simple listing tool with an output schema (presumably listing guide slugs/links), the description covers key usage: what it returns, ordering, filtering, and next step. Missing details on pagination behavior (e.g., what happens if limit is exceeded) is a minor gap, but overall it's sufficiently 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 0%, so description must add meaning. It explains the 'category' parameter with examples, but does not explain 'lang' or 'limit'. This partial compensation is adequate but incomplete, warranting a mid-range 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 uses a clear verb 'List' with a specific resource 'Zipp's Learn guides', and elaborates on the content (evergreen crypto explainers). It distinguishes from sibling 'get_guide' by indicating this returns a list of links and recommending get_guide for full 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 implies usage: use this to list guides and get_guide for details. It mentions optional category filtering but provides no explicit when-to-use or when-not-to-use guidance compared to siblings like search or list_categories.

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 time window (last 24 hours) and ordering (newest-first). Without annotations, this carries full burden. It doesn't mention safety (but read-only is implied). Output schema covers return format.

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: core function, ordering, example use cases. No filler, 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 optional parameters 3, output schema exists, and no annotations, the description covers purpose, scope, ordering, and example usage. Lacks explicit defaults for limit/lang but those are in schema. Good for a list endpoint.

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 0% schema description coverage, the description only adds meaning for the 'category' parameter ('Optionally scoped to a category'). Does not mention 'lang' or 'limit', leaving gaps. Moderate compensation.

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 tool retrieves latest news from the last 24 hours, optionally scoped by category, with ordering. The verb 'get' and resource 'latest news' are specific, and the time scope distinguishes it from siblings like get_breaking.

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 examples ('what's new today?', 'what happened in DeFi today?') which clearly indicate when to use this tool. Does not explicitly exclude alternatives 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?

With no annotations, the description carries the full burden. It discloses the output contents but lacks behavioral details such as authentication requirements, read-only nature, or error handling. The mention of 'full detail' implies completeness.

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, well-structured sentence that conveys the core function and input options without unnecessary words. It is front-loaded with the key 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 existence of an output schema, the description appropriately focuses on input and output summary. It is complete for a simple retrieval tool, but missing guidance on the 'lang' parameter and any usage caveats.

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

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

The description adds meaning to the required parameter 'slug_or_id' by explaining it can be a slug or numeric id. However, it does not mention the optional 'lang' parameter, leaving its purpose unclear despite a 0% schema description 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 clearly states the tool retrieves full detail of a single post, listing specific fields (title, summary, full body, categories, etc.) and the input methods (slug or numeric id). This distinguishes it from sibling tools like get_latest or get_breaking.

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 that the input can be a slug from a previous tool call or a numeric id, providing clear guidance on argument choices. However, it does not explicitly compare with siblings or state when not to use 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?

No annotations are provided, so the description carries the burden. It discloses that data is a 'live' snapshot from CoinGecko or CoinMarketCap, and mentions clamping of the limit parameter. However, it does not discuss data freshness, rate limits, authentication, or potential failure modes.

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 front-load the primary purpose and add key usage details (limit behavior). Every sentence adds value with no redundant or filler content.

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

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

Given the presence of an output schema, the description adequately explains what the tool returns (price, market cap, 24h change, rank movement) and covers input constraints. Sibling tools are not exhaustive, but the description is self-contained for this simple 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 description coverage is 0%, but the description compensates by explaining the limit parameter's clamping and default, and the provider parameter's sources and default. The lang parameter is not described, which is a minor gap.

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

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

The description clearly states the tool retrieves live crypto market-cap rankings, with specific data fields (price, market cap, 24h change, rank movement). It answers the question 'what are the top coins right now?' and distinguishes from siblings like get_trending_tokens that focus on trending tokens.

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 getting top coins but lacks explicit guidance on when not to use it or how it compares to alternatives like get_trending_tokens or get_latest. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description must carry the burden. It discloses the return data (name, ecosystem, exchange listings, coverage, live price when available) but does not mention potential failure modes (e.g., invalid ticker), authorization needs, or rate limits. The 'when available' caveat for price is good but incomplete.

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 dense paragraph that front-loads the main functionality and then provides usage examples. It is concise without redundant fluff. However, it could benefit from a more structured format (e.g., bullet points) for 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 3 parameters (1 required) and existence of an output schema, the description covers the high-level intent and key return fields. However, it lacks parameter explanations and does not address error handling or limitations. It is adequate but not thorough.

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

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

Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description only implicitly covers the 'ticker' parameter by mentioning 'coin' but does not explain 'lang' or 'article_limit'. An agent would not know the purpose of these parameters from the description 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 returns a detailed snapshot of a single token including name, ecosystem, exchange listings, recent coverage, and live price. It also gives specific examples like 'tell me about Solana', which distinguishes it from sibling tools that focus on breaking news, featured posts, or trending tokens.

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

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

The description explicitly says 'Use when the user asks about a specific coin' and provides concrete examples. It implies when not to use (for multiple tokens or general news) but does not name alternative sibling tools explicitly. This is clear enough for an agent to decide.

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 ordering (mention count desc, then recency) and window clamping (1–168h), which are key behaviors beyond basic parameters. With no annotations, it partly carries the burden, though it omits safety info like read-only nature (implied).

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, front-loaded with purpose, 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?

For a tool with 3 parameters, no annotations, and an output schema (covering returns), the description covers core behavior and window constraints. However, it lacks explanation for lang and limit, leaving some 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?

The description only explains window_hours (default and clamping) but does not address lang or limit parameters. With 0% schema description coverage, the parameter meanings are largely left to inference.

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 tokens with the most Zipp coverage in a recent time window, which distinguishes it from siblings like get_breaking (breaking news) or get_latest (latest posts). The purpose is specific and actionable.

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 tool's use case is explicitly given ('what coins is the market talking about right now?'), providing clear context. However, it does not mention when not to use it or list alternatives, which would improve guidance.

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

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

With no annotations, the description must fully cover behavioral traits. It mentions the output structure (35 categories, 7 groups) but does not explicitly state that this is a read-only, non-destructive operation. The safety profile is implied but not confirmed.

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

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

Two sentences with no wasted words. The first sentence defines the output precisely, and the second provides immediate usage context. Front-loaded and efficient.

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

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

Given the tool's simplicity (no required params, output schema exists), the description covers the core function and usage. Missing only a brief note on the 'lang' parameter's effect, which would improve completeness.

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

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

Schema description coverage is 0%, so the description must add meaning for the 'lang' parameter. It does not mention the parameter at all, leaving the agent unsure whether 'lang' filters categories or just the returned labels.

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' and the resource 'full Zipp taxonomy' with specifics (7 main groups × 5 leaves = 35 categories). It explicitly differentiates its purpose from siblings by stating it is used to discover valid category slugs for 'search' and 'get_latest' tools.

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

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

The description provides clear usage guidance: 'Use to discover valid category slugs for the search / get_latest tools.' It implies a preparatory role, but does not explicitly state when not to use it (e.g., for direct content retrieval).

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 key behaviors: full-text search, recency-ordering with relevance tiebreaker. Since no annotations exist, the description carries the full burden, and it covers the essential behavior adequately, though it omits details like pagination or output format.

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

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

The description is two sentences that are direct and front-loaded with the purpose. Every sentence provides actionable information without repetition or unnecessary detail.

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

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

Given the tool has 4 parameters and an output schema, the description covers the core functionality but lacks detail on parameter constraints (e.g., language format, maximum limit) and edge cases. It is minimally sufficient for an agent with schema knowledge.

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 0% schema description coverage, the description should compensate by explaining parameters. It only implies the 'query' parameter via examples and provides no context for 'lang,' 'limit,' or 'category,' leaving their semantics unclear.

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 performs 'full-text search across Zipp's news catalogue,' identifies the resource and action, and distinguishes from sibling tools that return specific collections (e.g., get_latest, get_breaking).

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 concrete examples like 'what's happening with Bitcoin ETFs?' that illustrate when to use this tool. It implicitly contrasts with siblings by focusing on broad queries, though it lacks explicit when-not-to-use guidance.

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