Supericons
Server Details
Supericons lets AI coding agents search, recommend, and retrieve SVG icons from a semantic registry of 20,000+ free icons.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.4/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: get_icon retrieves known icons, search_icons finds icons by concept, list_libraries shows available libraries, preview_icons creates visual previews, and recommend_icons suggests coherent sets. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_icon, list_libraries). The naming is predictable and uniform across the entire set.
With 5 tools, the server is well-scoped for icon management operations: searching, retrieving, previewing, recommending, and listing libraries. The count feels appropriate without being too sparse or excessive.
The tool set covers the full lifecycle for a read-only icon library: discovery (search, list libraries), retrieval (get icon), visualization (preview), and curation (recommend). There are no obvious gaps for the intended purpose.
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. Use "any" unless the caller needs a specific variant. | 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?
Annotations provide no hints, but description implies read-only retrieval. Could explicitly state it has no side effects. Still, return data is well described.
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 purpose, 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 output schema exists and context signals, description adequately covers usage and return without omitting critical details.
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 description does not add extra meaning beyond what schema already provides for 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 clearly states the tool retrieves one exact SVG icon given known ID and library. It distinguishes from sibling search_icons by specifying when to use that instead.
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 search_icons first if the user only described a concept. Provides clear context for when to call this tool.
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 indicate read-only, idempotent, non-destructive behavior. Description adds no additional behavioral context beyond purpose, which is adequate but does not exceed what annotations provide.
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 that are front-loaded with the action and immediately provide usage guidance. 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, existing output schema, and clear annotations, 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, schema coverage is 100%. Description does not need to explain parameters; baseline score of 4 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?
Description clearly states the tool lists free icon libraries from a specific server, distinguishing it from sibling tools that deal with icons (get_icon, search_icons, etc.) 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?
Explicitly says when to use this tool: before filtering by library or when asked which libraries are supported, providing clear context and alternatives.
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
Create a visual preview for icon search results or a fixed list of icon refs. Returns a hosted preview page, direct PNG image URL, ready-made Markdown image snippet, and, when requested, an MCP image contact sheet. Use markdown_image in final answers when the client supports remote Markdown images; otherwise share image_url or preview_url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum icons to include in the preview. Keep this small for image-capable clients. | |
| query | No | Optional search query to preview visually, for example "license plate recognition camera scan car". | |
| style | No | Optional style preference. | any |
| locale | No | Optional locale for multilingual search terms. Supported values: zh-Hans, zh-Hant, ja, ko, es, de, pt, ar, hi, vi, th. | |
| 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, for example ["si:x-ai", "mingcute:scan_2_line"]. | |
| include_image | No | When true, include a PNG contact sheet as MCP image content. 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. |
| image_url | No | Direct PNG URL for clients or Markdown renderers that can show remote images. |
| 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. |
| client_display_note | Yes | Plain-language note for clients that do not render images inline. |
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 value by detailing all return types (hosted preview page, PNG URL, Markdown snippet, MCP image contact sheet), which annotations do not convey. 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?
Two sentences, each earning its place. The first sentence declares purpose and outcomes; the second provides actionable usage guidance. No filler, well 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?
Given no output schema shown (though present), annotations, and full parameter coverage, the description adequately covers when to use the tool and what to do with results. It could mention that the tool is idempotent, but annotations already state that. Slightly missing guidance on when not to use compared to siblings, but still complete enough.
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 does not elaborate on parameter formats or additional constraints beyond the schema. However, it contextualizes the output in relation to parameters, which is helpful but not adding meaning to individual 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 starts with a specific verb 'Create a visual preview' and clearly distinguishes two use cases: icon search results or a fixed list of refs. It also enumerates the return types, making the tool's function unambiguous. Among siblings, it uniquely handles multi-icon previews.
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 provides explicit guidance on how to use the output ('Use markdown_image in final answers... otherwise share image_url or preview_url'). It implies when to invoke this tool (when a visual preview of icons is needed), though it does not explicitly contrast with sibling tools like search_icons or get_icon.
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 named UI slots in a product, app, dashboard, or navigation flow. Use this when the user needs several icons that should work together. Returns one recommendation and optional alternatives for each 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 | Yes | Overall UI task, for example "choose icons for an AI dashboard sidebar" or "select bottom navigation icons for a finance app". | |
| slots | Yes | List of UI slots to fill, for example ["model", "prompt", "dataset", "evaluation"]. | |
| style | No | Optional style preference. Use "outline" for most sidebar and toolbar icon sets unless the user asks otherwise. | any |
| locale | No | Optional locale for multilingual slot labels. Supported values: zh-Hans, zh-Hant, ja, ko, es, de, pt, ar, hi, vi, th. | |
| 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. Use plan for compact icon IDs and reasons, assets to include SVG only for each top recommendation, or full to include SVG and semantic payloads for all returned choices. | plan |
| limit_per_slot | No | Number of choices to return for each slot. Use 1 for a final pick or 2-3 when the user wants alternatives. | |
| include_query_frame | No | Optional public-safe diagnostics for query understanding. Leave false for normal compact responses. |
Output Schema
| Name | Required | Description |
|---|---|---|
| task | Yes | Original UI task. |
| style | No | Style preference used for recommendations. |
| library | No | Library filter used for recommendations, if provided. |
| results | Yes | Recommended icon choices grouped by requested UI slot. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint=false, destructiveHint=false). The description adds beyond annotations by detailing return format: 'public library labels and visual preview URLs where available.' It also clarifies library key 'si means Supericons, not Simple Icons', reducing ambiguity. 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?
The description is three sentences, each adding distinct value: purpose, usage context, and a clarifying note on library keys. It is front-loaded and contains no 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 8 parameters (2 required), high schema coverage, and presence of output schema, the description covers the main use case, output format, and critical library ambiguity. It could mention that output includes SVG or plans, but it's implied via response_mode description. Overall sufficient.
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 baseline is 3. The description adds value by providing usage hints for parameters: e.g., 'Use outline for most sidebar and toolbar icon sets unless the user asks otherwise' for style, and clarifies response_mode options. It also adds the 'si' clarification for library, which is not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Recommend a coherent icon set for named UI slots'. It specifies the verb (Recommend), resource (icon set), and context (UI slots for products, apps, dashboards). This distinguishes it from siblings like search_icons (single icon search) and get_icon (single icon retrieval).
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: 'Use this when the user needs several icons that should work together.' It also describes the output (one recommendation plus alternatives) and hints at library differentiation with the 'si' note. It lacks explicit 'when not to use' but still provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_iconsSearch IconsAInspect
Search 20,000+ curated SVG icons across 11 libraries by meaning, label, visual description, tags, and synonyms. Use this when the user describes an icon concept such as "database", "user profile", "chill", "security", "AI model", or "OpenAI Codex logo". Returns matching icons with SVG code, public semantic guidance, explicit library labels, and browser preview URLs. Library key si means Supericons, not Simple Icons.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of icons to return. Use 5-10 for browsing and 1-3 for quick agent choices. | |
| 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. Use "any" unless the user asks for outline or solid icons. | any |
| locale | No | Optional locale for multilingual search terms. Supported values: zh-Hans, zh-Hant, ja, ko, es, de, pt, ar, hi, vi, th. | |
| 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. | |
| include_query_frame | No | Optional public-safe diagnostics for query understanding. Leave false for normal compact responses. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching icons with SVG code and semantic guidance. |
| preview_url | No | Browser URL for visual inspection of this search result set. |
| query_frame | No | Optional public-safe query understanding diagnostics. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns SVG code, semantic guidance, library labels, and preview URLs. Annotations do not contradict (readOnlyHint is false but description implies read-only search). No side effects are mentioned, but for a search tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and usage, includes examples and a clarification. No superfluous 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 the complexity (6 parameters, output schema), the description covers purpose, usage, and a key library note. Could mention sorting/relevance, but is largely complete for a search 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% with detailed descriptions. The description adds value by clarifying the 'si' library key and giving query examples, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 20,000+ SVG icons across 11 libraries by meaning, label, etc., and gives concrete examples. It distinguishes from siblings like get_icon and list_libraries by focusing on concept-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when the user describes an icon concept' and provides examples. It lacks direct comparisons to siblings, but the context is clear enough for an agent to choose this tool for concept searches.
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!