Allows searching over 100,000 SVG icons from the AntV Infographic icon library using semantic search, returning SVG URLs for use in infographics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-icon search for an icon representing data analytics"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for semantic SVG icon search.
Generate infographic SVG icons by keyword — over 100,000 icons with semantic search support, powered by AntV Infographic.
Related MCP server: icogenie-mcp
🔍 Semantic search — Find icons by meaning, not just exact names
🖼️ 100,000+ SVG icons — A massive library of high-quality infographic icons
⚡ Three transport modes — stdio, sse, and streamable-http
🪶 Minimal dependencies — Clean, focused implementation
🧪 Fully tested — Unit tests with Vitest
Tool | Description |
| Search for SVG icons by keyword. Returns a list of SVG URLs matching the semantic query. |
search_icons parameters:
Parameter | Type | Required | Default | Description |
| string | ✅ | — | Search keyword or phrase (e.g. |
| number | ❌ |
| Number of icons to return (1–20) |
Add to your MCP client configuration (e.g. Claude Desktop, VS Code, Cursor):
macOS / Linux:
{
"mcpServers": {
"mcp-icon": {
"command": "npx",
"args": ["-y", "mcp-icon"]
}
}
}Windows:
{
"mcpServers": {
"mcp-icon": {
"command": "cmd",
"args": ["/c", "npx", "-y", "mcp-icon"]
}
}
}mcp-icon supports three standard MCP transport protocols.
Used by desktop MCP clients (Claude Desktop, Cursor, etc.):
npx mcp-icon
# or explicitly:
npx mcp-icon --transport stdionpx mcp-icon --transport sse --port 3456
# Server available at: http://localhost:3456/ssenpx mcp-icon --transport streamable --port 3456
# Server available at: http://localhost:3456/mcpmcp-icon CLI
Options:
--transport, -t Transport protocol: "stdio", "sse", or "streamable" (default: "stdio")
--host, -h Host for SSE or streamable transport (default: localhost)
--port, -p Port for SSE or streamable transport (default: 3456)
--endpoint, -e Endpoint path:
- For SSE: default is "/sse"
- For streamable: default is "/mcp"
--help, -H Show this help message# Clone the repository
git clone https://github.com/hustcc/mcp-icon.git
cd mcp-icon
# Install dependencies
npm install
# Build
npm run build
# Run tests
npm test
# Start with MCP inspector (for local debugging)
npm startsrc/
├── index.ts # CLI entry point
├── server.ts # MCP server + tool handlers
├── services/
│ ├── stdio.ts # Stdio transport
│ ├── sse.ts # SSE transport
│ └── streamable.ts # Streamable HTTP transport
├── tools/
│ └── search-icons.ts # Tool definition
└── utils/
├── api.ts # Icon search API client
└── logger.ts # Logger utility
tests/
├── api.test.ts # API client unit tests
└── server.test.ts # MCP server integration testsMIT © hustcc
Search for SVG icons by keyword using semantic search. Returns URLs of matching SVG icons from a library of over 100,000 infographic icons.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | The number of icons to return. Must be between 1 and 20. Defaults to 3. | |
| keyword | Yes | The search keyword or phrase to find relevant icons (e.g. "data analysis", "cloud computing", "security"). |
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 the core behavior: semantic search, return of URLs, and a large icon library. It does not mention rate limits or auth, but for a read-only search tool these are less critical and the main behaviors are covered.
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 concise sentences, front-loaded with the main action and resource, followed by the key return type and scale. Every word earns its place without redundancy.
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 simplicity, two well-documented parameters, and no output schema, the description is complete: it specifies what the tool does, what it returns (URLs), and the source domain. No further context is necessary for correct invocation.
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?
Parameter schema coverage is 100% with both keyword and topK fully described. The description adds context about semantic search and library size but does not meaningfully enrich parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for SVG icons by keyword using semantic search and returns URLs. It specifies a concrete resource (SVG icons) and action (search), making the purpose unmistakable even without sibling comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a user needs SVG icons matching a keyword/phrase. There are no explicit exclusions or alternatives, but with no sibling tools, this level of guidance is clear and sufficient.
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.
v1.0.0search_iconsScored across 1 tool
With only one tool, there is no possibility of confusion or overlap between tools. The single tool's purpose is clear and unambiguous.
The tool name 'search_icons' follows a clear verb_noun pattern, which is consistent and predictable. There are no other tools to compare against, so consistency is perfect.
A single tool for an icon server is too few. The server name implies a broader scope, and one tool feels insufficient for handling icon-related operations beyond searching.
The tool surface is severely incomplete for an icon service. Only search is offered; there are no tools for retrieving specific icons, listing categories, or managing icons, leaving significant gaps.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Search 161,000+ free hand-drawn icons and fetch ready-to-embed SVG or PNG from any MCP client.
Search open SVG icon packs and fetch exact SVG markup from coding agents through MCP.
320K+ open-source SVG icons: 12 tools, anonymous metadata search; SVG, exports, collections via Pro.
