Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Scored across 5 tools
search_icons is explicitly the main discovery tool, recommend_icons targets multi-slot UI sets, preview_icons refines/previews known refs, and get_icon fetches an exact SVG, which keeps the core purposes separable. However, search_icons, recommend_icons, and preview_icons all return icon result sets with previews, so an agent could reasonably hesitate between search and recommend for a simple request.
All five tools follow a strict verb_noun snake_case pattern: search_icons, recommend_icons, preview_icons, get_icon, list_libraries. No mixed conventions or vague verbs.
Five tools map cleanly onto the icon workflow (list libraries, search, recommend a set, preview, fetch SVG) with no redundant entries. The count is well within a comfortable scope and each tool earns its place.
Discovery, recommendation, preview, and exact SVG retrieval are all covered, plus library enumeration, so the lifecycle is essentially complete. The main gap is bulk SVG retrieval—get_icon fetches one icon at a time, so assembling many SVGs requires repeated calls.
Retrieve one exact SVG icon using an exact ref returned by search_icons, recommend_icons, or preview_icons. Do not guess icon IDs. Use search_icons first if the user only described a concept. Returns SVG code, explicit public library labels, visual preview URL, and public semantic guidance for the exact icon.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact icon ID without the library prefix, for example "database", "user-circle", "brain-circuit", or "arrow-down". | |
| style | No | Optional style preference. Material Symbols supports outline and solid. Other hosted libraries report their verified styles in list_libraries. | any |
| library | Yes | Required library key for the exact icon. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute. |
| Name | Required | Description |
|---|---|---|
| code | No | Stable error code when the exact icon is unavailable. |
| hint | No | Plain-language explanation of how to recover. |
| icon | No | Exact matching icon when found. |
| error | No | Recoverable error message when no exact icon is found. |
| next_step | No | Recommended next tool action. |
| retryable | No | Whether repeating the same exact lookup may succeed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint to false, while the description describes 'Retrieve', implying a read-only operation. This is a direct annotation contradiction. No behavioral traits beyond the return value are disclosed, but the contradiction forces a score of 1.
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 three sentences, front-loaded with the primary purpose. Each sentence earns its place: the main action, a usage warning, and the return value. No wasted or redundant 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?
The description covers purpose, usage constraints (don't guess, use search_icons for concepts), and return value contents (SVG code, labels, preview URL, semantic guidance). An output schema exists, but the description adds valuable context without being bloated. Complete for a retrieval tool.
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 provides 100% parameter descriptions, establishing a baseline of 3. The description adds context that the id must be an exact ref from specific tools, but this is more usage guidance than parameter semantics. No additional syntax or format details are provided 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?
Description clearly states 'Retrieve one exact SVG icon using an exact ref' with a specific verb and resource. It distinguishes from sibling tools by emphasizing 'exact' and requiring a ref from search_icons, recommend_icons, or preview_icons, contrasting with search and preview functions.
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?
Description explicitly instructs users to not guess icon IDs and to use search_icons first when the user only described a concept. This provides clear when-to-use guidance and an alternative tool recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the free icon libraries available through the hosted Supericons MCP server. Use this before filtering by library or when a user asks which icon libraries are supported.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| libraries | Yes | Free icon libraries available through this hosted MCP server. |
| publicRecordCount | Yes | Number of public semantic icon records searchable through the hosted MCP server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'free' scope and hosted-server context, but discloses no additional behaviors like pagination or rate limits. This is sufficient for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the purpose clearly, the second gives a usage tip. No filler or redundant 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?
Given zero parameters, rich annotations, and the presence of an output schema, the description fully covers what an agent needs to select and 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?
There are zero parameters, so the baseline is 4. The description adds relevant context about the list's content ('free icon libraries') without needing to describe any parameter syntax.
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 'list' with a clear resource 'free icon libraries' and context ('hosted Supericons MCP server'). It distinguishes from sibling tools that operate on individual icons, making the tool's purpose 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?
It explicitly advises use before filtering by library and when users ask about supported libraries. This provides clear context, though it does not name alternative tools directly or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refine an icon result set or preview known icon refs returned by another Supericons tool. Use search_icons first for normal icon requests. Icon lists up to 100 refs are accepted and safely truncated to 12. Returns ready-to-use Markdown, a hosted preview fallback, a direct PNG image URL, and, when requested, an MCP image contact sheet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Requested inline icon count. Values outside 1 to 12 are safely clamped with a warning. Numeric strings are accepted. | |
| query | No | Optional search query to preview visually, for example "license plate recognition camera scan car". | |
| style | No | Optional style preference. Unsupported values are ignored with a warning. | any |
| locale | No | Optional locale for multilingual search terms. Supported values: zh-Hans, zh-Hant, ja, ko, es, de, pt, ar, hi, vi, th. Unsupported values are ignored with a warning. | |
| library | No | Optional library key. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute. | |
| icon_refs | No | Optional fixed icon refs in library:id format. Arrays, a single ref, and comma-separated refs are accepted. Up to 100 are accepted, 24 appear on the browser preview, and 12 are rendered inline. Send at most 100; very large arrays are refused. | |
| include_image | No | When true, include a PNG contact sheet as MCP image content. Boolean strings are accepted. A preview_url is always returned. |
| Name | Required | Description |
|---|---|---|
| error | No | Recoverable error message when preview inputs are missing or invalid. |
| query | No | Search query used for the visual preview, if any. |
| results | Yes | Icons included in the visual preview. |
| warnings | No | Unsupported optional inputs that were safely ignored. |
| image_url | No | Direct PNG URL for clients or Markdown renderers that can show remote images. |
| next_step | Yes | Useful next action for the caller. |
| preview_url | Yes | Browser URL for visual inspection. |
| image_included | Yes | Whether this response includes MCP image content. |
| markdown_image | No | Ready-made Markdown image snippet for final answers in clients that render remote Markdown images. |
| rendered_count | Yes | Number of icons rendered in the inline preview. |
| truncated_from | No | Original icon ref count when the input was truncated. |
| client_display_note | Yes | Plain-language note for clients that do not render images inline. |
| browser_preview_count | Yes | Number of accepted icon refs available at preview_url. |
| suggested_response_markdown | No | Ready-to-use answer with the image, refs, and browser fallback link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, it discloses truncation behavior (100 accepted, 12 rendered inline), refusal of very large arrays, and the full output surface: Markdown, hosted preview fallback, direct PNG URL, and optional MCP image contact sheet. These are exactly the traits an agent needs before calling.
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 tight sentences, front-loaded with purpose and routing before behavioral and return details. Slight duplication of the schema's truncation rules costs it a point, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description needn't explain return values yet does, and it covers annotations, truncation, and the sibling alternative. The one real gap is that it never says whether query and icon_refs can be combined or are mutually exclusive, which an agent must know for this seven-parameter tool.
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 every parameter's meaning, defaults, and clamping rules are already documented structurally. The description restates the 100-to-12 truncation rather than adding new semantics, and leaves the interaction between query and icon_refs unexplained. Baseline 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?
States two concrete modes: refining an existing icon result set, and previewing known icon refs produced by another Supericons tool. It explicitly names the sibling to use for the normal case, so an agent can choose between preview_icons and search_icons without opening either 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?
Gives an explicit routing rule ('Use search_icons first for normal icon requests') plus the condition that selects this tool (refining a result set or previewing known refs). No exclusions are needed because the alternative path is fully named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a coherent icon set for up to 20 named UI slots in one call. Uses task context to narrow ambiguous meanings. When context is insufficient, returns needs_clarification with labeled interpretation options instead of guessing. Invalid inputs and service failures return a plain-language reason and a next step instead of a bare protocol error. Returns one recommendation and optional alternatives for each resolved slot, with explicit public library labels and visual preview URLs where available. Library key si means Supericons, not Simple Icons.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | Overall UI task, for example "choose icons for an AI dashboard sidebar" or "select bottom navigation icons for a finance app". Missing task text returns a structured recovery message. | |
| slots | No | List of 1 to 20 UI slots to fill, for example ["model", "prompt", "dataset", "evaluation"]. A single string is accepted as one slot. Lists of up to a few hundred slots return a structured split instruction; send at most 20 per call. | |
| style | No | Optional style preference. Unsupported values are ignored with a warning. | any |
| locale | No | Optional locale for multilingual slot labels. Unsupported values are ignored with a warning. | |
| library | No | Optional library key when the user wants a consistent icon family. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute. | |
| response_mode | No | Response size mode: plan, assets, or full. Unsupported values use plan with a warning. | plan |
| limit_per_slot | No | Number of choices per slot. Values outside 1 to 5 are clamped with a warning. Numeric strings are accepted. | |
| include_query_frame | No | Optional public-safe diagnostics for query understanding. Boolean strings are accepted. Leave false for normal compact responses. |
| Name | Required | Description |
|---|---|---|
| code | No | Stable error code for programmatic recovery. |
| hint | No | Plain-language recovery instruction. |
| task | Yes | Original UI task. |
| error | No | Plain-language reason the recommendation did not complete. |
| style | No | Style preference used for recommendations. |
| status | No | HTTP status from a hosted dependency failure. |
| details | No | Structured limits or failure details. |
| library | No | Library filter used for recommendations, if provided. |
| results | Yes | Recommended icon choices grouped by requested UI slot. |
| warnings | No | Unsupported optional inputs that were safely ignored or clamped. |
| next_step | No | Useful next action for the caller. |
| retryable | No | Whether a corrected or later request may succeed. |
| slot_count | Yes | Number of UI slots requested. |
| preview_url | No | Browser URL for visual inspection of the recommended icon set. |
| query_frame | No | Optional public-safe query understanding diagnostics for the task. |
| response_mode | Yes | Response size mode used for this recommendation. |
| search_runtime | No | Search execution path used for this recommendation. |
| all_slots_resolved | Yes | Whether every requested slot received a recommendation without clarification. |
| clarification_slots | Yes | Slots that need the caller to choose an interpretation. |
| needs_clarification | Yes | Whether one or more ambiguous slots require more context. |
| retry_after_seconds | No | Seconds to wait before retrying a rate-limited recommendation. |
| fallback_recommended | Yes | Whether the caller should consider direct search or clarification. |
| low_confidence_slots | Yes | Slots whose result is missing or has low confidence. |
| suggested_response_markdown | No | Plain-language explanation suitable for the agent response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: it discloses task-context narrowing, needs_clarification fallback with labeled options, plain-language error handling with next steps, per-slot recommendations plus alternatives, and preview URLs. These details help an agent understand how the tool behaves in ambiguous and failure cases.
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, then moves through ambiguity handling, error behavior, return shape, and a key naming clarification. Every sentence contributes useful information with no 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 an 8-parameter recommendation tool with an output schema, the description covers the crucial behavioral edges: slot limits, clarification fallback, error recovery, return structure, and library-key ambiguity. The output schema can carry detailed return fields, so no major completeness 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 meaningful semantics not fully captured elsewhere, especially that 'si' means Supericons rather than Simple Icons and that invalid style, locale, response_mode, and limit values are handled with warnings or clamping. It does not explain the plan/assets/full modes in 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?
The description uses a specific verb and resource: 'Recommend a coherent icon set' for named UI slots, with a clear scope of up to 20 slots per call. It does not explicitly differentiate itself from sibling tools such as search_icons or preview_icons, so it falls short of 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?
The description implies the tool's usage through 'for up to 20 named UI slots in one call' and explains clarification behavior when context is insufficient. However, it never states when to use this tool instead of alternatives like search_icons, get_icon, or preview_icons, 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.
Use this as the main icon tool. Search 20,000+ curated SVG icons across 11 libraries by meaning, label, visual description, tags, and synonyms. When matches exist, the response includes a paste-ready suggested answer, a direct preview image, and Markdown that can show the image in the final reply. When no supported match exists, it returns an honest structured no-result with a next step and no fabricated icon. If you choose a library yourself, use prefer. Use strict only when the user explicitly requires that library. Library key si means Supericons, not Simple Icons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of icons from 1 to 50. Numeric strings are accepted. | |
| query | Yes | Icon concept or search phrase, for example "database", "user profile", "chill", "trash", "upload cloud", "AI model", or "beautiful". | |
| style | No | Optional style preference. Unsupported values are ignored with a warning. | any |
| locale | No | Optional locale for multilingual search terms. Supported values: zh-Hans, zh-Hant, ja, ko, es, de, pt, ar, hi, vi, th. Unsupported values are ignored with a warning. | |
| library | No | Optional library key only when the user named a library. Omit it to search all libraries. Do not use all as a library key. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute. | |
| library_mode | No | Optional library behavior. Omit a self-chosen library and search all, or use prefer with that library. Use strict only when the user explicitly requires the named library. All searches every eligible library. Unsupported or incomplete combinations are safely normalized with a warning. | |
| include_query_frame | No | Optional public-safe diagnostics for query understanding. Boolean strings are accepted. Leave false for normal compact responses. |
| Name | Required | Description |
|---|---|---|
| code | No | Stable code for a structured no-result. |
| hint | No | Plain-language recovery hint for a structured no-result. |
| error | No | Plain-language error for a structured no-result. |
| status | No | HTTP status from an upstream search failure. |
| details | No | Structured rate-limit or upstream failure details. |
| results | Yes | Matching icons with SVG code and semantic guidance. |
| warnings | No | Unsupported optional inputs that were safely ignored. |
| image_url | No | Direct PNG URL when usable icons exist. |
| next_step | Yes | Useful next action for the caller. |
| retryable | No | Whether changing the query or filters may produce a result. |
| limit_scope | No | Allowance scope reported by a rate limit. |
| preview_url | No | Browser URL for visual inspection of this search result set. |
| query_frame | No | Optional public-safe query understanding diagnostics. |
| library_mode | Yes | Library behavior used for this search. |
| outcome_type | No | Whether this response contains results, an honest no-match, or a tool failure. |
| result_count | No | Number of verified icons returned by this search. |
| markdown_image | No | Ready-made Markdown image when usable icons exist. |
| search_runtime | No | Search execution path used for this request. |
| top_result_ref | No | Top ordered icon ref when results exist. |
| requested_library | Yes | Preferred or required library, when supplied. |
| retry_after_seconds | No | Seconds to wait before retrying a rate-limited search. |
| result_interpretation | No | Plain-language guidance for interpreting this result count and outcome. |
| suggested_response_markdown | Yes | Compact answer that accurately reflects this response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description carries the full behavioral burden. It thoroughly discloses match behavior (paste-ready answer, direct preview image, Markdown), no-match behavior (honest structured no-result with next step, no fabricated icon), and library-mode semantics. The si/Supericons disambiguation also prevents a likely misuse. This exceeds the minimum expected 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?
Every sentence earns its place: the primary-role statement, search capability, match/no-match response behavior, library-mode guidance, and the si/Supericons warning. It is front-loaded with the most important usage directive and remains compact for a tool with 7 parameters.
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 description is complete for correct invocation: it covers query style, result behavior, failure handling, library selection, and a known naming trap. The output schema exists, so detailed return-value documentation is already available to the agent. No critical operational context 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%, so the baseline is 3. The description adds meaningful guidance beyond the schema by explaining the prefer/strict library_mode behavior, the condition for strict usage, and the si key ambiguity. This additional context raises the score.
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 opens with 'Use this as the main icon tool' and names a specific action and resource: searching 20,000+ curated SVG icons across 11 libraries by meaning, labels, visual description, tags, and synonyms. It clearly establishes this as the primary search tool and distinguishes it from siblings like get_icon and list_libraries.
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 guidance on when to use this tool ('main icon tool') and how to choose library modes: 'If you choose a library yourself, use prefer' and 'Use strict only when the user explicitly requires that library.' It does not explicitly compare against sibling tools, but the primary-tool framing and mode rules provide clear usable context.
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.
preview_icons1 field changedInput schema / properties / icon_refs / descriptionPrevious value: -"Optional fixed icon refs in library:id format. Arrays, a single ref, and comma-separated refs are accepted. Up to 100 are accepted, 24 appear on the browser preview, and 12 are rendered inline. Larger lists are safely truncated with a warning."New value: +"Optional fixed icon refs in library:id format. Arrays, a single ref, and comma-separated refs are accepted. Up to 100 are accepted, 24 appear on the browser preview, and 12 are rendered inline. Send at most 100; very large arrays are refused."recommend_icons1 field changedInput schema / properties / slots / descriptionPrevious value: -"List of 1 to 20 UI slots to fill, for example [\"model\", \"prompt\", \"dataset\", \"evaluation\"]. A single string is accepted as one slot. Larger lists return a structured split instruction."New value: +"List of 1 to 20 UI slots to fill, for example [\"model\", \"prompt\", \"dataset\", \"evaluation\"]. A single string is accepted as one slot. Lists of up to a few hundred slots return a structured split instruction; send at most 20 per call."search_icons5 fields changedOutput schema / properties / search_runtime / properties / hosted_result_countAdded value: +{
+ "type": "number"
+}Output schema / properties / search_runtime / properties / local_attempt_countAdded value: +{
+ "type": "number"
+}Output schema / properties / search_runtime / properties / local_result_countAdded value: +{
+ "type": "number"
+}Output schema / properties / search_runtime / properties / local_retry_recoveredAdded value: +{
+ "type": "boolean"
+}Output schema / properties / search_runtime / properties / local_retry_usedAdded value: +{
+ "type": "boolean"
+}search_icons4 fields changedOutput schema / properties / search_runtime / properties / degradedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / search_runtime / properties / hosted_circuit_stateAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "closed",
+ "open",
+ "half_open_ready"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / search_runtime / properties / hosted_failure_codeAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / search_runtime / properties / hosted_failure_statusAdded value: +{
+ "type": [
+ "number",
+ "null"
+ ]
+}search_icons1 field changedInput schema / properties / library_mode / descriptionPrevious value: -"Optional library behavior. Omit it to use all when no library is named and strict when a library is named. Prefer requires a named library. All searches every eligible library. Unsupported or incomplete combinations are safely normalized with a warning."New value: +"Optional library behavior. Omit a self-chosen library and search all, or use prefer with that library. Use strict only when the user explicitly requires the named library. All searches every eligible library. Unsupported or incomplete combinations are safely normalized with a warning."get_icon4 fields changedOutput schema / properties / codeAdded value: +{
+ "description": "Stable error code when the exact icon is unavailable.",
+ "type": "string"
+}Output schema / properties / hintAdded value: +{
+ "description": "Plain-language explanation of how to recover.",
+ "type": "string"
+}Output schema / properties / next_stepAdded value: +{
+ "description": "Recommended next tool action.",
+ "type": "string"
+}Output schema / properties / retryableAdded value: +{
+ "description": "Whether repeating the same exact lookup may succeed.",
+ "type": "boolean"
+}preview_icons1 field changedOutput schema / properties / suggested_response_markdownAdded value: +{
+ "description": "Ready-to-use answer with the image, refs, and browser fallback link.",
+ "type": "string"
+}search_icons7 fields changedInput schema / properties / library / descriptionPrevious value: -"Optional library key. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute."New value: +"Optional library key only when the user named a library. Omit it to search all libraries. Do not use all as a library key. Supported values include si (Supericons AI and developer tool logos), lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons (Simple Icons brand logos), and mingcute."Input schema / properties / library_mode / defaultRemoved value: -"strict"Input schema / properties / library_mode / descriptionPrevious value: -"Library behavior. Strict stays inside the requested library, prefer puts it first and includes labeled alternatives, and all searches every eligible library. Unsupported values are ignored with a warning."New value: +"Optional library behavior. Omit it to use all when no library is named and strict when a library is named. Prefer requires a named library. All searches every eligible library. Unsupported or incomplete combinations are safely normalized with a warning."Output schema / properties / outcome_typeAdded value: +{
+ "description": "Whether this response contains results, an honest no-match, or a tool failure.",
+ "enum": [
+ "results",
+ "no_match",
+ "tool_error"
+ ],
+ "type": "string"
+}Output schema / properties / result_countAdded value: +{
+ "description": "Number of verified icons returned by this search.",
+ "type": "number"
+}Output schema / properties / result_interpretationAdded value: +{
+ "description": "Plain-language guidance for interpreting this result count and outcome.",
+ "type": "string"
+}Output schema / properties / top_result_refAdded value: +{
+ "description": "Top ordered icon ref when results exist.",
+ "type": [
+ "string",
+ "null"
+ ]
+}search_icons2 fields changedOutput schema / properties / search_runtime / properties / local_fusion_usedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / search_runtime / properties / mode / enumPrevious value: -[
- "local_first",
- "local_fallback",
- "hosted_fallback",
- "hosted"
-]New value: +[
+ "local_first",
+ "local_fallback",
+ "hosted_fallback",
+ "hosted",
+ "hosted_fused"
+]Icons 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.
Search 324k icons or generate new ones in the Lucide grammar - grammar-locked lint+critique+repair
Add one secure layer between your agents and this server.
