Infyicon

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds valuable behavior beyond annotations: returns URLs only (no binary data), errors on malformed/unknown ids, requires attribution, and supports all seven sizes or one requested size. No contradiction with annotations.

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

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

Every sentence earns its place: purpose, usage context, behavioral notes, and attribution. Information is front-loaded and compact without being terse.

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 URL-returning tool with a complete schema and strong annotations, the description covers return format, error behavior, auth state, size options, and the sibling alternative. Nothing needed for correct invocation is missing.

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 well. The description reinforces the two calling modes (single size vs all sizes) and lists the exact sizes, but does not add substantial new 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?

States a specific action and resource: returns direct PNG download URLs with transparent backgrounds for one Infyicon icon id. Clearly distinguishes itself from get_icon_svg by targeting PNG output and file/<img> use cases.

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

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

Explicitly says when to use this tool (image file or <img> src for environments that cannot render SVG) and when to use get_icon_svg instead. Also clarifies no auth is required and that it returns URLs only.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral detail: no auth required, error behavior for malformed or unknown ids, and a size-based fallback where svg_url is returned instead of inline markup. It also notes attribution requirements, giving a fuller operational picture.

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

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

Every sentence carries functional weight: primary purpose, usage routing, behavioral caveats, and attribution. The most important information is front-loaded, and the description is dense without being padded.

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 a single required parameter and no output schema, the description provides everything needed to call the tool correctly: id format, id source, return type, error behavior, fallback condition, and alternative tools. Nothing essential is missing.

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

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

The schema already documents the parameter at 100% coverage, but the description adds practical meaning with a concrete id format example ('hammer-16_66091') and directs the agent to search_icons for valid ids. This goes beyond the schema text.

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 action (return SVG markup), the resource (ONE Infyicon icon by id), and the exact usage context. It explicitly distinguishes itself from siblings like get_icon_svg_bulk and get_icon_png, so an agent can select it without ambiguity.

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

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

It provides explicit when-to-use guidance ('Use when the user wants inline SVG for a single icon') and names alternatives with their conditions ('use get_icon_svg_bulk for 2-20 icons... use get_icon_png when they need a raster image URL'). It also tells the agent where to obtain valid ids, via search_icons.

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 multiple non-obvious behaviors beyond annotations: ids beyond 20 are silently dropped, per-item errors with partial success, oversized SVGs return svg_url instead of markup, and attribution requirement. No contradiction with readOnly/idempotent annotations.

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

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

Four sentences pack purpose, usage, limits, error handling, and return behavior without repetition. Front-loaded with the main result, keeping the call condition first.

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 bulk fetch with no output schema, it covers the request parameters, behavior limits, error semantics, fallback return, and licensing. An agent has enough to invoke and interpret results correctly.

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

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

Schema already documents the ids array with min/max and example (100% coverage), so baseline is 3. Description adds meaningful usage semantics: ids should come from search_icons, the 20-item cap behavior, and partial-error handling, which improves correctness.

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 + resource ('Return ready-to-embed SVG markup for 1-20 Infyicon icons in one call') and explicitly differentiates from get_icon_svg for single icons. The bulk behavior is 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?

Explicitly says when to use: 'when building a UI, icon set or design system' and when to use alternative: 'use get_icon_svg for a single icon'. Also tells where ids come from: 'array of ids from search_icons'. This is above and beyond.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description goes further by adding 'no auth', 'always returns results (never errors on empty input)', and 'Free with attribution to infyicon.com', which are not available in the annotations. This meaningfully increases the agent's understanding of safety and side effects.

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 front-loaded with the core purpose in the first sentence, followed by usage guidance, and finally behavioral/legal notes. Every sentence carries necessary information—no filler or repetition. Three sentences is appropriate for the tool's complexity.

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

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

With no output schema, the description explains the return shape by listing fields (ids, names, styles, URLs). It also covers usage conditions, auth requirements, error behavior, and attribution. For a 2-param read-only tool with full annotation coverage, this is 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?

The input schema already provides 100% coverage, describing both limit and style with constraints and defaults. The description adds 'up to 30' which matches the schema's max, and mentions 'without a search query' to clarify there is no query param, but this is already evident from the schema. No new semantic meaning is added 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 states a specific verb ('Return') and resource ('popular/featured Infyicon icons') with concrete output fields (ids, names, styles, URLs). It also distinguishes this tool from search_icons and get_related_icons, making it clear what this tool is not for.

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

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

It explicitly states when to use this tool: 'when the user just wants "a nice icon" or a starting set and has not named a subject.' It also names alternatives with their conditions: search_icons for described subjects, get_related_icons for variations from an existing icon. No inference needed.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable extra context: the error condition for non-slug_number ids, exclusion of the source icon from results, and the free-with-attribution requirement. These go beyond the annotations without contradicting them.

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 with clear front-loading of the core action and usage intent. It includes some redundancy (e.g., 'Read-only' is already in annotations) and could be tightened, but it is not verbose or disorganized.

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 absence of an output schema, the description covers key behavioral aspects: result count, theme/style filtering, error handling, and exclusion of the source icon. It does not specify the exact return structure (e.g., list of ids vs. objects), but that may be inferred from context. Overall, it provides sufficient information for correct invocation.

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

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

Schema coverage is 100%, with both `id` and `limit` already described with formats and constraints. The description mentions the id format ('slug_number') and source tools, but this largely reiterates the schema. It does not add substantial new meaning beyond what the schema provides, so a 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 tool's function: taking an icon id and returning up to 30 related icons in the same theme and styles. It distinguishes itself from search_icons by explicitly noting when to use each, making the 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?

Provides explicit guidance on when to use this tool ('for offering variations, alternatives or building a matching icon set') and when to use the alternative ('Use search_icons instead when you do not yet have an id'). It also mentions the id format requirement, covering key constraints.

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

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

Annotations already declare readOnly, idempotent, and non-destructive hints, and the description adds meaningful behavioral context: no auth required, no pagination, a hard limit of 100, and a free-with-attribution requirement. It also reveals output ordering by popularity, going well beyond the annotations.

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

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

Three compact sentences front-load the core listing behavior and output, then provide usage routing, then constraints. Every sentence contributes new information and there is no filler or repetition.

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

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

For a simple single-parameter tool with no output schema, the description is complete: it covers output fields, ordering, use cases, alternative tool routing, auth, pagination, and attribution. An agent has everything needed to invoke it correctly.

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

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

The schema already describes the only parameter (limit) with default and maximum values, and schema description coverage is 100%. The description adds no significant parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

Description uses a specific verb ('List'), a specific resource ('Infyicon icon categories'), and enumerates the returned fields (name, slug, icon count, category page URL) with ordering by popularity. It also differentiates itself from sibling tools by naming search_icons as the tool for actually fetching 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 states when to use the tool: browse or suggest topics before searching, or link to a category page. It also gives an exclusion by directing agents to use search_icons when actual icons are needed, which is clear routing versus alternatives.

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

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

Annotations already mark the tool read-only, idempotent, and non-destructive, but the description adds substantial behavioral context: no auth or API key required, empty queries return an error, pagination via total_matches and next_offset, and free-with-attribution policy. No contradictions with annotations.

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

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

The description is dense but every sentence carries distinct value: core behavior, return fields, style meanings, usage routing, and operational caveats. The most important information is front-loaded, and no sentences are 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?

For a search tool with four parameters, no output schema, and several siblings, the description provides everything needed to invoke it correctly and interpret the result: result fields, style options, pagination signals, error behavior, and routing to downstream tools. Nothing critical is missing.

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?

Although the schema already covers all four parameters at 100%, the description enriches them: it explains the four style values in plain terms, notes that query works best with 1-4 plain words, gives concrete examples, and clarifies that offset should be fed from next_offset. This is meaningfully more than the schema alone 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 opens with a specific verb and resource: 'Search 161,000+ free Infyicon vector icons by keyword'. It states exactly what is returned (icon id, name, style, URLs, tags), clearly distinguishing this search tool from related retrieval and listing 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 gives explicit routing guidance: use this first whenever the user describes an icon, pass an id to get_icon_svg/get_icon_svg_bulk/get_icon_png afterward, use get_popular_icons when there is no search term, and use search_uicons when a CSS webfont class is wanted. This leaves no ambiguity about when to choose 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?

Annotations already signal read-only/idempotent/non-destructive, and the description adds substantial behavior: case-insensitive substring matching, up to 40 matches, no pagination, empty-name error, no auth, and attribution requirement. This goes well beyond what the annotations convey and does not contradict them.

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

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

The description is dense but every clause earns its place: it front-loads the core purpose, then covers output format, usage guidance, matching limits, auth, and attribution. No filler or 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?

Despite lacking an output schema, the description tells the agent exactly what the tool returns: CSS class names in both variants, a ready <i> tag, and the stylesheet link. It also covers edge behavior (empty name, match limit) and the single parameter, making the tool fully callable from the description alone.

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% and the schema describes the name parameter, so the baseline is 3. The description adds real semantic value by defining the matching mode (case-insensitive substring), examples ('home', 'arrow'), and the empty-name error condition.

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 and resource: search the Infyicon UI webfont by glyph name and return CSS class names plus a ready <i> tag. The description clearly distinguishes this from search_icons by framing it as the icon-font/CSS-class counterpart to SVG/PNG search.

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 ONLY when the user wants an icon font / CSS class (like Font Awesome usage)' and names the alternative tool for SVG/PNG files. This gives an agent a clear decision rule rather than leaving selection to inference.

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