Search 161,000+ free hand-drawn Infyicon icons in four matching styles and fetch ready-to-embed SVG markup or PNG URLs, plus CSS class lookup for the 61,000-glyph Infyicon UI webfont. Free with attribution, no API key required.
Scored across 8 tools
Each tool targets a clearly distinct retrieval mode: search, popular, related, categories, single SVG/PNG, bulk SVG, and webfont CSS lookup. Even similar tools like get_icon_svg and bulk_svg are cleanly separated by singular vs batch use.
Tool names are all lowercase snake_case and readable, but they mix action-led names like get_icon_svg, list_categories, and search_icons with descriptor-led names like popular_icons and related_icons. The pattern is not fully consistent, though the meaning remains clear.
Eight tools is well-scoped for an icon library: search, browse, related discovery, single-format retrieval, batch retrieval, and webfont lookup. Each tool serves a distinct purpose without unnecessary redundancy.
The toolset covers the complete icon-serving workflow: discovering icons via search, categories, popular, and related suggestions, then retrieving them as SVG or PNG, including batch SVG. The uicons_lookup tool fills the webfont-specific niche, leaving no obvious dead ends.
Fetch the SVG markup for up to 20 Infyicon icons in one call (pass an array of ids). Use when building a UI or icon set so you grab several at once instead of calling get_icon_svg repeatedly.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of icon ids, e.g. ["home-2_101", "gear-1_202"] |
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 adds useful behavioral context such as the 'up to 20' limit and 'one call' semantics. However, it does not disclose what happens for invalid IDs or when more than 20 are passed, nor the exact response shape.
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 efficient sentences: the first states the action and constraint, the second provides the usage context and differentiates it from the sibling. 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 single-parameter tool with high schema coverage, the description is largely complete: it gives the action, batch size, and usage context. The only notable gap is the absence of an output-shape note, but given there is no output schema, the description still provides enough to invoke 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?
The input schema already provides 100% coverage, including format and an example for the sole required parameter. The description adds the 'up to 20' cap, which is helpful, but it does not add significant meaning beyond what the schema already conveys.
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 ('Fetch'), names the resource ('SVG markup for up to 20 Infyicon icons'), and specifies the input shape ('pass an array of ids'). It clearly distinguishes itself from get_icon_svg by emphasizing the batch capability.
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 states when to use the tool ('when building a UI or icon set') and explicitly contrasts it with an alternative ('instead of calling get_icon_svg repeatedly'). It does not spell out exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get direct PNG download URLs (16-512px, transparent background) for an Infyicon icon id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 | |
| size | No | Optional single size; omit for all sizes |
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 convey key output traits: 'direct PNG download URLs', sizes ranging 16-512px, and 'transparent background'. However, it does not mention any error behavior, rate limits, or whether an invalid id returns no URLs or fails, so it falls short of full transparency.
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 sentence conveys the tool's core purpose, output type, size range, transparency trait, and input requirement without redundancy. It is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small, well-documented two-parameter tool with high schema coverage, the description is mostly sufficient. It omits an explicit return-shape explanation for the 'all sizes' case, but since output schema is absent and the schema already covers the optional size parameter, the description plus schema should allow an agent to invoke 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 100%, with both 'id' and 'size' already documented in the input schema. The description adds the PNG/transparency context but does not elaborate on parameter behaviors beyond what the enum and property descriptions already provide. 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?
The description clearly states a specific verb ('Get'), a specific resource ('direct PNG download URLs'), and a scope ('for an Infyicon icon id'). The explicit mention of 'PNG' naturally distinguishes it from the sibling tool get_icon_svg.
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 makes it obvious that the tool is for retrieving PNG download URLs and implicitly not for SVG retrieval, but it does not explicitly name alternatives or state when not to use this tool. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full SVG markup of an Infyicon icon by id (format: slug_number, e.g. hammer-16_66091 — get ids from search_icons). Returns ready-to-embed SVG code.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly reveals that the operation returns ready-to-embed SVG markup rather than a URL or binary file. It does not describe error conditions or authentication, but for a simple one-parameter fetch this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the action and output type are front-loaded, and the second sentence provides the necessary id-format and upstream source guidance. Every part 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 one-parameter tool with no output schema, the description fully covers what is needed: how to get the id, what the tool returns, and in what form. There is no missing information that would prevent correct usage.
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 already gives the same id format and example. The description adds a useful provenance hint ('get ids from search_icons'), but most parameter meaning is already present in the input 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 specific action and resource: getting the full SVG markup of an Infyicon icon by id. It includes the id format and names the sibling tool (search_icons) as the source, making it easy to distinguish from get_icon_png and the other 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?
It explicitly tells callers to get ids from search_icons and implies the tool is the right choice when SVG source code is needed. It does not explicitly say to use get_icon_png for raster output, but the context makes that distinction reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most popular Infyicon icon categories with icon counts. Category pages live at https://infyicon.com/free-icons/.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max categories (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it delivers key behavioral context: the tool returns categories ordered by popularity, includes icon counts, and category slugs map to the URL pattern provided. It does not mention failure modes or pagination, but for such a simple list tool the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. The first front-loads the core purpose and result content, the second adds a valuable URL pattern. 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?
For a zero-required-parameter list tool with no output schema, the description plus the schema fully covers what the agent needs: what it lists, what each item includes, the URL pattern, and the optional limit. A bit more detail on result shape would make it 5, but it is otherwise 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 only parameter 'limit' is already fully described in the schema with min, max, and default value. The description itself may not mention the parameter, but with 100% schema coverage the baseline applies and no critical semantic information is 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?
States a specific verb ('List') and resource ('Infyicon icon categories'), with the scope qualifier 'most popular' and the output content 'icon counts'. It makes the tool distinct from sibling icon-download/search tools without needing to name them.
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 the tool is for browsing category listings, especially popular ones, but it does not give explicit when-to-use or when-not-to-use guidance compared to search_icons or other siblings. The intended use is inferable rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get popular/featured Infyicon icons without a search query — ideal when the user just wants "a nice icon" for something. Optionally restrict to one style. Returns ids, styles, page/SVG/PNG URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 12) | |
| style | No | Optional: restrict to one style |
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 that the call requires no search query, supports optional style restriction, and returns ids, styles, page/SVG/PNG URLs. However, it does not mention pagination, result limits, or other operational behavior beyond what the schema already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main purpose and use case are front-loaded, followed by the optional parameter and return value summary. Every phrase 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?
The tool is simple, has only two optional parameters, and no output schema. The description covers the core return fields and the no-query behavior. It could mention default/max limits explicitly, but the schema already covers those, so the description is sufficiently complete 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 description coverage is 100%, so the schema already documents both parameters. The description adds only a minor clarification with 'Optionally restrict to one style', which is already reflected in the schema's enum and optional status. This aligns with the baseline 3.
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 and resource: 'Get popular/featured Infyicon icons'. It also differentiates the tool from search-based alternatives with 'without a search query', though it does not name a specific sibling tool, so it stops short of the strongest sibling differentiation.
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 clear context for when to use the tool: 'ideal when the user just wants "a nice icon" for something'. It does not explicitly state when not to use it or name alternatives, but the usage scenario is concrete enough for an agent to route appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 161,000+ free Infyicon vector icons. Returns matches with icon id, style, page URL, SVG and PNG URLs. Styles: outline (black line), fill (black solid), color-outline, color-fill. Free to use with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10) | |
| query | Yes | What to search for, e.g. "shopping cart", "doctor", "hammer" | |
| style | No | Optional: restrict to one style | |
| offset | No | Optional: skip this many results for pagination. Use next_offset from a previous call to get the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It proactively discloses return contents, style options, and licensing terms, but does not mention pagination behavior or next_offset usage.
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 dense sentences communicate purpose, scale, return fields, style variants, and licensing. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the main result contents and style options. It omits pagination details, though the offset parameter schema partially covers 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 description coverage is 100%, so the schema already documents all parameters with descriptions and examples. The description adds stylistic and output context but does not substantially deepen parameter-level understanding.
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 (Search), a concrete resource (161,000+ Infyicon vector icons), and the returned fields. This clearly differentiates it from sibling tools like get_icon_svg, popular_icons, and related_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 clearly establishes the use case: keyword search for icon assets. It does not explicitly name alternative tools or state when not to use this tool, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up CSS class names in the Infyicon UI webfont (61,000+ glyphs). Use the returned class like with stylesheet https://infyicon.com/uicons/uicons.css
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Glyph name to search, e.g. "home", "arrow" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of explaining side effects and limits. It implies a read-only lookup by saying 'look up' and shows the expected result pattern, but it does not disclose match semantics, such as exact match, partial search, case-insensitivity, what happens on no match, or return shape. It adds some behavioral context through the usage example, but important traits remain unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that deliver purpose, a usage example, and the needed stylesheet link. There is no unnecessary wording, and the core purpose 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?
The definition works for a one-parameter lookup tool because the schema is clear and the usage example helps the agent call it correctly. However, the description does not explain the result format, whether multiple matches are returned, or how this lookup differs from search_icons. Without an output schema or note differentiating it from sibling tools, an agent could still be uncertain about invocation expectations.
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 single parameter `name` is completely documented in the input schema with the description 'Glyph name to search' and a couple of examples, so schema coverage is 100%. The tool description does not add any additional meaning about the parameter beyond that, 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 action is 'Look up CSS class names in the Infyicon UI webfont' and gives a concrete usage example with an <i> tag. It specifically identifies the resource (CSS class names) and the data source (61,000+ glyph webfont), distinguishing it from sibling tools that return PNG, SVG, or category lists.
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 tells the agent how to use an output like <i class='ii-r-home'></i> and supplies the stylesheet URL, but it does not say when to choose this tool over search_icons, get_icon_png, or get_icon_svg. The 'when to use' context is implied rather than explicit, and no exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bulk_svgpopular_iconsrelated_iconssearch_icons1 field changedInput schema / properties / offsetAdded value: +{
+ "description": "Optional: skip this many results for pagination. Use next_offset from a previous call to get the next page.",
+ "minimum": 0,
+ "type": "integer"
+}get_icon_pngget_icon_svglist_categoriessearch_iconsuicons_lookup
