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

With no annotations, the description carries the behavioral burden. It adds one behavioral detail beyond the basic function: 'Cached for 5 minutes,' which tells the agent about data freshness. However, it doesn't disclose authentication requirements, side effects, or error behavior. 'Show' implies read-only, but that is implicit rather than explicit.

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?

One compact sentence that front-loads the core purpose and then adds the caching behavior. No filler or redundancy; every word 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?

For a read-only usage check with no parameters, the description covers the essential scope (time windows, call-type split) and even adds a caching note. It doesn't specify the output data format, but the lack of an output schema and the simplicity of the tool make this acceptable. An agent can infer the response structure well enough to proceed.

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

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

The tool has zero parameters, and schema description coverage is 100% (empty schema). Per the baseline rule, this warrants a 4; the description correctly omits parameter details because none exist.

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?

States a specific verb ('Show') and resource ('current API usage vs limits'), with granularity (hourly/daily/monthly windows) and a split (service calls vs icon calls). It clearly distinguishes from siblings like get_icon and search_collections, which are all icon/collection 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?

No explicit when-to-use or exclusions are stated, but the domain is so distinct from siblings that an agent can easily infer when to invoke it. The description provides clear context by enumerating the time windows and call categories, though it doesn't explicitly say 'use this when checking rate limits.'

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 of behavioral disclosure. It usefully discloses the quota cost (150/day on the free trial), the public-domain-only restriction on the free trial, and the optional color/size behavior. It does not describe the return representation (e.g., raw bytes vs file written via save_to_file), which is a minor gap but the disclosed constraints are meaningful.

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 short sentences with no wasted words. The core action and formats are front-loaded, and the usage boundary and quota warning are relevant additions. The phrase 'expensive *icon* call' is slightly informal but 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?

The description covers when to use, quota, and licensing restrictions, which is good for a tool with no annotations and no output schema. However, it does not explain what the tool actually returns when save_to_file is omitted, nor how download success is conveyed, leaving a meaningful gap for an agent deciding how to present the result to the user.

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 the schema already documents all five parameters. The description adds only that color/size are optional and that size applies to PNG, but those details are already implied by the schema. It does not introduce substantial new parameter meaning beyond the structured definitions.

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

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

States a specific action ('Download one icon') with explicit formats (SVG or PNG) and modifiers (color/size). The description distinguishes it from inspection workflows by clarifying it is for saving/embedding, not inspecting search results, which separates it from sibling tools like get_icon and search_icons.

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 it only when the user asked to save or embed the file, and not to inspect search results. This gives a clear when/when-not boundary, but it does not name the specific sibling tool that should be used for inspection, so the guidance is strong but not maximally explicit.

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 of behavioral disclosure. 'Service call' and 'a page of its icons' convey that a single call returns a page of icons rather than one icon, and the preference note hints at batching efficiency. However, it does not describe response structure, error behavior, rate limits, or whether the operation is safe and idempotent.

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 opening sentence is front-loaded and specific, and the preference note is useful and compact. The standalone sentence 'Service call' is terse and adds only marginal information, preventing a perfect score.

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 six parameters and no output schema, the description gives a high-level result shape but no concrete response format or pagination continuation details. The schema covers parameter meanings, and the description adds batching guidance, so an agent can select and start using the tool, though the definition is not fully self-contained for advanced pagination workflows.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds context for the pagination parameters by saying it returns 'a page of its icons,' but it does not explain parameter defaults, token relationships, or enum semantics 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?

The description uses the specific verb-object pair 'Get a collection and a page of its icons,' clearly identifying the resource and the paginated nature of the result. The final sentence distinguishes it from get_icon by noting it should be preferred over per-icon calls, making its purpose unambiguous.

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 instructs the agent to prefer this tool over calling get_icon on each icon, giving concrete selection guidance and naming the relevant alternative. It does not enumerate when to fall back to get_icon or when search_collections would be more appropriate, so the guidance is strong but not exhaustive.

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 burden, and it discloses that the icon_url is temporary and expires in 1 hour, and that the call is expensive with specific quota caps. It doesn't describe every behavioral edge case, but the key constraints are surfaced.

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 compact sentences with no filler. The core purpose and temporary URL detail are front-loaded, followed directly by important usage and cost guidance.

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

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

For a simple tool with only two parameters and 100% schema coverage, the description provides enough context: what it does, a key return value, cost implications, and when to avoid it. It doesn't explain the complete response structure, but the core decision-making context is present.

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

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

Schema description coverage is 100%, so both icon_id and thumbnail_size are already documented in the input schema. The description adds no extra meaning about how these parameters behave or interact, so the baseline score of 3 is appropriate.

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

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

The description clearly states the primary action: getting extra details for a single icon, including a temporary SVG icon_url. It also hints at a distinction from search_icons by noting when not to use it, though 'extra details' remains somewhat vague about the full set of fields returned.

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 warns that this is an expensive icon call with daily/monthly free-trial limits and explicitly says to skip it when search_icons already has the needed metadata. This gives the agent a clear decision rule and a named 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?

Annotations are not provided, so the description carries the burden. It mentions 'Cheap service call' which is a performance trait, but does not disclose return format, error behavior, or other side effects. It adds some value beyond the schema by hinting at cost, but a 3 is fair for not going further.

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 brief, front-loaded with the core purpose, and includes a practical usage hint. Every sentence adds value without fluff, making it highly efficient for the agent.

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 autocomplete tool with fully documented schema, the description provides usage timing and performance context. It lacks details about return format, but given the simplicity and schema coverage, the description is sufficiently complete for agent decision-making.

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

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

Schema description coverage is 100%, so the schema already documents both parameters clearly. The description adds the max limit context (max 10) which matches the schema's maximum of 10, but it does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('Autocomplete') and resource ('icon search terms'), and implicitly scopes it to autocomplete functionality. It doesn't explicitly contrast with siblings like search_icons, but the purpose is clear enough for an agent to understand the tool's role.

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 guidance: 'use before searching if the query is ambiguous.' It indicates when to use this tool, though it doesn't explicitly name alternatives or when not to use it. The guidance is clear and actionable, so a 4 is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a 'service call' and cheaper than download-related tools, but it does not disclose whether results are paginated, what the response shape is, whether authentication is required, or other operational behavior.

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

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

The description is a single sentence that front-loads the core purpose and adds a concise cost-related note. Every part earns its place, and there is no redundant or vague 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?

The description is adequate for a basic search tool but incomplete without output schema or annotations. It does not explain what the returned collection data looks like, how pagination should be driven via next_page/prev_page, or 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?

Schema description coverage is 100%, so the parameters are already documented. The description adds no extra meaning about query syntax, limit defaults, or pagination token usage, placing it at the baseline.

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 states a specific verb and resource: 'Search Noun Project collections (icon sets).' This clearly differentiates it from retrieval/download siblings like get_icon and download_icon, and the '(icon sets)' qualifier separates it from search_icons.

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 it is used for searching collections rather than icons, but it does not explicitly state when to use this tool versus search_icons, get_collection, or icon_autocomplete. The 'cheaper than get_icon/download_icon' note adds some cost-based context but not clear selection criteria.

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 provided, the description carries the full burden of behavioral disclosure. It discloses the call is a cheap 'service call' and provides concrete quota context (2,000/month, 1,000/day), which shapes agent behavior. The warning against redundant get_icon follow-ups and the return-field list further clarify what the agent can rely on. It doesn't cover auth or error behavior, but for a search tool this is non-critical.

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

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

Four sentences, each earning its place: purpose, return values, inter-tool routing, and cost/pagination guidance. Front-loaded with the primary purpose, followed by actionable caveats. No fluff or repetition of schema content.

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

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

For a search tool with 9 parameters and no output schema, the description covers the essentials: what it returns, when to use alternatives, and quota-driven pagination strategy. It does not specify output shape in detail, but the listed return fields mitigate the missing output schema. Minor omissions like authentication or rate-limit exhaustion handling keep it from a 5.

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 the schema already documents all 9 parameters with descriptions and enums. The description adds meta-advice about query specificity and pagination cost, but no per-parameter meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource: 'Search The Noun Project for icons,' and enumerates the return fields (IDs, style, license, thumbnails, tags, attribution). This clearly distinguishes it from siblings like search_collections (collections) and get_icon (single icon) without requiring the agent to inspect schemas.

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 NOT to follow up: 'do NOT follow up with get_icon for every result.' Names the correct alternative for files: 'Use download_icon only when the user wants a file.' Also gives search strategy guidance: 'Prefer a specific query over pagination.' This is textbook when/when-not guidance with named alternatives.

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