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 discloses the time window (last 24 hours), importance threshold (≥ 75), and volume comparison to get_latest. However, it does not explicitly state that the tool is read-only or mention any rate limits, though these are implied by 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 two sentences, highly concise, and front-loads the most important information (breaking news criteria and usage).

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 output schema and simple parameters with defaults, the description covers the essential filtering criteria and usage context. It is complete for this 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%, and the description does not explain the parameters (lang and limit). The agent must infer their meaning from defaults and names, which is insufficient.

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 'Breaking news only — last 24 hours, importance score ≥ 75', clearly identifying the tool's purpose. It also distinguishes itself from the sibling get_latest by noting lower volume and market-moving 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 provides a specific use case: 'Use for "what's the most important crypto news right now?"'. It also contrasts with get_latest, guiding when to choose this over 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?

Discloses default behavior (omit date for latest) and required date format (YYYY-MM-DD). No annotations exist, so description carries burden; lacks details on errors or permissions, but adequate for read operation.

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, no wasted words, purpose stated first, then usage details.

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?

Lists returned fields (title, standfirst, etc.) and references sibling tool. Could mention error handling, but for a detail retrieval tool this is 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?

Adds meaning beyond schema: explains date format and optional behavior of 'date_or_slug', and implies purpose of 'editor_slug'. Does not elaborate on 'lang', but schema coverage is 0% so description compensates well.

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?

Clear verb ('get') and resource ('Digest'), lists specific fields returned, and distinguishes from sibling 'get_digests'.

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 when to use (get a single digest), how to pass parameters (editor slug, optional date/slug), and when to use alternative 'get_digests'.

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), what fields each item carries (editor, headline, standfirst, sentiment, tickers), and that full body requires a different call. This is strong transparency, though it could mention if there are limits or side effects beyond the trivial.

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

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

The description is compact (two sentences), front-loaded with the tool's purpose, and every sentence adds value—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 low complexity (0 required params, no enums) and presence of an output schema, the description is fairly complete: it covers output structure, ordering, and sibling relationships. It doesn't mention pagination beyond the limit default, but the output schema likely handles that.

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%, yet the description adds no information about the lang or limit parameters. The agent must infer from defaults and names; no format, constraints, or usage hints are provided. The description fails to compensate for the schema's lack of description.

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 daily Editor Digests, describes their content (market briefings, editorial personas, 24h synthesis), and explicitly distinguishes from sibling get_digest by noting that get_digest is for full body retrieval.

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 (list digests) and when to use a different tool (call get_digest for full body), providing clear usage guidance and an alternative.

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' as a behavioral trait. No annotations exist, so description carries full burden. It could mention caching or pagination, but given tool simplicity, 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?

Two sentences, front-loaded with key information, no waste. 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 purpose and usage well, but misses parameter details. With output schema present, return values are covered. A slightly more complete description would mention parameter effects.

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 fails to explain the 'lang' and 'limit' parameters. For a low-coverage scenario, the description should compensate, but it does 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 retrieves editor-picked feature stories and distinguishes from recency-sorted news by noting 'No time window.' This separates it from siblings like get_latest.

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 guidance on when to use and implying alternative 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 describes the return content (title, HTML body, etc.) but does not mention potential error conditions, authentication, or side effects. For a read-only retrieval tool, this is adequate but not comprehensive.

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, well-structured with the most important information first. Every phrase adds value with 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 tool has only 2 parameters, no annotations, and an output schema exists, the description is fairly complete. It states the core function, return fields, and how to get the slug. It could be slightly improved by noting that it is a read-only operation, but this is minor.

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 compensate. It explains the 'slug' parameter's purpose (the guide identifier and how to obtain it) but does not describe the 'lang' parameter, which has a default. This adds partial meaning 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 retrieves full details of a Zipp Learn guide by slug, listing specific content fields. It distinguishes from siblings by directing users to 'use get_guides to discover 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 provides clear context for when to use the tool (when you have a slug and need full guide details) and directs users to get_guides for slug discovery. However, it does not explicitly exclude alternatives or discuss 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?

No annotations provided, so description carries full burden. It states 'Newest-first' ordering and returns items with links, implying read operation. But it doesn't explicitly declare read-only or disclose pagination/rate limits.

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

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

The description is four short sentences with no fluff. It front-loads the purpose and adds filtering and next-step guidance efficiently.

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 output schema exists (return values documented elsewhere), the description adequately covers purpose, filtering, ordering, and follow-up action. Missing only pagination details and lang parameter explanation.

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 compensate. It explains category is a free-text filter and mentions listing (implying limit). However, lang parameter is not explained, and limit is only implicit.

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 'Zipp's Learn guides' — specific resource and action. It details the type of content and ordering. It distinguishes from sibling tools like get_guide by referencing it for detail retrieval.

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 guides when to use (listing guides) and suggests calling get_guide for body. However, it does not explicitly exclude alternatives or mention when not to use this tool over search or get_breaking.

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 the 24-hour time window, newest-first ordering, and optional category filter. However, it does not mention whether the operation is read-only, authentication needs, rate limits, or what happens when no news is available. This is adequate but not comprehensive.

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 long, front-loaded with the core purpose, and contains no redundant information. Every sentence adds value: time range, optional scoping, ordering, and usage examples.

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 (3 optional parameters, no required) and the presence of an output schema, the description covers the essential aspects: purpose, scope, ordering, and common use cases. It could slightly improve by mentioning that 'limit' controls the number of returned posts, but overall it is nearly complete.

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

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

Schema description coverage is 0%, but the description explains only the 'category' parameter ('Optionally scoped to a category'). It does not explain 'lang' or 'limit' beyond what the schema defaults provide. For a tool with 3 parameters, this is insufficient 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?

The description clearly states the tool gets the latest news from the last 24 hours, ordered newest-first, with optional category scoping. It provides concrete example queries ('what's new today?', 'what happened in DeFi today?') and distinguishes itself from siblings like get_breaking and get_digest through time scope and ordering.

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

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

The description gives explicit usage scenarios ('Use for what's new today? or what happened in DeFi today?') and mentions optional category scoping. It does not explicitly state when not to use this tool or list alternative tools, but the context is clear enough for most agents.

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 discloses the tool's read-only nature implicitly (retrieves details) and lists return fields, but does not mention authentication, rate limits, or error behavior. Some behavioral context is provided, but gaps exist.

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: first lists returned fields, second explains input. No redundant information. Efficient and well-structured.

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

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

The description covers the tool's purpose and input constraints. With an output schema present, it does not need to detail return format further. It is adequately complete for a simple retrieval tool, though missing error case mentions.

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%. The description explains the 'slug_or_id' parameter, but the 'lang' parameter (with a default) is not described. Given low coverage, the description partially compensates but leaves one parameter unexplained.

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 retrieves the full detail of a single post, listing specific fields (title, summary, full body, etc.). It distinguishes itself from siblings that likely return lists or summaries.

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 tool accepts either a slug or numeric id, implying it should be used when you have an identifier for a specific post. However, it does not explicitly state when not to use it or mention alternatives like search for multiple posts.

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 full burden. It discloses the limit clamping (1–100, default 10) and defaults for lang and provider, but does not mention any behavioral traits like read-only nature, rate limits, authentication requirements, or side effects. The disclosure is adequate 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?

Two concise sentences: the first states the core purpose and fields, the second answers the user query and clarifies parameter behavior. No redundant 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 the presence of an output schema (so return values are covered), the description explains all three optional parameters and the clamping behavior. It lacks details on error handling or provider limitations, but for a straightforward listing tool, the information is sufficient.

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

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

The input schema has 0% description coverage, so the description must compensate. It adds meaning for limit (clamped range) and provider (default coingecko, allows coinmarketcap), but lang is only given a default value without explanation. This provides enough context for agent to use parameters correctly.

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

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

The description clearly identifies the tool as retrieving live crypto market-cap rankings with specific fields (price, market cap, 24h change, rank movement) and answers a concrete question ('what are the top coins right now?'). It distinguishes itself from sibling tools like get_breaking, get_digest, etc. by focusing on market rankings.

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 real-time top-N rankings and specifies the default provider (CoinGecko) with an alternative (CoinMarketCap). However, it does not explicitly state when NOT to use it or point to alternatives among siblings, which is a minor gap.

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

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

No annotations are provided, so the description must fully disclose behavior. It details the returned data (name, ecosystem, exchange listings with URLs, recent coverage, live price). However, it does not mention that the tool requires a ticker or any authorization/rate limits.

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

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

The description is a single paragraph of moderate length, starting with the core purpose and then providing usage examples. It is efficient but could benefit from clearer separation of output components or parameter hints.

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 3 parameters and an output schema, the description adequately covers the output richness but fails to fully explain input parameters. The presence of an output schema reduces the need to describe return values, but the parameter gap reduces completeness.

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

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

The input schema has 0% description coverage, so the description must compensate. It does not explain 'lang' or 'article_limit' parameters, and 'ticker' is only implied through examples. The description adds value by linking output components to language, but parameter semantics are largely missing.

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 provides a 'detailed snapshot of a single token' with specific components (name, ecosystem, exchange listings, news, price). It distinguishes from sibling tools by focusing on individual tokens and includes example queries.

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 gives three concrete query examples. It does not directly mention alternatives, but the context of sibling tools and the clear scope imply appropriate usage.

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

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

No annotations are provided, so the description carries the burden. It discloses ordering (by mention count descending then recency), window defaults (24 hours), and clamping (1-168 hours). This is good behavioral transparency for a read-only tool, though it omits details like authentication or rate limits.

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

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

The description is three sentences long, front-loads the core purpose, and includes necessary details without extraneous text. 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?

The description covers the tool's purpose, ordering, and window behavior. An output schema exists, so return values need not be described. However, the limit parameter and pagination behavior are not addressed, which is a minor gap for a list 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%. The description adds meaning for window_hours (defaults and clamping) but does not describe lang or limit parameters. This partial coverage is adequate but leaves two parameters unexplained, which could confuse an AI agent.

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 identifies the tool's purpose: retrieving tokens with the most Zipp coverage in a recent time window. It uses specific verbs ('get') and resources ('trending tokens'), and differentiates from siblings by focusing on 'what coins is the market talking about right now' rather than news or posts.

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?

Description provides clear usage context: 'useful for what coins is the market talking about right now?' and explains ordering and window constraints. It does not explicitly state when not to use or name alternatives, but the context is sufficient 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?

With no annotations, description discloses that this is a read-only listing operation with specific structural output. Behavior is clearly non-destructive. However, does not mention any authentication requirements or rate limits, but for a list tool 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?

Single sentence, zero waste. Efficiently packs structure and 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 simplicity, output schema exists, description covers core functionality and use case. Missing parameter semantics is a minor gap but overall sufficient.

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

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

Schema coverage is 0%, but description does not mention the 'lang' parameter or explain its role (likely language for category names). Agent cannot infer correct usage beyond default.

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 verb 'List' and resource 'full Zipp taxonomy', specifies structure (7x5=35 categories). It distinguishes from siblings (none list categories) and explains why to use it: to discover slugs for search/get_latest.

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 agent to use this tool to discover valid category slugs for search/get_latest tools, providing clear context. No when-not advice needed since tool is simple and standalone.

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 correctly notes the tool performs full-text search and orders results by recency with relevance as a tiebreaker. However, it does not explicitly state that the operation is read-only or non-destructive, nor does it mention any auth or rate limits.

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

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

The description is extremely concise: two sentences plus example usage. Every sentence adds value, and the critical information (search functionality, ordering, example queries) is 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 presence of an output schema, the description need not detail return values. It adequately covers the tool's purpose and basic behavior. However, the lack of parameter descriptions and usage exclusions leaves gaps for a tool with 4 parameters and no schema descriptions.

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 compensate. It only obliquely references the 'query' parameter through example questions but does not explain the meaning or usage of 'lang', 'limit', or 'category'. This leaves the agent without guidance on how to set these 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 verb 'search' and the resource 'Zipp's news catalogue', and specifies that it returns recent stories ordered by recency and relevance. This distinguishes it from sibling tools which are specific fetches (e.g., get_breaking, get_latest).

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 example questions ('what's happening with Bitcoin ETFs?') that illustrate when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tool list implies that for specific items or categories, other tools might be better.

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