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

No annotations are provided, so the description carries the full behavioral burden. It reveals the underlying library (Sharp) but says nothing about whether conversion fails on malformed SVG input, what happens when fromFormat does not match the actual iconData content, whether the result is returned inline or written somewhere, or any size limits — all material for a conversion tool.

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

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

Two short sentences, purpose front-loaded, no filler. The second sentence is thin but not wasted, since custom sizing is a real capability of the tool.

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

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

For a 4-parameter conversion tool with no annotations and no output schema, the description should explain return behavior and format-mismatch handling. It instead repeats a size capability already documented in the schema and misstates the conversion direction, leaving key operational questions unanswered.

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 50%: size and iconData are documented, but fromFormat and toFormat have no descriptions at all. The description's "Convert SVG icon to PNG" actually conflicts with the parameter semantics by implying a fixed direction, and it adds no meaning about the enum values or whether fromFormat is validated. With low coverage the description should compensate and 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?

States a concrete verb and resource ("Convert SVG icon to PNG") and names the implementation library, which is more than a tautology. However, it narrows the tool to SVG→PNG while fromFormat/toFormat enums permit svg and png in either direction, so the stated purpose undersells and mildly misdescribes the actual scope. It also gives no signal to distinguish it from siblings like optimize_svg or create_sprite.

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?

There is no statement of when to reach for this tool versus optimize_svg, create_sprite, or get_icon. The only usage hint is "Supports custom sizes," which is a capability claim, not guidance on selection or preconditions.

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 full behavioral burden. It mentions only that it generates a sprite sheet and is useful for web apps; it omits critical details such as whether it requires specific permissions, how it handles missing icons, whether it overwrites existing files, or what the output format actually is beyond 'SVG'.

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 that are front-loaded with the core purpose. The second sentence adds context but is somewhat redundant with the first, though not wasteful.

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 no annotations, no output schema, and 4 parameters (2 required), the description is insufficient. It lacks details on parameter usage, behavioral traits, return values, and error conditions, leaving the agent with significant gaps to call the tool 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 description coverage is 75%, so most parameters already have descriptions. The description does not add meaning beyond the schema; for example, it doesn't explain the 'icons' list format, the 'library' selection criteria, or the 'format' enum beyond what is in 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 uses a specific verb ('Generate') and resource ('SVG sprite sheet combining multiple icons'), and adds a use-case note. It clearly distinguishes itself from siblings like list_libraries, search_icons, and optimize_svg by focusing on sprite sheet creation.

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 gives an implied usage context ('Useful for web apps that need multiple icons'), but does not specify when to use it versus alternatives like get_multiple_icons or optimize_svg. No explicit when-not-to-use or prerequisite guidance is provided.

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 behavioral burden. It does disclose the return payload ("SVG content ready for use"), which is genuine value, but says nothing about error handling for unknown names, caching, or whether png/optimize options change the output despite the format parameter allowing png.

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 tight sentences, front-loaded with the core action, then the identifier convention, then the return value. No filler, though the third example icon (simple-icons:github) is slightly redundant padding.

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?

No output schema exists, so the description correctly fills that gap by stating it returns usable SVG. For a single-item getter with 83% schema coverage, this is nearly complete, though it never touches the library/format/optimize options that shape the return.

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 83%, so the schema already documents all six parameters. The description's prefix:name convention and examples duplicate the name parameter's own schema description, adding no new meaning; baseline 3 applies.

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 ("Get a specific icon") and the identifier scheme ("prefix:name"), which lets an agent distinguish it from search_icons and get_multiple_icons. It does not explicitly name those siblings, but the singling-out of "a specific icon" does implicit work.

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 when-not-to-use guidance, and no alternative tool is named. The agent is left to infer that this is for fetching one known icon vs. searching or bulk-fetching, but nothing in the text states that routing.

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 one meaningful behavioral constraint (maximum 50 icons per request), but says nothing about return format, error behavior on invalid names, or partial-failure handling for a batch call.

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, purpose front-loaded, no padding. The second sentence slightly restates the first ('efficient for getting several icons at once' echoes 'multiple icons'), costing a little density.

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 batch-read tool with no output schema and no annotations, the description covers purpose and the batch limit adequately but omits any hint about response shape or the role of format/optimize. Minimum viable, with clear 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?

Schema description coverage is 67%, so the schema already documents the name example and the optimize flag. The description's 'maximum 50 icons' adds a real constraint on the icons array, but format and optimize remain unexplained beyond their schema entries.

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 ('Fetch multiple icons in a single request') and the batch scope immediately distinguishes it from the single-icon sibling get_icon. It never names that sibling explicitly, but the 'multiple' framing makes the distinction clear without opening 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?

'Efficient for getting several icons at once' implies the batching use case versus get_icon, but there is no explicit when-to-use/when-not guidance and no mention of alternatives. Usage is inferable rather than stated.

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. 'Get available' signals a read-only, side-effect-free lookup, but nothing is said about return shape, pagination, or whether results are static or filtered.

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 front-loaded sentence with the resource, scope, and parenthetical examples. Every clause earns its place and nothing is 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?

For a one-parameter read-only tool this is close to sufficient, but with no output schema the description never indicates what a category result looks like, and it leaves the relationship to list_libraries unexplained.

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% and the single 'library' parameter is fully documented with its permitted values in the schema. The description adds only the concept of categories/styles, not any parameter-level 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 verb+resource ('Get available icon categories/styles from a library') with concrete examples (solid, outline, brands). It implicitly distinguishes itself from list_libraries by scoping to categories within one library, though it never names that sibling explicitly.

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 when-to-use, prerequisites, or alternative guidance. The only hint is that a library must already be known, with nothing said about when to prefer this over search_icons or list_libraries.

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 return content (library info, popular icon sets, usage examples), which is useful behavioral context, but says nothing about the read-only nature, ordering, or size of the result set. 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?

Three short sentences, front-loaded with the purpose and followed by the workflow cue and return summary. 'with details' is slightly redundant against the explicit return list, but nothing is wasted.

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 must describe returns, and it does enumerate the key payload (library info, popular icon sets, usage examples). For a parameterless read-only listing tool this is sufficient, though pagination or result-size limits are unaddressed.

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 takes zero parameters, so the baseline is 4. There is no parameter syntax to explain, and the description correctly focuses on what the call returns instead.

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: 'List all available icon libraries with details,' clearly distinct from sibling tools like search_icons or get_icon. It does not explicitly name a sibling it differs from, but the listing framing 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?

'START HERE to understand available icon sources' gives clear contextual guidance on when to reach for this tool first in the workflow. It stops short of naming when-not-to-use or explicit alternatives, but the entry-point framing is a strong usage signal.

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. It discloses what is removed (metadata, comments, unnecessary attributes) and the goal (reduce file size), which is useful behavioral context for a transformation tool. However, it omits that output structure may change (e.g., removeViewBox/removeDimensions can alter rendering), that this is a non-destructive transform returning modified content, and any auth or rate constraints.

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 tight sentences with the purpose front-loaded and no filler. It efficiently conveys the engine and the categories of content removed.

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?

No output schema exists, so the description should ideally indicate what is returned (optimized SVG string), and the 16 nested option flags carry defaults whose behavior is not summarized. It is adequate but leaves meaningful gaps for a tool with this much internal configuration.

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 svgContent and the options object. The description adds no detail about the nested options (cleanupIDs, removeViewBox, etc.) beyond what is in the schema, so baseline 3 applies.

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 ('Clean and optimize SVG content') and names the underlying engine, SVGO. This distinguishes it from sibling tools like convert_icon or create_sprite, which handle icons in other ways, though it doesn't explicitly frame itself against those siblings.

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 no guidance on when to use this versus alternatives, no prerequisites, and no exclusions. An agent must infer that this is the tool for shrinking raw SVG markup.

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 behavioral burden, and it says only that results are 'curated icon suggestions with usage examples.' It does not state determinism, what happens for an unsupported use case, result ordering, or whether limit truncates silently.

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?

Purpose is front-loaded in the first sentence and the return value follows. The 20-item use-case list is long but functional rather than filler, since it defines the accepted input domain.

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 does mention what comes back (curated suggestions plus usage examples), which is the key gap to cover. A recommendation-only read tool with a fully documented 3-param schema needs little more.

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 limit, style, and useCase are already documented in the schema. The description adds the valid use-case vocabulary beyond the schema's short example list, which is useful but marginal; baseline 3 applies when the schema does the heavy lifting.

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 ('Get AI-friendly icon recommendations') and scopes it to UI use cases, which separates it from raw lookups like get_icon or search_icons. However, it never names or contrasts those siblings explicitly, so the agent must infer the boundary between 'recommend' and '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?

The enumeration of supported use cases implies when the tool is applicable, giving an implicit usage signal. It offers no explicit when-to-use vs when-not guidance and does not point to search_icons/get_icon as alternatives for other needs.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format ('prefix:name') and the default library, which is genuinely useful, but says nothing about result ordering, pagination when limit caps results, or behavior on no matches.

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 the core capability front-loaded and zero filler. The return-format example earns its place because there is no output schema.

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 a fully documented schema and no output schema, the description supplies the essential missing piece: the shape of the returned icon identifier. It is nearly complete, though it could mention the default result limit behavior given the absence of an output schema.

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

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

Schema description coverage is 100%, so the schema already documents query, limit, and libraries, establishing a baseline of 3. The description reinforces the libraries default and explains the returned 'prefix:name' shape, but adds no new syntax or constraint details 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 verb and resource ('Search for icons') plus the scale (200,000+ icons, 150+ icon sets), which is far more specific than the bare name. It does not, however, explicitly distinguish itself from siblings like recommend_icons or get_icon, so an agent must infer the boundary.

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 says to use the 'iconify' library for best results and notes it is the default, which is useful guidance. But it gives no when-to-use vs. when-not framing and never points to recommend_icons (semantic/recommendation search) or list_libraries as alternatives.

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