Skip to main content
Glama
deenesjakoruzh
SeeYangZhi

heroicons-mcp

by SeeYangZhi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

히어로아이콘-mcp

Heroicons를 LLM 및 에이전트 애플리케이션의 리소스 및 도구로 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. Bun과 MCP TypeScript SDK로 구축되었습니다.

Heroicons란 무엇인가요?

Heroicons는 Tailwind CSS 개발자들이 직접 디자인한 수작업 SVG 아이콘으로 구성된 인기 라이브러리입니다. 아이콘은 다양한 스타일(윤곽선, 단색)로 제공되며 웹 프로젝트에 쉽게 통합할 수 있습니다.

Related MCP server: SupaUI MCP Server

MCP란 무엇인가요?

MCP(Model Context Protocol)는 AI 도구가 기본 학습 데이터 외부의 소스에서 특정 컨텍스트를 요청하기 위한 표준입니다.

이 MCP 서버를 통해 AI 코딩 어시스턴트와 기타 에이전트 애플리케이션이 Heroicons에 대한 정보에 액세스하여 더 나은 지원 및 아이콘 검색 기능을 제공할 수 있습니다.

특징

  • Heroicons를 MCP 리소스(개요 및 단색 스타일)로 노출합니다.

  • 이름이나 키워드로 아이콘을 검색하기 위한 도구를 제공합니다.

  • 모든 아이콘 또는 특정 스타일 내의 아이콘을 나열할 수 있습니다.

  • Claude Desktop 및 기타 MCP 클라이언트와 통합 준비 완료

  • HTTP 서버 또는 stdio 기반 MCP 서버로 실행할 수 있습니다.

필수 조건

시작하기(개발)

1. 저장소를 복제합니다.

지엑스피1

2. Bun을 설치하세요(Bun이 없다면)

Bun 설치 가이드 를 참조하세요.
설치 후 터미널을 다시 시작하고 다음을 확인하세요.

bun --version

3. 종속성 설치

bun install

4. 프로젝트 빌드

이렇게 하면 TypeScript 소스가 build 디렉토리의 JavaScript로 컴파일됩니다.

bun run build

용법

HTTP 모드

npx 사용하여 HTTP 서버를 실행할 수 있습니다.

npx heroicons-mcp

이렇게 하면 HTTP 서버가 시작됩니다(기본값은 src/http.ts 에 정의된 대로 포트 3000).

또는 전역적으로 설치:

npm install -g heroicons-mcp

그런 다음 실행하세요.

heroicons-mcp

표준 모드

npx heroicons-mcp --stdio
# or if installed globally
heroicons-mcp --stdio

지역 개발

MCP 서버를 실행하는 두 가지 주요 방법은 다음과 같습니다.

1. HTTP 모드

HTTP를 통한 통신을 지원하는 클라이언트에 적합합니다.

개발용(Bun 사용):

bun run start
# or directly
bun run src/entry.ts

이는 src/entry.ts 에 정의된 서버를 실행하며, 기본값은 HTTP 모드입니다.

2. 표준 모드

Claude Desktop이나 MCP Inspector와 같은 도구와 직접 통합하여 표준 입출력을 통해 통신하는 데 자주 사용됩니다.

개발용(Bun 사용):

bun run src/entry.ts --stdio

AI 도구를 사용한 구성

예: Claude Desktop

Claude Desktop 에서 이 MCP 서버를 사용하려면:

  1. Claude Desktop 구성 파일을 엽니다.

code ~/Library/Application\ Support/Claude/claude_desktop_config.json

(또는 원하는 편집기를 사용하세요) 2. mcpServers 섹션에 서버를 추가합니다.

옵션 A: npx 를 통해:

{
  "mcpServers": {
    "heroicons": {
      "command": "npx",
      "args": ["heroicons-mcp", "--stdio"]
    }
  }
}

옵션 B: 빌드 출력을 직접 가리키기( bun run build 사용하여 프로젝트를 빌드했는지 확인):

{
  "mcpServers": {
    "heroicons": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/heroicons-mcp/build/entry.js", "--stdio"]
    }
  }
}

/ABSOLUTE/PATH/TO/heroicons-mcp/build/entry.js 빌드한 entry.js 파일의 실제 절대 경로로 바꾸세요.

  1. 파일을 저장하고 Claude Desktop을 다시 시작하세요.

  2. 이제 Claude의 도구 패널에서 "heroicons" 서버를 볼 수 있습니다.

참고: npx heroicons-mcp --stdio 명령은 stdio 모드에 권장되는 방법입니다.

사용 가능한 도구(MCP)

이 MCP 서버는 AI 코딩 어시스턴트에 다음 도구를 제공합니다.

  1. 모든 아이콘 목록

  • 설명: 사용 가능한 모든 영웅아이콘을 나열하고, 선택적으로 스타일(윤곽선, 실선)별로 필터링합니다.

  • 매개변수: style (선택 사항: "outline" | "solid")

  1. 검색_아이콘

  • 설명: 모든 스타일에서 이름이나 키워드로 Heroicons를 검색합니다.

  • 매개변수: query (문자열), style (선택 사항: "outline" | "solid")

  1. get_icon_usage_examples

  • 설명: 특정 아이콘에 대한 JSX 예제 사용법을 검색합니다.

  • 매개변수: name (문자열), style (문자열: "outline" | "solid")

사용 예

AI 도구가 MCP 서버를 사용하는 방법은 다음과 같습니다.

  1. 사용자가 AI 도구에 "Heroicons에서 '사용자' 아이콘을 찾아주세요. 단색 스타일이면 더 좋아요."라고 요청합니다 .

  2. AI 도구는 search_icons 호출합니다 :

  • query : "사용자"

  • style : "솔리드"

  1. MCP 서버는 일치하는 견고한 Heroicons(예: UserIcon , UserCircleIcon , UserPlusIcon ) 목록으로 응답합니다.

  2. 사용자가 도구에 "UserIcon의 사용 예를 보여주세요"라고 요청합니다 .

  3. AI 도구는 get_icon_usage_examples 호출합니다 :

  • name : "UserIcon"

  • style : "솔리드"

  1. MCP 서버는 JSX 코드 예제로 응답합니다 .

import { UserIcon } from "@heroicons/react/24/solid";

function Example() {
  return (
    <div>
      <UserIcon className="w-6 h-6 text-blue-500" />
    </div>
  );
}

Inspector를 사용하여 로컬에서 MCP 테스트

MCP Inspector를 사용하여 MCP 서버(stdio 모드)를 로컬로 테스트할 수 있습니다.

먼저, 프로젝트가 빌드되었는지 확인하세요.

bun run build

그런 다음 Inspector를 실행하고 --stdio 플래그와 함께 node ./build/entry.js 명령을 사용하여 서버에 연결합니다.

npx @modelcontextprotocol/inspector node ./build/entry.js --stdio

이렇게 하면 Inspector 인터페이스가 열리고 MCP 서버에서 노출된 리소스와 도구를 대화형으로 테스트할 수 있습니다.

개발 스크립트

  • bun run dev : 개발을 위해 HTTP 모드로 서버를 시작합니다( src/entry.ts 사용).

  • bun run dev:stdio : 개발을 위한 stdio MCP 서버를 시작합니다( src/entry.ts --stdio 사용).

  • bun run build : TypeScript를 JavaScript로 컴파일합니다( build/ 에 출력).

  • bun run lint : ESLint를 사용하여 코드베이스를 린트합니다.

자원

특허

MIT

Available Tools

3 tools
get_icon_usage_examplesB

Get usage examples for an icon

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesIcon component name, e.g. BeakerIcon
styleYesIcon style: solid or outline

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but does not reveal any behavioral traits such as whether it's a read-only operation, potential rate limits, error conditions, or the format of returned examples. For a tool with no annotations, this is a significant gap, warranting a score of 2.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly. This optimal conciseness earns a score of 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (2 required parameters) and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are important for an agent to use the tool effectively. Without annotations or an output schema, the description should do more, resulting in a score of 3.

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?

The schema description coverage is 100%, with clear descriptions for both parameters ('name' and 'style'), including an enum for 'style'. The description does not add any meaning beyond what the schema provides, such as explaining how 'name' relates to icon components or providing examples of usage. Given the high schema coverage, the baseline score of 3 is appropriate.

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 clearly states the verb 'Get' and the resource 'usage examples for an icon', making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'list_all_icons' or 'search_icons', which might also involve icons but serve different functions. This clarity without sibling distinction justifies a score of 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as 'list_all_icons' or 'search_icons'. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone. This lack of explicit guidelines results in a score of 2.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_all_iconsB

List all icons from the heroicons library, optionally filtered by style

ParametersJSON Schema
NameRequiredDescriptionDefault
styleNoIcon style: solid or outline (optional)

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions listing and optional filtering but doesn't describe key behaviors such as pagination, rate limits, authentication requirements, or what the output format looks like (e.g., list of icon names, metadata). For a tool with no annotations, this leaves significant gaps in understanding how it operates.

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?

The description is a single, efficient sentence that front-loads the core purpose ('List all icons from the heroicons library') and adds an optional feature ('optionally filtered by style'). There is no wasted text, and it's appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter intent but lacks details on behavioral aspects like output format or usage constraints. For a listing tool, this is borderline acceptable but could be improved with more context.

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%, with the single parameter 'style' fully documented in the schema (including enum values 'solid' or 'outline'). The description adds minimal value beyond the schema by mentioning 'optionally filtered by style', which aligns with the schema but doesn't provide additional context like default behavior if omitted or how filtering is applied.

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 clearly states the verb 'List' and resource 'all icons from the heroicons library', which provides a specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'search_icons' or 'get_icon_usage_examples', which likely have different functions (searching vs listing, or getting usage examples vs listing icons).

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?

The description implies usage by mentioning 'optionally filtered by style', suggesting this tool is for listing icons with optional style filtering. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_icons' (which might allow more complex queries) or 'get_icon_usage_examples' (which focuses on examples rather than listing).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_iconsB

Search for icons from heroicons by name or category

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoCategory to filter by (optional)
limitNoMax results to return
queryYesSearch term for icon name or category
styleNoIcon style: solid or outline

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't mention rate limits, authentication needs, response format, pagination, or error handling. The description only states the basic functionality without operational context.

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?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for this tool's complexity and front-loads the core functionality without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details about return values, error conditions, and behavioral constraints that would be helpful for an AI agent.

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 the schema fully documents all parameters. The description adds minimal value by mentioning 'name or category' search, which aligns with the 'query' parameter but doesn't provide additional semantic context beyond what's in the schema.

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 clearly states the action ('Search for icons') and resource ('from heroicons'), specifying the search scope ('by name or category'). It distinguishes from 'list_all_icons' by implying filtering, but doesn't explicitly differentiate from 'get_icon_usage_examples'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings is provided. The description implies filtering capabilities but doesn't specify scenarios where search_icons is preferred over list_all_icons or get_icon_usage_examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedget_icon_usage_examples
    • First observedlist_all_icons
    • First observedsearch_icons
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: listing all icons, searching icons by criteria, and getting usage examples for a specific icon. There is no overlap in functionality, making it easy for an agent to select the right tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_icon_usage_examples, list_all_icons, search_icons) with clear, descriptive verbs. The naming is uniform and predictable across the set.

Tool Count5/5

With 3 tools, this server is well-scoped for its purpose of accessing a heroicons library. Each tool serves a distinct and essential function, making the count appropriate without being too thin or heavy.

Completeness5/5

The tool set provides complete coverage for the domain: listing icons, searching icons, and getting usage examples. This covers the core workflows for accessing and utilizing an icon library, with no obvious gaps or dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • hugeicons-mcp

    hugeicons
    A
    license
    A
    quality
    F
    maintenance
    MCP server for Hugeicons integration and documentation This is a TypeScript-based MCP server that provides tools and resources for integrating Hugeicons into various platforms. It implements a Model Context Protocol (MCP) server that helps AI assistants provide accurate guidance for using Hugeicons
    5
    2,051 npm
    26
    MIT

  • PickAPIcon MCP

    Leee62
    A
    license
    B
    quality
    D
    maintenance
    MCP server that allows FE/UI/Designers to retrieve SVG icons via the Iconify API by simply asking LLMs rather than manually searching websites.
    3
    31 npm
    4
    MIT