Supericons
Server Details
Semantic SVG icon search and recommendations for AI coding agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- curlymolelabs/supericons
- GitHub Stars
- 0
- Server Listing
- supericons
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: search_icons for conceptual search, get_icon for exact retrieval, list_libraries for library enumeration, preview_icons for visual output, and recommend_icons for set recommendations. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., search_icons, get_icon), using snake_case throughout. The pattern is predictable and clear.
With 5 tools, the server is well-scoped for its purpose of icon search, retrieval, preview, and recommendation. Neither too few nor too many; each tool earns its place.
The tool surface covers the full expected workflow: discovering libraries, searching by concept, retrieving exact icons, previewing results, and getting recommendations. There are no obvious gaps for a read-only icon service.
Available Tools
5 toolsget_iconGet IconAInspect
Retrieve one exact SVG icon when the icon ID and library are already known. 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| icon | No | Exact matching icon when found. |
| error | No | Recoverable error message when no exact icon is found. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only retrieval operation with the word 'Retrieve', but annotations set readOnlyHint to false, indicating potential side effects. No additional behavioral traits (e.g., side effects, mutation, or rate limits) are disclosed, and the contradiction reduces 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?
The description consists of two front-loaded sentences with no wasted words. Every sentence is informative: the first states the primary purpose and prerequisite, the second provides an alternative and lists return values.
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 the presence of an output schema and three parameters, the description covers the key aspects: what the tool does, when to use it, and what it returns. It mentions a sibling tool for context. It could mention other siblings or error conditions, but it is largely 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema, merely echoing that id and library are needed. It does not provide any new context about the parameters.
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 the specific verb 'Retrieve' and the resource 'exact SVG icon', clearly indicating the tool's function. It distinguishes from the sibling tool search_icons by stating the prerequisite that the icon ID and library are already known.
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 explicitly states when to use this tool ('when the icon ID and library are already known') and when to use the alternative ('Use search_icons first if the user only described a concept'). This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_librariesList LibrariesARead-onlyIdempotentInspect
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 | |||
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no extra behavioral context, but is consistent 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?
Two sentences, front-loaded with main purpose. Every sentence adds value with no wasted 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?
Given zero parameters, rich annotations, and an output schema, the description fully covers the tool's purpose and usage context.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'free icon libraries', distinguishing it from sibling tools that deal with icons rather than 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?
Provides explicit guidance: 'Use this before filtering by library or when a user asks which icon libraries are supported.' This tells when to invoke it, though it doesn't explicitly mention 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.
preview_iconsPreview IconsARead-onlyIdempotentInspect
Refine an icon result set or preview known icon refs. Use search_icons first for normal icon requests. Long icon lists are accepted and safely truncated to 12. Returns a hosted preview page, direct PNG image URL, ready-made Markdown image snippet, 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. Larger lists are safely truncated with a warning. | |
| include_image | No | When true, include a PNG contact sheet as MCP image content. Boolean strings are accepted. A preview_url is always returned. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return types (preview page, PNG URL, Markdown snippet, MCP image) and conditions (when requested), adding context beyond annotations. No contradictions with readOnlyHint or idempotentHint.
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: first covers purpose and output, second delivers actionable usage guidance. No extraneous text.
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?
Covers main purpose, output types, and output usage. With annotations covering safety and output schema likely covering structure, it feels complete; minor gap on error handling.
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% with parameter descriptions already present; description adds minimal additional semantics beyond summarizing that it supports query or icon_refs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a visual preview for icon search results or a fixed icon list, distinguishing it from sibling tools like get_icon or search_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?
Provides practical guidance on when to use markdown_image vs image_url or preview_url, but does not explicitly contrast with alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_iconsRecommend IconsAInspect
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. Larger lists return a structured split instruction. | |
| 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. |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns needs_clarification when context insufficient, provides preview URLs, clarifies library key 'si' meaning. Annotations do not contradict; description adds value beyond 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?
Single concise paragraph with no filler. Front-loaded with purpose, covers ambiguity handling, output format, and a key disambiguation. Every sentence contributes.
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?
Covers main behavioral aspects and output expectations. Output schema exists, so return values not needed. Could mention error handling or rate limits, but not critical for effective use.
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% with parameter descriptions. Description adds extra context like how task narrows ambiguity, response_mode options, and library key nuance. Exceeds baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it recommends a coherent icon set for named UI slots, differentiating from siblings like get_icon (single icon) or search_icons (search). Uses specific verb 'recommend' and describes scope with examples.
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?
Explains when to use (for coherent sets) and how ambiguity is handled (returns needs_clarification). Does not explicitly list alternatives but context implies differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_iconsSearch IconsAInspect
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. 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. 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 | 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. | strict |
| include_query_frame | No | Optional public-safe diagnostics for query understanding. Boolean strings are accepted. Leave false for normal compact responses. |
Output Schema
| 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. |
| markdown_image | No | Ready-made Markdown image when usable icons exist. |
| search_runtime | No | Search execution path used for this request. |
| requested_library | Yes | Preferred or required library, when supplied. |
| retry_after_seconds | No | Seconds to wait before retrying a rate-limited search. |
| suggested_response_markdown | Yes | Compact answer that accurately reflects this response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no hints). Description adds transparency by detailing return values (SVG code, semantic guidance, library labels, preview URLs) and clarifying the 'si' library key. No contradictions.
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?
Concise (3-4 sentences), front-loaded with purpose, then usage, then return info. No unnecessary text.
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 7 parameters with 100% schema coverage and output schema present, description covers purpose, usage, return fields, and a key clarification. Complete for agent decision-making.
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%, baseline 3. Description adds value by clarifying the 'si' library key meaning and providing example queries. Schema descriptions are already detailed, but description enhances context.
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 it searches 20,000+ curated SVG icons across 11 libraries by meaning, label, visual description, tags, and synonyms, with explicit examples. Distinguishes 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?
Provides clear usage guidance with examples like 'database', 'user profile', and explicit use case: 'when the user describes an icon concept'. Does not explicitly state when not to use, but sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.