Find semantic Digche replacements for functional UI icons and retrieve the selected SVG style.
Find and rank Digche replacements for an icon from Lucide, Heroicons, Material Symbols, Font Awesome, or another library. Include the UI context for a more useful match.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1 to 10 candidates. | |
| context | No | Functional UI context, for example Back button in mobile navigation. | |
| sourceIcon | Yes | Original component or icon name, for example ArrowLeft. | |
| sourceLibrary | No | ||
| preferredStyle | No | Linear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It states the purpose (find and rank) but does not mention whether the operation is read-only, how results are ranked, or any side effects—though the tone implies a read-only action.
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 the main action, and no wasted words. The description is concise and immediately communicates the core purpose.
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 tool has 5 parameters and no output schema or annotations. The description tells what the tool does but not what a 'replacement' consists of, how ranking works, or the structure of the returned candidates. It is adequate for a simple tool but leaves 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 roughly 60% (sourceLibrary lacks a description). The description adds meaning to the context parameter ('Include the UI context for a more useful match') and clarifies that sourceLibrary is optional ('or another library'), but it doesn't significantly elaborate on other 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 specific verbs 'Find and rank' and identifies the resource 'Digche replacements', along with supported libraries (Lucide, Heroicons, Material Symbols, Font Awesome, or another). This clearly distinguishes the tool from broader search/recommendation siblings.
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 a practical tip about including UI context but gives no guidance on when to choose this tool over siblings like search_icons or recommend_icons. There are no exclusions or alternative scenarios, leaving the decision to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a validated SVG variant after selecting a Digche slug. Prefer Linear for functional product UI unless the project uses another Digche style. Use format "jsx" when pasting straight into a .tsx/.jsx file as an inline element — "svg" (default) is the raw markup, meant for dangerouslySetInnerHTML, a static file, or any non-JSX consumer.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| style | No | Linear | |
| format | No | svg | |
| allowFallback | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains the meaningful difference between 'svg' and 'jsx' output and calls the result 'validated'. It does not cover fallback or error behavior, but the core behavior is transparent.
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 concise sentences, front-loaded with the main purpose, then style guidance, then format guidance. Every sentence earns its place and there is no redundancy with the schema.
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 the required slug, style preference, and format semantics, which is sufficient for most calls. The undocumented allowFallback parameter and lack of output schema details prevent a perfect completeness rating.
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 0%, so the description must compensate. It adds meaning for style and format, and indirectly for slug. However, allowFallback is never explained, leaving a notable gap for one of the four 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 states a specific action ('Retrieve') on a specific resource ('validated SVG variant after selecting a Digche slug'). This clearly distinguishes the tool from siblings like search_icons, preview_icons, and recommend_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 prefer Linear style and when to use jsx vs svg format. It does not explicitly name alternatives or exclusion conditions, but the retrieval-by-slug context makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every published Digche category with its icon count and available styles. Call this once to learn the catalog vocabulary before filtering searches by category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds meaningful context by stating it lists 'every published' category (scope) and includes 'icon count and available styles' (content). The phrase 'Call this once' also hints at low cost, which is helpful. It does not explicitly say it is read-only, but 'list' strongly implies that.
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 with no fluff. The first sentence delivers the core functionality, and the second sentence provides usage guidance. Every part earns its place, and it is front-loaded with the key action.
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 tool is simple (0 params, no output schema). The description covers what it returns (categories with counts and styles) and when to use it. It could explicitly state that it returns a list/array, but 'List every...' implicitly conveys that. It is complete enough for an agent to invoke 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?
The tool has zero parameters, so the description cannot add parameter-level meaning. The schema already covers everything (empty properties). The baseline for 0 parameters is 4, and the description appropriately does not invent unnecessary parameter details.
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 every published Digche category, including icon count and available styles. It uses a specific verb ('List') and resource ('Digche category'), and it distinguishes itself from sibling tools like search_icons by focusing on catalog vocabulary rather than searching.
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 a clear 'when to use': 'Call this once to learn the catalog vocabulary before filtering searches by category.' It implies this is a one-time setup step and not for ongoing filtering, though it does not explicitly name alternatives or state 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.
Render candidate Digche icons as a single image so a person can compare them before choosing. Pass slugs from an earlier tool call, or a query to search and preview in one step.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1 to 24 icons. | |
| query | No | Used only when slugs are not supplied. | |
| slugs | No | Slugs from a previous result. | |
| style | No | Linear | |
| theme | No | light |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool renders a single image for comparison, but it does not mention read-only nature, output format details, or how conflicting inputs (slugs + query) are handled. Some behavior is implied (e.g., search+preview) but not fully elaborated.
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 compact sentences, front-loaded with purpose and then usage. Every word contributes, with no redundant restating of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional params and no output schema, the description covers core behavior and both usage modes. It omits some details like default handling when neither slugs nor query are supplied, and it doesn't explicitly describe the returned image format, but the schema fills some gaps (defaults, limits).
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 covers 60% of parameters (limit, query, slugs), and the description adds relational meaning: slugs come from a previous tool call, query is an alternative for one-step search+preview. However, style and theme have no description and are left only as enum labels, relying on implicit understanding.
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 'Render' with a clear resource ('candidate Digche icons') and the intended outcome ('compare them before choosing'). It distinguishes the tool from siblings like search_icons (which searches/returns metadata) and get_icon_svg (which returns a single SVG) by emphasizing a single composite image for comparison.
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 defines two usage modes: pass slugs from an earlier tool call, or use a query to search and preview in one step. This clearly indicates when to use the tool, though it does not name alternative tools or state exclusions (e.g., not for fetching SVGs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick a coherent Digche icon set for up to 20 named UI slots in one call. Give the overall task so ambiguous slot names resolve correctly. Use this instead of one search per icon when laying out a screen.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | What the screen is, for example: sidebar for a billing dashboard. | |
| slots | Yes | UI slots to fill, for example ["profile", "billing", "logout"]. | |
| limitPerSlot | No | 1 to 5 candidates per slot. | |
| responseMode | No | plan returns slugs only; assets adds the SVG for each top pick. | plan |
| preferredStyle | No | Linear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must disclose behavior. It reveals that the tool recommends a coherent set, supports up to 20 slots in one call, and uses the task context to resolve ambiguity. However, it doesn't disclose the output format (e.g., slugs vs. SVG) or any side effects, though the responseMode parameter covers the format.
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 with no filler. It front-loads the main action, then provides guidance on the task parameter, and ends with the usage comparison to search_icons.
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 moderate complexity (5 params, no output schema, no annotations), the description covers the core use case and distinguishes it from siblings. The main omission is explicit mention of responseMode (plan vs assets), but the parameter description in the schema covers that. Overall, it's sufficiently complete for an agent to invoke 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?
The schema already documents most parameters (80% coverage), but the description adds a critical constraint: 'up to 20 named UI slots' which is absent from the schema. It also explains the purpose of 'task' as resolving ambiguous slot names, adding meaning beyond the schema's example.
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 opens with 'Pick a coherent Digche icon set for up to 20 named UI slots in one call', clearly stating the verb, resource, and scope. It explicitly contrasts with per-icon search ('Use this instead of one search per icon'), distinguishing it from the search_icons sibling.
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 says to use this tool when laying out a screen and instead of one search per icon, providing a clear alternative. It also instructs users to 'Give the overall task so ambiguous slot names resolve correctly', which guides effective use. It doesn't enumerate other sibling tools, but the primary alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published Digche icons by name, alias, use case, tag, category, or functional meaning. Use this before choosing a UI icon. Returns a paste-ready summary and a preview image of the results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1 to 20. Out-of-range values are clamped. | |
| query | Yes | Functional intent such as previous page, analytics, or delete item. | |
| style | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches only 'published' icons and returns 'a paste-ready summary and a preview image', which are useful behavioral traits. However, it does not state whether the operation is read-only, or describe pagination or error behavior, so it's partial 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?
Two sentences, no filler. The first sentence states function, the second gives usage timing and return value. Efficient and 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?
The description covers purpose, timing, return format, and scope. It lacks detailed parameter semantics for style/category and doesn't explain the output schema, but these are partially covered by the input schema. The combination is adequate for a search tool with 4 simple parameters.
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 schema already documents query and limit. The description adds that query can include 'functional meaning' and other dimensions, enriching the query concept. However, the style and category parameters receive no description in either schema or text, even though the schema description coverage is only 50%. The description mentions 'category' as a search dimension but not as a filter parameter.
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 verb 'Search' and the resource 'published Digche icons', and enumerates search dimensions (name, alias, use case, tag, category, functional meaning). This distinguishes it from sibling tools like find_replacement or preview_icons, and the phrase 'Use this before choosing a UI icon' reinforces its purpose.
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 a clear usage context: 'Use this before choosing a UI icon.' However, it does not explicitly mention when not to use it or how it differs from sibling tools like find_replacement, so it lacks exclusions or alternative pointers.
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. Dates show when Glama detected each change.
get_icon_svg1 field changedInput schema / properties / formatAdded value: +{
+ "default": "svg",
+ "enum": [
+ "svg",
+ "jsx"
+ ],
+ "type": "string"
+}find_replacement6 fields changedInput schema / properties / limit / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / limit / defaultRemoved value: -5Input schema / properties / limit / descriptionAdded value: +"1 to 10 candidates."Input schema / properties / limit / maximumRemoved value: -10Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typeRemoved value: -"integer"list_categoriespreview_iconsrecommend_iconssearch_icons6 fields changedInput schema / properties / limit / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / limit / defaultRemoved value: -8Input schema / properties / limit / descriptionAdded value: +"1 to 20. Out-of-range values are clamped."Input schema / properties / limit / maximumRemoved value: -20Input schema / properties / limit / minimumRemoved value: -1Input schema / properties / limit / typeRemoved value: -"integer"find_replacementget_icon_svgsearch_iconsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Search open SVG icon packs and fetch exact SVG markup from coding agents through MCP.
Search 324k icons or generate new ones in the Lucide grammar - grammar-locked lint+critique+repair
Icons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Add one secure layer between your agents and this server.
Each tool targets a distinct workflow stage—discovery, replacement, bulk recommendation, comparison, and retrieval—so an agent can usually choose correctly. The only slight ambiguity is preview_icons, whose search-and-preview mode overlaps with search_icons' built-in preview image.
All six tools use a consistent snake_case verb_noun convention (find_, get_, list_, preview_, recommend_, search_), each verb uniquely identifies the action. No mixed patterns or vague generic names are present.
Six tools is well-scoped for an icon library: it covers discovery, selection, retrieval, and migration without bloat. Every tool has a clear role and the set is neither thin nor overwhelming.
The set covers the full icon workflow: discover via search/categories, evaluate via preview/recommend, retrieve via get_icon_svg, and migrate via find_replacement. A minor gap is the lack of batch SVG retrieval or detailed per-icon metadata, but agents can work around it by looping get_icon_svg.