Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
Scored across 5 tools
Each tool has a distinct primary purpose (search, brand lookup, fetch SVG, list sets, feedback). find_brand_logo and search_icons overlap somewhat since search_icons also covers brand logos, but the descriptions clarify that find_brand_logo returns style/hex metadata and matches by domain while search_icons is keyword-based.
All five tools follow a clean verb_noun snake_case pattern: find_brand_logo, get_icon, list_collections, search_icons, send_feedback. No mixing of conventions or vague verbs.
Five tools is well-scoped for an icon library: search, brand lookup, fetch, enumerate collections, and a feedback channel. Nothing feels redundant or missing at the count level.
Core icon workflows (search, find brand, fetch SVG, list sets) are covered, and the download-URL pattern handles bulk retrieval. A way to enumerate icons within a specific collection (browse by prefix) is missing, but agents can work around it via search.
Find the logo of a company, product or technology by name or domain (e.g. "Stripe", "vercel.com"). Returns matching icons from several logo packs as "prefix:name" with their style (color, mono, wordmark), plus the official brand hex color when known. Fetch the SVG of a result by its "prefix:name". Where the client supports it, the user sees the color and a clickable logo grid.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Brand name or domain, e.g. "GitHub" or "github.com" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the result format ('prefix:name'), the style variants returned, the official hex color, and the fact that SVG retrieval requires a follow-up 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?
Front-loaded with the core action and input, then return shape and next step. The final sentence about client rendering (color swatch and clickable grid) is the least essential, but the overall length is reasonable for the amount of return information conveyed.
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 carries the return-value burden and does so well: match format, style metadata, and hex color. It omits result-count limits and no-match behavior, which keeps it short of fully complete for an open-ended lookup.
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 a single parameter, so the schema already documents 'brand' fully. The description's examples ('Stripe', 'vercel.com') mirror what the schema already gives, adding no new syntax or format constraints — 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 (find), resource (brand logo), and accepted inputs (company/product/technology name or domain), which cleanly separates it from generic icon tools. It does not, however, name any sibling tool, so an agent must infer the boundary with search_icons and get_icon.
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?
Usage is implied by the input shape — use this when you have a brand name or domain rather than a visual description. There is no explicit when-not guidance and no alternative (search_icons, get_icon) is named, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the raw SVG markup for a single icon by "prefix:name". Icons over 32 KB (some emoji and flags) return their size and a URL to grab the SVG from without loading it into context.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Icon name as "prefix:name", e.g. "mdi:arrow-right" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: icons over 32 KB (emoji, flags) do not return markup but instead return size plus a URL, which changes how an agent must handle the result. It omits any error/not-found or auth behavior, so not a 5.
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, no filler, and the core action plus identifier format are front-loaded before the edge-case note. Every clause carries information.
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 carries the return-value burden and does so for both the normal case (raw SVG markup) and the oversized case (size + URL). It is nearly complete for a one-parameter read tool, though it says nothing about failure modes or response shape beyond the markup itself.
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?
There is a single parameter and schema description coverage is 100%; the schema already documents the "prefix:name" format with an example. The description repeats the same format guidance without adding syntax, validation, or fallback semantics for the name argument.
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 ('Fetch') and resource ('raw SVG markup for a single icon'), plus the exact identifier format. It is clearly distinguishable from search_icons (which finds icons) and list_collections without opening any schema.
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 usage (call it when you need the actual SVG source) and the 32 KB rule tells the agent what to expect, but it never names an alternative or states when NOT to use this tool versus search_icons. 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.
List every hosted icon set in one response, grouped by category, with each set's prefix, name and icon count. Call it once per conversation and reuse the result; it does not count toward usage limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world). The description adds genuinely useful behavioral context beyond them: the entire catalog is returned in a single response, and the call does not count toward usage limits, which affects how aggressively an agent should avoid repeating it.
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 tightly-packed sentence front-loads the core verb and scope, then tacks on the caching and quota caveats. No filler, no restatement of the title or annotations.
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 input parameters and no output schema, the description carries the burden of explaining what comes back, and it does: grouped-by-category sets with prefix, name, and icon count, plus the reuse and quota behavior. An agent has everything needed to call this correctly and cache the result.
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 for the description to compensate for. The description instead documents the shape of the returned entries (prefix, name, icon count), which is a reasonable substitute given no output schema exists.
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 (every hosted icon set) and even previews the return shape (grouped by category, with prefix, name, icon count). This cleanly distinguishes it from siblings get_icon and search_icons, which operate on individual or queried icons rather than enumerating the catalog.
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?
"Call it once per conversation and reuse the result" gives clear operational context for when to invoke it, and the catalog-enumeration framing implies it precedes per-icon lookups. However, it never explicitly names get_icon or search_icons as the follow-up alternatives, so the routing guidance is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search open-source SVG icons and brand logos across hundreds of icon sets by keyword. Returns icon names as "prefix:name", no SVG content. To save many icons as files, download https://i.allsvgicons.com//.svg directly instead of loading each one into context. Where the client supports it, the user also sees a clickable icon grid and can pick one.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, capped at 20 | |
| query | Yes | Search keyword | |
| picker | No | Show the icon grid to the user (default true). Pass false for searches the user does not need to see | |
| prefix | No | Scope the search to a single icon set prefix, e.g. "mdi" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuine behavioral detail beyond them: results are identifiers in 'prefix:name' form with no SVG payload, and a clickable grid is surfaced to the user when the client supports it. That UI side effect is exactly the kind of trait annotations cannot express.
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, front-loaded with purpose and return shape, then workflow advice and UI behavior; each sentence carries distinct information. Slightly dense but no filler, and nothing important is buried.
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 search with no output schema, the description covers what the agent needs: what is searched, what is returned (and what is not), how to obtain the actual files, and the user-visible picker behavior. Safety is handled by annotations, so no gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the 'prefix:name' shape that the prefix parameter scopes and that prefix/name compose the download URL, tying the parameters to the return format and a follow-up action. This goes beyond the schema's one-line parameter descriptions.
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) and resource (open-source SVG icons and brand logos) with clear scope (hundreds of icon sets, by keyword). It implicitly separates itself from get_icon by noting it returns names and no SVG content, but it never names a sibling, so an agent must infer the boundary with find_brand_logo, whose territory ('brand logos') this description claims.
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?
Gives concrete when-to-use context (keyword search over many sets) and an explicit when-not alternative: for bulk file saving, hit the i.allsvgicons.com URL directly rather than loading icons into context. It stops short of routing the agent to get_icon or find_brand_logo for single-icon or brand-logo lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send feedback about this icon server to its maintainer: bugs, missing icons, feature requests, pain points, and whether it saved the user time. Good moments to offer it: after the user finishes an icon task, cannot find an icon, or hits a limit. Ask the user first and send only after they agree; show them the message before sending. Most useful content: what they were building, what worked, what was missing or slow, what to add next, and rough time saved. Do not include personal data, code, or secrets. One-way: no reply comes back. If the user wants a reply, the result includes a prepared email link to give them. Limit: 3 messages per day.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Feedback message, max 1000 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the one-way nature (no reply comes back), the fallback (a prepared email link in the result), the rate limit (3 messages per day), consent requirements, and a privacy prohibition on personal data, code, or secrets. The openWorldHint/destructiveHint flags are complemented rather than merely restated.
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 clause, followed by timing, consent, content guidance, privacy, delivery semantics, and limits. Every sentence carries a distinct actionable instruction, with 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, non-destructive tool with no output schema, the description covers everything needed: when to call, consent handling, what to put in the message, what to exclude, that no reply returns, and the daily cap. Nothing an agent needs to invoke this correctly 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 coverage is 100% and the length bounds already live in the schema, so the baseline is 3. The description adds real semantic value by specifying what makes a good message (what they were building, what worked, what was missing or slow, what to add next, time saved) and what must not be included, which meaningfully constrains content beyond the raw string type.
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 (send) plus resource (feedback about this icon server) and its recipient (the maintainer). It is unmistakably distinct from the sibling tools get_icon, list_collections, and search_icons, which are all read/lookup operations.
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?
Gives explicit trigger moments ('after the user finishes an icon task, cannot find an icon, or hits a limit') and an explicit precondition ('ask the user first and send only after they agree; show them the message before sending'). No inference is required about when to invoke it.
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.
find_brand_logosearch_icons1 field changedInput schema / properties / pickerAdded value: +{
+ "description": "Show the icon grid to the user (default true). Pass false for searches the user does not need to see",
+ "type": "boolean"
+}list_collections3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / limitRemoved value: -{
- "description": "Max results per page, default 50, capped at 100",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / offsetRemoved value: -{
- "description": "Pagination offset, default 0",
- "minimum": 0,
- "type": "integer"
-}send_feedback2 fields changedInput schema / properties / message / descriptionPrevious value: -"Feedback message, max 500 characters"New value: +"Feedback message, max 1000 characters"Input schema / properties / message / maxLengthPrevious value: -500New value: +1000get_iconlist_collectionssearch_iconssend_feedbackIcons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
320K+ open-source SVG icons: 12 tools, anonymous metadata search; SVG, exports, collections via Pro.
Search 161,000+ free icons; get SVG (single/bulk), PNG, related icons, webfont classes. No API key.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Add one secure layer between your agents and this server.
