Search 161,000+ free icons; get SVG (single/bulk), PNG, related icons, webfont classes. No API key.
Scored across 8 tools
Each tool targets a distinct retrieval mode: single PNG URL, single SVG, batch SVG, popular icons, related icons, categories, keyword search, and webfont search. Cross-references in the descriptions actively prevent confusion by telling the agent which tool to use instead. No two tools appear to do the same job.
All tool names follow a consistent verb_noun snake_case pattern: get_*, list_*, and search_*. The only variant, get_icon_svg_bulk, reads as a clear modifier of get_icon_svg rather than a different naming convention.
Eight tools is a well-scoped size for an icon lookup service: search, browse, and retrieval are each covered without redundancy or bloat. Every tool has a clear place in the workflow and earns its inclusion.
The surface covers discovery well with search, popular, related, and categories, plus retrieval through PNG, single SVG, bulk SVG, and webfont outputs. A minor gap is the lack of a bulk PNG counterpart, though agents can work around it by calling get_icon_png per icon or using the URLs from search_icons.
Return direct PNG download URLs (transparent background) for one Infyicon icon id, either a single size or all seven sizes 16/24/32/64/128/256/512 px. Use when the user needs an image file or src (email, docs, chat, platforms that cannot render SVG); use get_icon_svg instead when inline vector markup is wanted. Read-only, no auth; returns URLs only (no binary data); returns an error for a malformed id or an unknown icon. Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 (slug_number) | |
| size | No | Optional single size in px; omit to get all seven sizes |
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.
Return the full, ready-to-embed SVG markup of ONE Infyicon icon by id (slug_number, e.g. hammer-16_66091 - get ids from search_icons). Use when the user wants inline SVG for a single icon; use get_icon_svg_bulk for 2-20 icons in one call, and get_icon_png when they need a raster image URL instead of markup. Read-only, no auth; returns an error for a malformed id or an unknown icon; if the SVG is over 200 KB the response carries svg_url instead of inline markup. Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Icon id like hammer-16_66091 (slug_number) |
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.
Return ready-to-embed SVG markup for 1-20 Infyicon icons in one call (pass an array of ids from search_icons). Use when building a UI, icon set or design system so you fetch several icons at once instead of calling get_icon_svg repeatedly; use get_icon_svg for a single icon. Read-only, no auth; ids beyond the first 20 are silently dropped; each bad or unknown id gets a per-item error while the rest still succeed; oversized SVGs (>200 KB) return svg_url instead of markup. Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Array of 1-20 icon ids, e.g. ["home-2_101", "gear-1_202"] |
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.
Return up to 30 popular/featured Infyicon icons (ids, names, styles, page/SVG/PNG URLs) without a search query - use when the user just wants "a nice icon" or a starting set and has not named a subject. Use search_icons instead when the user describes a subject, and get_related_icons instead when they already have an icon and want variations. Read-only, no auth; always returns results (never errors on empty input). Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 12, max 30) | |
| style | No | Optional: restrict to one style |
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.
List the most popular Infyicon icon categories (name, slug, icon count, category page URL at https://infyicon.com/free-icons/), ordered by popularity. Use to browse or suggest topics before searching, or to link the user to a category page; use search_icons to actually fetch icons for a topic. Read-only, no auth; no pagination (limit up to 100). Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max categories (default 30, max 100) |
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.
Search 161,000+ free Infyicon vector icons by keyword and return up to 30 matches per page, each with icon id (slug_number), name, style, page URL, direct SVG URL, 512px PNG URL and tags. Styles: outline (black line), fill (black solid), color-outline, color-fill. Use this first whenever the user describes what icon they want; then pass an id to get_icon_svg, get_icon_svg_bulk or get_icon_png. Use get_popular_icons instead when there is no search term, and search_uicons instead when the user wants a CSS webfont class rather than an SVG/PNG file. Read-only, no auth, no API key; empty query returns an error; total_matches + next_offset are returned for paging. Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per page (default 10, max 30) | |
| query | Yes | What to search for, e.g. "shopping cart", "doctor", "hammer" (1-4 plain words work best) | |
| style | No | Optional: restrict to one style; omit to get all four styles mixed | |
| offset | No | Optional: skip this many results for pagination. Pass next_offset from the previous response to get the next page. |
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.
Search the Infyicon UI webfont (61,000+ glyphs) by glyph name and return matching CSS class names (regular ii-r-, solid ii-s-) plus a ready tag and the stylesheet link https://infyicon.com/uicons/uicons.css. Use ONLY when the user wants an icon font / CSS class (like Font Awesome usage); use search_icons for SVG or PNG icon files. Case-insensitive substring match, up to 40 matches, no pagination; empty name returns an error. Read-only, no auth. Free with attribution to infyicon.com.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Glyph name or part of it to search, e.g. "home", "arrow" |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
bulk_svgget_icon_png2 fields changedInput schema / properties / id / descriptionPrevious value: -"Icon id like hammer-16_66091"New value: +"Icon id like hammer-16_66091 (slug_number)"Input schema / properties / size / descriptionPrevious value: -"Optional single size; omit for all sizes"New value: +"Optional single size in px; omit to get all seven sizes"get_icon_svg1 field changedInput schema / properties / id / descriptionPrevious value: -"Icon id like hammer-16_66091"New value: +"Icon id like hammer-16_66091 (slug_number)"get_icon_svg_bulkget_popular_iconsget_related_iconslist_categories1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max categories (default 30)"New value: +"Max categories (default 30, max 100)"popular_iconsrelated_iconssearch_icons4 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 10)"New value: +"Max results per page (default 10, max 30)"Input schema / properties / offset / descriptionPrevious value: -"Optional: skip this many results for pagination. Use next_offset from a previous call to get the next page."New value: +"Optional: skip this many results for pagination. Pass next_offset from the previous response to get the next page."Input schema / properties / query / descriptionPrevious value: -"What to search for, e.g. \"shopping cart\", \"doctor\", \"hammer\""New value: +"What to search for, e.g. \"shopping cart\", \"doctor\", \"hammer\" (1-4 plain words work best)"Input schema / properties / style / descriptionPrevious value: -"Optional: restrict to one style"New value: +"Optional: restrict to one style; omit to get all four styles mixed"search_uiconsuicons_lookupbulk_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_lookupIcons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
320K+ open-source SVG icons: 12 tools, anonymous metadata search; SVG, exports, collections via Pro.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Add one secure layer between your agents and this server.
