Skip to main content
Glama
Sign In
@opensvg/mcp

@opensvg/mcp

by mahbubhasanhira
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_icon

Fetches an icon as SVG markup or precompiled React JSX, Vue 3, Svelte, or Data URI code with configurable size, color, and stroke width, ready to use by identifier or database ID.

Instructions

Retrieve the vector markup or pre-compiled framework component code for an icon (SVG, React JSX, Vue 3, Svelte, or Data URI).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "get_icon"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesFull icon identifier (e.g. "lucide:shopping-cart", "heroicons:bell") or numeric database ID.
sizeNoWidth and height dimension in pixels (e.g. 20, 24, 32). Default is 24.
colorNoFill or stroke color (e.g. "currentColor", "#4f46e5", "rgb(99, 102, 241)"). Default is "currentColor".currentColor
formatNoOutput framework format. Default is "svg". Use "react" to get an inline JSX React component with TypeScript props.svg
strokeWidthNoStroke thickness for stroke-based outline icon packs (e.g. 1.5, 2). Default is 2.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are supplied, so the description bears the full burden, and it does disclose the key behavioral trait: the output is source code in one of five framework targets, not an image or metadata record. It is silent on other relevant traits, such as whether size/color/strokeWidth are baked into the emitted markup, whether the call is a pure read with no side effects, and what happens when the id is unknown or the icon lacks the requested format.

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?

A single front-loaded sentence with the verb, resource, and enumerated returnable formats; no filler, no restatement of the tool name, and the most decision-relevant information (that this returns code, and which formats) appears immediately.

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 and no annotations, the description must convey the return shape, and it does so adequately by characterizing the output as markup or pre-compiled component code across five formats. It falls short of fully complete only on failure behavior and on how the styling parameters manifest in the returned code, which an agent would need to know to call it confidently.

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 description coverage is 100%, so every parameter including defaults and the format enum is already documented in the schema, which sets the baseline at 3. The description reinforces that 'format' selects the output artifact by naming the five targets, but adds no new semantics about id syntax, size units, or color handling beyond what the schema states.

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?

The description uses a specific verb ('Retrieve') and resource ('icon') and enumerates what is returned: vector markup or pre-compiled component code in SVG, React JSX, Vue 3, Svelte, or Data URI form. That is enough to distinguish it in practice from search_icons (discovery) and svg_to_data_uri (conversion of existing markup), but it never names or contrasts those siblings explicitly.

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 only implied: an agent can infer this is the fetch step once an icon id is known, since a required 'id' parameter is present. There is no explicit when-to-use/when-not guidance, no mention of using search_icons first to obtain an id, and no statement about how this differs from svg_to_data_uri when format is 'data-uri'.

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