Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
Scored across 5 tools
find_brand_logo and search_icons overlap: both claim to find logos, with search_icons explicitly saying it searches 'icons and brand logos' while find_brand_logo says 'use this when the user asks to find a logo'. The rest (get_icon, list_collections, send_feedback) are clearly distinct, but the two search tools require careful reading to choose correctly.
All 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 retrieval server: search, brand lookup, fetch SVG, list collections, and feedback each earn their place. Nothing bloated or missing at the structural level.
Core search-to-SVG flow is covered, but list_collections returns prefixes and counts with no tool to enumerate icons within a collection, creating a dead end for browsing. There is also no metadata/style filter search or pagination for large result sets.
Finds a company, product, or technology logo by name or domain. Use this when the user asks to find a logo. Returns matching icons in "prefix:name" format with their style (color, mono, wordmark) and, when available, a brand hex color. Get the SVG of a result with get_icon. Where supported, it also displays the color and an icon grid.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | Yes | Company, product, or technology name, or a domain such as "example.com" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive, so the description's real contribution is the return shape ('prefix:name', style variants, optional brand hex color) and the note that it may render a color and icon grid where supported. That is useful context beyond annotations, though no-match or empty-result behavior is left unstated.
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 purpose, then usage, then return format and the handoff to get_icon — a sensible order. The trailing sentence about displaying a color and icon grid is slightly incidental but still short.
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 correctly spends its words explaining the return value format and the get_icon follow-up, which is what an agent needs. Only edge cases (no results, ambiguous brand names) are absent.
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 single 'brand' parameter is fully documented there. The description's 'by name or domain' merely restates the schema, adding no syntax or format detail beyond it.
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 ('Finds a company, product, or technology logo') and scopes it to brand/domain input, which separates it from search_icons and list_collections. An agent can identify the tool's remit without opening the 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?
Explicitly says 'Use this when the user asks to find a logo' and then routes the follow-up step to get_icon for the SVG. It gives clear positive guidance but never states exclusions or when to prefer search_icons instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves SVG markup for one icon identified by "prefix:name". Use this when the user requests the SVG for a selected icon. Returns the SVG markup or, for SVGs over 32 KB, its size and a URL.
| 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 readOnly/non-destructive/closed-world, so safety is covered. The description adds the non-obvious behavioral detail that oversized SVGs (>32 KB) return size and a URL instead of markup, which an agent could not infer from any structured field. It stops short of describing error behavior for unknown icons.
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. The identifier format and the primary use case are front-loaded before the return-value caveat.
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 read-only tool with no output schema, the description covers input format, the trigger condition, and the exact return shape including the large-file exception. Nothing an agent needs to call and interpret it 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 schema already documents "prefix:name" with the mdi:arrow-right example. The description restates the same format without adding syntax, validation, or resolution rules (e.g. case sensitivity, collection prefix requirements). 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 (retrieves SVG markup for one icon) plus the exact identifier format "prefix:name". An agent can distinguish this from search_icons (discovery) and find_brand_logo (brand-specific) 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?
Explicitly says to use it "when the user requests the SVG for a selected icon", which cleanly separates lookup-by-known-name from search. It does not name the alternatives (search_icons, find_brand_logo) or state what to do when the name is unknown, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists hosted icon sets by category, including each set's prefix, name, and icon count. Use this once per conversation when the user asks about available icon collections; reuse the returned list. 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 declare readOnly/destructive/openWorld behavior, so the bar is lower, and the description adds genuinely non-structured facts: caching guidance and 'does not count toward usage limits.' That quota/cost disclosure is the kind of context 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?
Two sentences: the first defines the output, the second defines when to call it and how to cache. No filler, and the 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?
With no parameters and no output schema, the description carries the return-value burden and mostly discharges it by naming the fields returned. It could go slightly further (e.g., whether results are paginated or how many sets are returned) but is adequate to call 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?
Zero parameters, so baseline is 4. The description additionally describes the shape of the return payload, which is the only semantics available for a no-input tool.
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 ('Lists hosted icon sets by category') and enumerates the returned fields (prefix, name, icon count), which lets an agent distinguish it from search_icons/get_icon by subject matter. It does not explicitly name a sibling or state the contrast, keeping it below a 5.
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 clear triggering context ('when the user asks about available icon collections') plus an operational instruction to reuse the returned list once per conversation. It lacks explicit when-not-to-use or named alternatives, so it is a strong 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches SVG icons and brand logos by keyword. Use this when the user asks to find an icon or logo. Returns matching icon identifiers in "prefix:name" format and does not return SVG content. To save many icons as files, download https://i.allsvgicons.com//.svg directly instead of calling get_icon for each one. Where supported, it also displays an icon grid.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return, up to 20 | |
| query | Yes | Keyword or phrase describing the requested icon | |
| picker | No | Whether to show the icon grid when the client supports it (default true). Pass false for searches the user does not need to see | |
| prefix | No | Limit the search to one icon set prefix, such as "mdi" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/non-destructive safety, and the description adds substantive context: return format ('prefix:name'), explicit exclusion of SVG content, the direct download URL pattern, and the conditional icon-grid display. This is meaningful disclosure beyond the structured fields.
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-loads purpose and trigger, then adds return format and the download tip; each sentence earns its place. Slightly dense in the third sentence but no real waste.
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 usefully explains the return value and that no SVG payload comes back, and covers the bulk-download workflow. The remaining gap is not clarifying the overlap with find_brand_logo for logo-specific searches.
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 all four parameters are already documented, including the picker default and limit cap. The description adds only implicit color (grid display relates to picker), 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 and resource ('Searches SVG icons and brand logos by keyword') and clarifies output form ('prefix:name' identifiers, no SVG content), which distinguishes it from get_icon (which presumably returns SVG) and from find_brand_logo's narrower scope.
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 a clear trigger ('when the user asks to find an icon or logo') and an explicit alternative path for bulk downloads instead of looping get_icon. However, it doesn't clarify when to prefer this over the sibling find_brand_logo, despite both covering logos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a user-confirmed feedback message about this icon server to its maintainer. Use this only when the user asks to send feedback and confirms the message. Do not include personal data, code, or secrets. Returns a sending confirmation and, if a reply is requested, a prepared email link. 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?
Annotations only cover readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes well beyond them by disclosing the return behavior (sending confirmation, plus a prepared email link when a reply is requested), a concrete rate limit ('3 messages per day'), and content privacy 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?
Four short sentences, each doing distinct work: purpose, usage gate, content prohibition, return behavior and rate limit. Front-loaded with the purpose, zero 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 one-parameter mutation with no output schema, the description supplies everything an agent needs: when it may be called, what it returns, and the rate ceiling. Nothing material is left to inference.
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 'message' parameter already documents its 1000-character cap, so the schema carries the load. The description adds only indirect meaning via the 'no personal data, code, or secrets' content rule, not parameter-level detail.
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 ('Sends a user-confirmed feedback message about this icon server to its maintainer'), plus the scope of what is sent. This is unmistakably different from every sibling (find_brand_logo, get_icon, list_collections, search_icons), none of which are feedback 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?
Gives an explicit hard gate: 'Use this only when the user asks to send feedback and confirms the message.' It also states what must not be included (personal data, code, secrets), which is actionable pre-invocation guidance. No sibling could be confused with this tool, so the absence of named alternatives is not a gap.
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_logo1 field changedInput schema / properties / brand / descriptionPrevious value: -"Brand name or domain, e.g. \"GitHub\" or \"github.com\""New value: +"Company, product, or technology name, or a domain such as \"example.com\""search_icons4 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results, capped at 20"New value: +"Number of results to return, up to 20"Input schema / properties / picker / descriptionPrevious value: -"Show the icon grid to the user (default true). Pass false for searches the user does not need to see"New value: +"Whether to show the icon grid when the client supports it (default true). Pass false for searches the user does not need to see"Input schema / properties / prefix / descriptionPrevious value: -"Scope the search to a single icon set prefix, e.g. \"mdi\""New value: +"Limit the search to one icon set prefix, such as \"mdi\""Input schema / properties / query / descriptionPrevious value: -"Search keyword"New value: +"Keyword or phrase describing the requested icon"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.
