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., "@hugeicons-mcp Find a delivery truck icon as duotone-rounded SVG in #0f172a"
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.
An MCP server that gives AI assistants Hugeicons as SVG markup. With a Hugeicons Pro licence you get all 10 styles: stroke, solid and duotone in their variants, plus twotone and bulk. Without one you get the free stroke-rounded set. Each style has about 6,000 icons.
It runs on your machine. The icons come from the npm packages your licence installs, and the server renders them to SVG locally. The only network call is to hugeicons.com/api/icons for search tags, cached for 7 days. There is no telemetry.
The official @hugeicons/mcp-server does something different. It returns icon-font glyphs and setup docs, not SVG, and it has no Pro styles.
Tool | What it does |
| Finds icons by name, tag or category, e.g. "delivery truck". |
| Returns one icon as SVG in a chosen style, size, colour, secondary colour and stroke width. Can write it to an |
| Returns one icon in every installed style, so you can pick one. |
| Shows which styles are installed and how to add the rest. |
Names match the ones on hugeicons.com (delivery-truck-01, 1st-bracket). Code names such as DeliveryTruck01Icon work too.
Related MCP server: Svg/icons MCP
You need Node and pnpm. It is built and tested on Node 26.
git clone https://github.com/yakshitpatel/hugeicons-mcp.git
cd hugeicons-mcp
pnpm install
pnpm buildCopy your Universal License Key from the Tokens tab of your Hugeicons account, add this line to ~/.npmrc, then run pnpm install again:
//npm.hugeicons.com/:_authToken=YOUR_UNIVERSAL_LICENSE_KEYThe repo's own .npmrc already points @hugeicons-pro at the Hugeicons registry. Keep the key in your home folder so it never lands in git. Without a key, pnpm install skips the Pro packages and still succeeds.
Claude Code:
claude mcp add hugeicons -s user -- node /absolute/path/to/hugeicons-mcp/dist/index.jsClaude Desktop, Cursor and other clients take the same command in their MCP config:
{
"mcpServers": {
"hugeicons": {
"command": "node",
"args": ["/absolute/path/to/hugeicons-mcp/dist/index.js"]
}
}
}Ask in plain words:
"Find a Hugeicon for notifications and give me the duotone-rounded SVG in #0f172a with an orange secondary colour."
"Show me the home icon in every style."
"Save the solid-sharp settings icon to ~/Desktop/settings.svg at 48px."
To get an icon into Figma, ask for it with a save_to path and have your assistant upload that file with the Figma MCP.
Colours are hex (#0f172a), rgb(), hsl() or oklch() values, currentColor or transparent. Your assistant turns "orange" into a hex value.
save_to takes an absolute path or one starting with ~/. It only writes regular files ending in .svg, refuses symbolic links, hard links and pipes, and won't replace an existing file unless you pass overwrite: true.
pnpm build
pnpm testtest/real-packages.test.mjs parses and renders every icon in every installed style, about 60,000 files with Pro installed. It finishes in about 15 seconds.
The code is MIT. The icons are not part of this repo: they belong to Hugeicons and are covered by your Hugeicons licence. Pro icons need a valid Pro licence. This project is not affiliated with Hugeicons.
Returns the same icon as SVG in every installed style, to choose between them.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Icon name from search_icons, e.g. delivery-truck-01. | |
| size | No | Width and height in px. Default 24. | |
| color | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only safety is already covered by readOnlyHint=true, and openWorldHint is hinted at by the word 'installed', which implies results depend on the environment's style set. The description still omits useful behavior: whether missing styles are skipped, whether size/color apply uniformly to every returned SVG, and roughly how many results to expect. With annotations carrying the safety profile, this is adequate but thin.
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?
A single tight sentence with the core behavior front-loaded and no filler. It may be slightly too terse for the multi-output nature of the tool, but there is no wasted phrasing.
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 simple read-only 3-parameter tool with no output schema, the description conveys what comes back (SVG per installed style) and why. Minor gaps remain around output cardinality and the fact that styling parameters apply to all variants, but nothing blocks a correct call.
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 67% and the schema already documents name (with a pointer to search_icons), size, and color. The description adds nothing about how size or color propagate to the multi-style output, which is the one piece of non-obvious semantics here. Baseline 3 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?
States a specific verb and result ('returns the same icon as SVG') plus scope ('in every installed style'), which distinguishes it from get_icon (single icon) and list_styles (style catalog). It doesn't name a sibling explicitly, so differentiation is inferred rather than stated.
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 trailing clause 'to choose between them' implies the use case (style selection), but there is no explicit when-to-use framing, no statement of when to prefer get_icon or list_styles instead, and no note that the icon name should come from search_icons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one icon as SVG markup in the chosen style. Optionally writes it to an .svg file (use an absolute path), for example to upload into Figma.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Icon name from search_icons, e.g. delivery-truck-01. | |
| size | No | Width and height in px. Default 24. | |
| color | No | Main colour. Default currentColor, which inherits the surrounding text colour. | |
| style | No | stroke-rounded | |
| save_to | No | Absolute path (or ~/…) of an .svg file to write. | |
| overwrite | No | Replace save_to if it already exists. | |
| stroke_width | No | Stroke width for stroke-based parts. Icons ship at 1.5. | |
| secondary_color | No | Colour of the lighter layer in duotone, twotone and bulk styles. Defaults to color. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, and the description explains why: it can write an .svg file, with an explicit note to use an absolute path and an overwrite flag in the schema. That reconciles the non-read-only hint. It stops short of describing failure modes (e.g. write errors, path rejection).
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 waste, with the primary return value front-loaded and the optional side effect second. Nothing redundant.
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 no output schema, the description correctly identifies the return value as SVG markup and covers the main side effect. For an 8-parameter tool it leans on the rich schema, which is reasonable, though a note on what happens when save_to is combined with style/color would complete it.
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 88%, so the schema already documents nearly every parameter including defaults and constraints. The description adds only the 'chosen style' and 'absolute path' framing, both of which the schema states more precisely, so baseline 3 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?
States a specific verb and resource ('Returns one icon as SVG markup in the chosen style'), which clearly distinguishes retrieval from siblings like search_icons and list_styles. It doesn't explicitly name those siblings, keeping it short of a 5.
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?
Usage is implied by the optional file-write example ('for example to upload into Figma'), but it never states when to prefer this over search_icons or list_styles. The schema's name parameter does point back to search_icons, which carries some of that load.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows which of the 10 styles are installed and how to add the missing ones.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered structurally. The description adds that results include remediation guidance for missing styles, which is useful beyond annotations, but it doesn't say what the output looks like or how '10 styles' is enumerated.
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?
One sentence, front-loaded with the core behavior and followed by the secondary benefit (adding missing styles). No filler or 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?
For a zero-parameter, no-output-schema tool the description covers the essentials, but without an output schema it could usefully sketch the return shape (e.g., a list of style names with installed/missing flags). That gap keeps it at adequate rather than 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?
There are zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is empty and fully consistent with a no-argument status tool.
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 a specific verb and resource ('Shows which of the 10 styles are installed') and adds the remediation angle ('how to add the missing ones'). It is clear enough to distinguish from siblings like get_icon and search_icons, though it doesn't name them explicitly.
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?
Usage is only implied: an agent can infer this is a pre-flight/status check before requesting or installing styles. There is no explicit when-to-use versus compare_styles or search_icons, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Hugeicons by name, tag or category. Returns names to pass to get_icon.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | What the icon should show, e.g. "delivery truck" or "settings". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-ended nature are covered. The description usefully adds that the return value is icon names for get_icon (important since there is no output schema), but says nothing about result metadata, ranking, or what happens at the limit boundary.
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 core action and followed immediately by the actionable output. Zero wasted language.
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 two-parameter read-only search tool with existing annotations, this covers the essential behavior and downstream usage. The only meaningful gap is the unexplained limit parameter, which is a minor omission given its self-describing default and range in the schema.
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?
With 50% schema coverage, the description partially compensates by clarifying that the query matches name, tag, or category — meaning beyond the schema's 'what the icon should show' phrasing. However, the limit parameter (max 50, default 15) is never mentioned, so the description does not cover the undocumented half.
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?
States a specific verb and resource ('Find Hugeicons') plus the search facets ('by name, tag or category'), and explicitly distinguishes itself from the sibling get_icon by declaring it produces names to pass there. An agent can tell it apart from get_icon/list_styles without opening a schema.
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?
'Returns names to pass to get_icon' gives clear context for the intended two-step search-then-fetch workflow. It does not state when-not to use it or contrast with list_styles/compare_styles, keeping it just short of full exclusion guidance.
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.
v0.1.0compare_stylesget_iconlist_stylessearch_iconsScored across 4 tools
Each tool serves a clearly distinct purpose: searching, retrieving a single SVG, listing styles, and comparing all styles. The boundary between get_icon and compare_styles is well defined by the latter returning every installed style for comparison.
All four tools follow a consistent verb_noun convention: get_icon, list_styles, search_icons, compare_styles. There is no mixing of camelCase, vague verbs, or inconsistent patterns.
Four tools are well scoped for an icon lookup server: search, inspect installed styles, retrieve an icon, and compare styles. Each tool earns its place without redundancy.
The core workflow of finding, inspecting, and retrieving icons is covered, including style discovery and comparison. Minor gaps such as explicit category/tag enumeration or richer icon metadata exist, but agents can work around them via search.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
Icons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Search open SVG icon packs and fetch exact SVG markup from coding agents through MCP.
