Skip to main content
Glama

Get a Hugeicon as SVG

get_icon

Render a single Hugeicons icon as SVG markup in a chosen style, with control over size, color, stroke width, and an optional absolute save path for exporting an .svg file.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
nameYesIcon name from search_icons, e.g. delivery-truck-01.
sizeNoWidth and height in px. Default 24.
colorNoMain colour. Default currentColor, which inherits the surrounding text colour.
styleNostroke-rounded
save_toNoAbsolute path (or ~/…) of an .svg file to write.
overwriteNoReplace save_to if it already exists.
stroke_widthNoStroke width for stroke-based parts. Icons ship at 1.5.
secondary_colorNoColour of the lighter layer in duotone, twotone and bulk styles. Defaults to color.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools