This MCP server lets you discover and retrieve Keyline Icons as SVGs, React usage snippets, and set metadata.
search_icons: find icons by substring in kebab-case names, optionally filter by style, and limit results.
get_icon: get full SVG source for an exact icon name, with style and corner treatment options.
get_react_usage: get the React import line and JSX for an exact icon, style, and corners.
describe_set: get set overview, including icon count, styles, and style coverage rules.
1,286 icons, drawn on one 24×24 grid, in four styles and two corner treatments. Built for shadcn/ui, free under MIT.
keylineicons.com to browse and copy.
Style | Icons | What it is |
| 1,286 | The full set. 2px keylines on a 24 grid. |
| 1,286 | The stroke drawing over a flat plate at reduced opacity. |
| 1,286 | No outline: a grey body with the detail in full strength. |
| 1,286 | Solid, with the detail knocked back out of the shape. |
stroke is the drawing every other style starts from, and since 1.0.0 every
name comes in all four. two-tone is what duotone meant until 0.9.0: the
outline kept, a 40% plate under it. duotone now drops the outline and decides
per icon which part is grey and which is black, so the thing that matters reads
first: the check on a badge, the liquid in a flask, the data rather than the
chart's axes. A glyph with nothing to fill, like bar-chart, carries its stroke
drawing in the filled styles, so no import ever comes up empty.
Every drawing in the table comes twice: rounded, with round caps and filleted corners, and sharp, with butt caps and square corners. Same names, same coverage, so 10,288 SVGs in total.
icons/stroke/bell.svg
icons/sharp/stroke/bell.svg
icons/sharp/fill/bell.svgSharp is a drawing of its own rather than a filter over the rounded one. Squaring
a corner moves the ink, and where that changes the silhouette the geometry was
solved again, so both treatments sit side by side in raw/ and the build
converts neither into the other.
Related MCP server: brain-mcp-icon-visual
Copy one from the site. keylineicons.com is the
browser: click any icon to open it, then take it as SVG, JSX, a React import or
an npx line, at whatever style, corners, stroke width and size you have set.
The panel keeps the last three icons you opened, so two candidates can be held
side by side. That is the fastest path and needs no install.
Take the files. icons/<style>/<name>.svg and
icons/sharp/<style>/<name>.svg are plain, normalised SVGs with no wrapper, no
ids and no classes. They are generated, so treat them as build output: to
change one, change the drawing in raw/ and rebuild.
Import them in React. @keyline-icons/react exports one component per
icon, one entry point per style and corner treatment:
npm i @keyline-icons/reactimport { ArrowUpRight, Check, Menu } from "@keyline-icons/react"
import { Folder as FolderDuotone } from "@keyline-icons/react/duotone"
import { Folder as FolderFill } from "@keyline-icons/react/fill"
import { Folder as FolderSharp } from "@keyline-icons/react/sharp"
import { Folder as FolderSharpFill } from "@keyline-icons/react/sharp/fill"
<Check className="size-4" />
<ArrowUpRight size={16} />Every component takes the usual SVGProps plus size, and colours from
currentColor. There is no theme, no context and no provider.
The style entry points are smaller than the stroke one and deliberately so.
Check is three open strokes with nothing to fill, so it exists in
@keyline-icons/react and /sharp and in none of the others; Folder has an
interior and exists in all six. The counts at the top of this file are the same
fact.
components/icons/index.tsx is the same set generated for this repo's own
site, and @/components/icons is the import to use inside it. Both come off
icons/stroke/, so they hold the same drawings; the package is the one to
install anywhere else.
Import them in React Native. @keyline-icons/react-native is the same
components drawn through react-native-svg, with the same entry points and
export names, so shared code changes the package name and nothing else. It
works in Expo, on the web through Expo too.
npm i @keyline-icons/react-native react-native-svgimport { Check } from "@keyline-icons/react-native"
import { Folder } from "@keyline-icons/react-native/duotone"
<Check size={16} color="#2563eb" />A native view has no CSS to inherit from, so colour is a color prop rather
than currentColor.
Own the source with the shadcn CLI. The registry is served by the site, so
adding the set to a project is one entry in components.json:
"registries": {
"@keyline": "https://keylineicons.com/r/{name}.json"
}npx shadcn add @keyline/bell
npx shadcn add @keyline/fill/bell
npx shadcn add @keyline/sharp/fill/bellEach icon arrives as a self-contained component that imports nothing from the package, so it can be renamed, edited or folded into the project's own conventions. Take the package to have the whole set behind one import; take the registry to own a handful of files.
Add one at a time from the terminal. @keyline-icons/cli searches the set
and writes SVGs into a project without adding a dependency to it:
npx @keyline-icons/cli search arrow
npx @keyline-icons/cli add circle-arrow-down bell --out src/icons
npx @keyline-icons/cli add bell --style fill --corners sharpGive an agent the set. @keyline-icons/mcp is an MCP server that searches
the set, returns SVG source in any style and corner treatment, and returns the
React import, so an assistant picks a real icon name rather than guessing one:
claude mcp add keyline-icons -- npx -y @keyline-icons/mcpAnything else that speaks MCP over stdio runs the same command; the package's own README has the JSON.
Use them outside React. The whole set is on
Iconify as keyline-icons,
which covers Vue, Svelte, Solid, web components and the Tailwind plugin. Stroke
is the bare name and everything else is a suffix on it:
keyline-icons:bell
keyline-icons:bell-fill
keyline-icons:bell-sharp-duotoneIconify re-imports from this repository, so it carries whatever the last release drew. The install page has the snippet for each framework.
Drop one onto a Figma canvas. The Figma plugin inserts any icon in any style and either corner treatment into the file you already have open, and the Community file is the whole set as components, with style, corners and container as variant properties.
61 icons come in a square- form and 66 in a circle- form, which wrap the
base drawing rather than replacing it:
icons/stroke/arrow-down.svg
icons/fill/square-arrow-down.svg
icons/sharp/duotone/circle-arrow-down.svgA square- or circle- prefix does not always mean a container. circle-half
and square-dashed are shapes in their own right, with no base for them to
contain, so they are filed as regular icons. The rule is that the base has to
exist before the prefix means anything.
Arrows, Chevrons & Carets, Git, Files, Time, Mail, Finance, Commerce, Maps, Home, Media, Charts, Diagrams, Devices, Pointers, Text, Layout, Users, Gender, Emoji, Actions, Controls, Education, AI, Science, Health, Sport, Food & Drink, Art, Tools, Stationery, Shapes, Web, Weather, Transport, Nature and Animals, plus the Square and Circle container groups.
What changed in each release, redraws included, is on the changelog.
raw/<name>/ Figma exports, untouched. The source of truth.
icons/<style>/ Generated SVGs, rounded. Do not hand-edit.
icons/sharp/<style>/ Generated SVGs, sharp. Do not hand-edit.
components/icons/ Generated React components. Do not hand-edit.
pipeline/ The build, the linter and the checks.
app/, components/ The site at keylineicons.com.
packages/ Publishable packages.Node 20.9 or newer, and pnpm.
pnpm install
pnpm dev # the site
pnpm icons:build # raw/ -> icons/
pnpm icons:react # icons/ -> components/icons/ and packages/react/
pnpm icons:lint # geometry and coverage rules
pnpm icons:ci # everything CI runspipeline/README.md is the real documentation: what the build normalises, every
rule the linter enforces and why, how the Figma check works, and the standard a
new drawing has to meet. Read it before adding an icon. The drawing standard is
not a matter of taste here, it is measured, and the linter will tell you the
number it wanted.
Two checks deliberately sit outside CI. icons:figma needs the Figma file,
which CI does not have. brand:check rasterises through headless Chrome, where
two versions disagree by a pixel on identical input, and a check that cries wolf
gets switched off. Run both locally.
Preline, since August 2026.
The set is free, has no paid tier, and is not getting one. Sponsorship pays for the hours rather than unlocking anything, so every icon added is added for everyone.
Sponsoring on GitHub from $25 a
month puts your name in this section, and from $100 a month on
keylineicons.com as well. lib/sponsors.ts is the
list both read from.
MIT. See LICENSE. Use them in anything, commercial included, without attribution.
The licence covers the icons and the code. It does not grant rights in the name "Keyline Icons".
What this set is: how many icons, which styles, and the rule that decides which icons have which style. Call this first when deciding whether the set covers what you need.
| 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 and does disclose the return content (icon count, styles, styling rule). It does not mention auth, cost, or limits, but for a zero-param read-only metadata call that is a minor gap.
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 that are front-loaded with what is returned, then the when-to-use cue. No filler, though the phrasing is slightly indirect.
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?
No output schema exists, so describing the returned fields is valuable and largely covered. With no parameters and no output schema, little else is required for an agent to call it 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?
Zero parameters, so the baseline is 4; nothing to document and the description appropriately does not discuss inputs.
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 that it returns metadata about the icon set (count, styles, style-assignment rule), which is a specific verb-less but resource-specific disclosure. It is distinguishable from siblings like search_icons/get_icon, though 'What this set is' is slightly meta phrasing rather than a crisp verb+resource.
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?
'Call this first when deciding whether the set covers what you need' gives a clear usage context and ordering relative to other tools. No explicit when-not or alternative named, but the routing intent is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full SVG source for one icon, ready to paste. Colour comes from currentColor, so it inherits whatever text colour is in scope.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact icon name, e.g. `circle-arrow-down`. | |
| style | No | Defaults to `stroke`, the only style every icon has. | |
| corners | No | Corner treatment. `regular` is the rounded drawing and the default; `sharp` is the same icon with squared corners and butt caps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the output is full SVG source and that colour comes from `currentColor` (inheriting text colour), which is genuine output behavior. However, it says nothing about error handling for bad names, permissions, or response shape beyond the SVG snippet.
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 tight sentences with zero filler, and the core output fact (full SVG source) is front-loaded. Every clause earns its place by describing what is returned and how colour behaves.
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 getter with one required parameter and full schema coverage, the description sufficiently explains the return value ('full SVG source') despite there being no output schema. It could be more complete by addressing failure modes or explicitly routing to siblings, but nothing essential is missing 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?
Schema description coverage is 100%, so the schema already documents all three parameters (name, style, corners) and their enums thoroughly. The description adds no parameter-level detail beyond the schema, which is the expected baseline when the schema is complete.
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 (implied 'get') and resource ('full SVG source for one icon'), and adds a use-case cue ('ready to paste'). It does not explicitly distinguish itself from the sibling get_react_usage, though the phrase 'full SVG source' implies raw output rather than a React snippet.
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 a context (you need the raw SVG to paste somewhere), but it gives no explicit when-to-use guidance and does not name or contrast with alternatives like get_react_usage or search_icons. An agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The import line and JSX for one icon from @keyline-icons/react. Each style is its own entry point because they do not cover the same icons, and sharp is one segment further along: @keyline-icons/react/sharp and /sharp/duotone. The export is called the same thing either way.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Exact icon name, e.g. `circle-arrow-down`. | |
| style | No | Defaults to `stroke`. | |
| corners | No | Corner treatment. `regular` is the rounded drawing and the default; `sharp` is the same icon with squared corners and butt caps. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully explains the entry-point scheme (`/sharp`, `/sharp/duotone`) and that the export name is stable across styles, but it says nothing about error behavior for unknown icon names or whether results are cached/static.
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 output promise is front-loaded in the first sentence, and the path details follow as supporting context. The second sentence is a bit dense but each clause conveys import-path information an agent cannot get elsewhere.
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?
There is no output schema, and the description compensates by stating what is returned (import line plus JSX). For a simple three-parameter read tool this is nearly complete, with only error/edge-case behavior left unstated.
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 100%, so the enum values and defaults are already documented in the schema. The description adds entry-point path context but no additional per-parameter meaning beyond that, so the 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?
The description names a specific deliverable ("the import line and JSX for one icon") and the source package (`@keyline-icons/react`), so the purpose is clear. It does not, however, distinguish itself from siblings like `get_icon` or `describe_set`, leaving the agent to infer the difference.
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: readability suggests you call this when you want React import syntax rather than icon metadata. There is no explicit when-to-use, when-not-to-use, or reference to alternatives such as `get_icon` or `search_icons`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find icons by name. Returns matching names and which of the four styles each one has. Names are kebab-case and compounds read base-first, so a mail icon with a tick is mail-check, not check-mail. Search the base word to find a family. Word order does not matter and a component name from another set is accepted as written, so CheckCircle2 finds circle-check. Trust an empty result: it means the set has no such icon.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results. Default 25. | |
| query | Yes | Substring to match, e.g. `arrow` or `mail`. | |
| style | No | Only return icons that have this style. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the return content, the kebab-case base-first naming convention, normalization behavior, and the meaning of an empty result. It omits any mention of auth requirements, rate limits, or result-count behavior (limit defaulting to 25), which the schema only partially covers.
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?
Purpose leads, then return shape, then three tight sentences of search semantics. Every sentence earns its place and none is 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?
No output schema exists, so the description must explain returns, which it does (names + styles). Combined with full schema coverage of the three params, an agent has everything needed to call this correctly; limit/pagination is handled 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?
Schema coverage is already 100%, so baseline is 3, but the description adds real semantic value on `query`: base-first compounds, order-insensitivity, and cross-set name acceptance. The `style` annotation is only implied ("which of the four styles"), so it doesn't add beyond the enum.
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+resource ("Find icons by name") and immediately describes the return shape (matching names plus which of four styles). The plural/verb distinguishes it from the singular get_icon sibling without the agent opening the 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?
Gives strong operational guidance on querying: search the base word to find a family, word order is irrelevant, foreign component names are accepted, and an empty result is authoritative. It never names an alternative sibling (get_icon, describe_set), so it stops short of explicit when-not 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.0describe_setget_iconget_react_usagesearch_iconsScored across 4 tools
Each tool has a clearly distinct purpose: search_icons finds icons by name, get_icon retrieves SVG source, get_react_usage retrieves React import/JSX, and describe_set explains the set. No two tools overlap in output or intent, and descriptions make the boundaries explicit.
All tool names follow a consistent verb_noun snake_case pattern: search_icons, get_icon, get_react_usage, describe_set. The verbs are clear and the naming convention is uniform throughout.
With 4 tools, the set is well-scoped for an icon library: discovery, retrieval in two formats, and set description. Each tool earns its place without redundancy or unnecessary bloat.
The core workflows—search, SVG retrieval, React usage, and set overview—are covered. A minor gap exists in browsing or listing all icons (e.g., no list-all or filter-by-style tool), but agents can work around it via search queries.
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 161,000+ free icons; get SVG (single/bulk), PNG, related icons, webfont classes. No API key.
Search and fetch genuine Icons8 icons and Ouch illustrations as SVG, PNG or animation.
