Skip to main content
Glama
deenesjakoruzh
SeeYangZhi

heroicons-mcp

by SeeYangZhi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ヒロイコンズ-MCP

Heroicons をLLM およびエージェントアプリケーションのリソースおよびツールとして公開するModel Context Protocol (MCP)サーバー。Bun と MCP TypeScript SDK を使用して構築されています。

Heroicons とは何ですか?

Heroiconsは、Tailwind CSSの開発者によってデザインされた、手作りのSVGアイコンの人気ライブラリです。アイコンは複数のスタイル（アウトライン、ソリッド）で提供されており、Webプロジェクトに簡単に統合できます。

Related MCP server: SupaUI MCP Server

MCPとは何ですか?

モデル コンテキスト プロトコル (MCP)は、AI ツールがメインのトレーニング データ以外のソースから特定のコンテキストを要求するための標準です。

この MCP サーバーにより、AI コーディング アシスタントやその他のエージェント アプリケーションが Heroicons に関する情報にアクセスできるようになり、より優れた支援機能とアイコン検索機能が実現します。

特徴

  • Heroicons を MCP リソースとして公開します (アウトラインとソリッド スタイル)

  • 名前やキーワードでアイコンを検索するためのツールを提供します

  • すべてのアイコンまたは特定のスタイル内のアイコンを一覧表示できます

  • Claude Desktop およびその他の MCP クライアントとの統合が可能

  • HTTPサーバーまたはstdioベースのMCPサーバーとして実行できます

前提条件

はじめに（開発）

1. リポジトリをクローンする

git clone https://github.com/SeeYangZhi/heroicons-mcp.git
cd heroicons-mcp

2. 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 サーバーを実行するには、主に 2 つの方法があります。

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でこの 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」サーバーが表示されるはずです。

注: stdio モードでnpx heroicons-mcp --stdioコマンドの使用が推奨されます。

利用可能なツール（MCP）

この MCP サーバーは、AI コーディング アシスタントに次のツールを公開します。

  1. すべてのアイコンをリストする

  • 説明: 使用可能なすべての Heroicons を一覧表示します。オプションでスタイル (アウトライン、ソリッド) 別にフィルター処理されます。

  • パラメータ: style (オプション: "outline" | "solid")

  1. 検索アイコン

  • 説明: すべてのスタイルで、名前またはキーワードで Heroicons を検索します。

  • パラメータ: query (文字列)、 style (オプション: "outline" | "solid")

  1. アイコンの使用例を取得する

  • 説明: 特定のアイコンの 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 を使用してコードベースをリントします。

リソース

ライセンス

マサチューセッツ工科大学

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