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 4 of 4 tools scored.
Each tool has a distinct purpose: listing libraries, searching icons, retrieving a specific icon, and recommending icon sets. No two tools overlap in functionality.
All tool names follow a consistent verb_noun pattern (get_icon, list_libraries, recommend_icons, search_icons) using lowercase and underscores.
Four tools cover the essential operations for icon management (discovery, retrieval, and recommendation) without being excessive or insufficient.
The tool surface covers library listing, semantic search, exact retrieval, and intelligent recommendation, leaving no obvious gaps for the domain of icon access.
Available Tools
4 toolsget_iconGet IconARead-onlyIdempotentInspect
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 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 lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons, 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 already declare readOnlyHint, idempotentHint, destructiveHint. Description adds return type (SVG code and semantic guidance) beyond 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 efficiently convey purpose, use case, and return. Could be slightly sharper but not verbose.
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 full schema coverage, annotations, and explicit return description, the tool is fully understood without gaps.
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 3. Description adds clarifications like 'without library prefix' for id and default style behavior.
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 'retrieve one exact SVG icon' when ID and library known. Distinct from sibling 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?
Explicitly directs to use search_icons when only a concept is known, providing clear when-to-use guidance.
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 and idempotentHint=true, so the agent knows it's a safe read operation. The description adds that libraries are 'free' and 'hosted', providing extra context beyond 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?
The description is two sentences, front-loaded with the main action. Every sentence adds value: one for purpose, one for usage context. 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 no parameters and an output schema present, the description sufficiently explains what the tool does and when to use it. It covers the essentials for a simple list 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?
There are no parameters, so the description has no burden to explain parameters. Baseline is 4, and the description adds no parameter info, which 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?
The description clearly states the tool lists free icon libraries from the hosted Supericons MCP server, using a specific verb and resource. It distinguishes from sibling tools like get_icon (individual icon) and search_icons (icons), as libraries are a separate concept.
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 advises to use this tool before filtering by library or when asked about supported libraries. It implies context but does not explicitly name alternative tools, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_iconsRecommend IconsARead-onlyIdempotentInspect
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.
| 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 lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons, 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. |
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. |
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, so the safety profile is clear. The description adds that it returns recommendations and alternatives, which is consistent but not significantly beyond the 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?
The description is two sentences, front-loaded with purpose and usage. Every sentence adds value without redundancy or fluff.
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 tool's complexity (7 parameters, 3 enums) and the presence of an output schema, the description covers the core intent well. It could mention response mode implications or slot constraints, but overall it is 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 description coverage is 100%, so all parameters are already documented. The description adds general context about coherence but does not provide additional meaning beyond what the schema already offers.
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 'recommend' and the resource 'icon set for named UI slots'. It specifies context ('product, app, dashboard, or navigation flow') and distinguishes from siblings by emphasizing coherence and multiple slots.
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 needs several icons that should work together', providing clear direction for when to use. It does not explicitly exclude single-icon scenarios, but the sibling tools cover that implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_iconsSearch IconsARead-onlyIdempotentInspect
Search 20,000+ curated SVG icons across 10 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", or "AI model". Returns matching icons with SVG code and public semantic guidance.
| 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 lucide, tabler, phosphor, heroicons, bootstrap, iconoir, ionicons, material, simpleicons, and mingcute. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Matching icons with SVG code and semantic guidance. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: it retrieves SVG code and 'public semantic guidance', and highlights the scale ('20,000+ curated SVG icons across 10 libraries'). This adds value beyond annotations, though no explicit mention of potential latency or filtering quirks.
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: first sentence states the core function, second gives usage guidance with examples, third describes the return value. Every sentence is essential, no redundancy, and it is front-loaded for quick understanding.
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 rich schema annotations, parameter descriptions, and existence of an output schema, the description covers the tool's purpose, usage, and returns adequately. It lacks explicit mention of pagination or sorting, but the limit parameter addresses the former. Overall, it is complete for a search tool with good structured metadata.
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 each parameter having a detailed description (e.g., query examples, limit ranges, style enum, locale enum, library list). The description itself does not add new parameter details but reinforces the query concept with examples. Baseline 3 is appropriate as the schema carries the semantic weight.
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 searches icons by meaning, labels, tags, and synonyms across multiple libraries. It uses a specific verb ('Search') and resource ('20,000+ curated SVG icons'), and the sibling tools (get_icon, list_libraries, recommend_icons) suggest distinct purposes, which the description implicitly differentiates 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 concrete examples. This gives a clear when-to-use guide, and the context of sibling tools implies when not to use (e.g., get_icon for specific icon IDs, list_libraries for browsing libraries).
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!