heroicons-mcp
героиконы-mcp
Сервер Model Context Protocol (MCP), предоставляющий Heroicons в качестве ресурсов и инструментов для LLM и агентских приложений. Создан с помощью Bun и MCP TypeScript SDK.
Что такое Heroicons?
Heroicons — популярная библиотека иконок SVG, созданных вручную, разработанная создателями Tailwind CSS. Иконки доступны в нескольких стилях (Outline, Solid) и легко интегрируются в веб-проекты.
Related MCP server: SupaUI MCP Server
Что такое МКП?
Протокол контекста модели (MCP) — это стандарт для инструментов ИИ, позволяющий запрашивать определенный контекст из источников, находящихся за пределами их основных обучающих данных.
Этот сервер MCP позволяет помощникам по кодированию на основе ИИ и другим агентским приложениям получать доступ к информации о Heroicons, обеспечивая лучшую поддержку и возможности поиска иконок.
Функции
Раскрывает Heroicons как ресурсы MCP (стили Outline и Solid)
Предоставляет инструменты для поиска иконок по имени или ключевым словам.
Позволяет перечислить все значки или значки в определенном стиле.
Готов к интеграции с Claude Desktop и другими клиентами MCP
Может работать как HTTP-сервер или как MCP-сервер на базе stdio
Предпосылки
Начало работы (разработка)
1. Клонировать репозиторий
git clone https://github.com/SeeYangZhi/heroicons-mcp.git
cd heroicons-mcp2. Установите Bun (если у вас его нет)
Обратитесь к официальному руководству по установке Bun .
После установки перезагрузите терминал и проверьте:
bun --version3. Установка зависимостей
bun install4. Постройте проект
Это скомпилирует исходный код TypeScript в JavaScript в каталоге build .
bun run buildИспользование
HTTP-режим
Вы можете запустить HTTP-сервер с помощью npx :
npx heroicons-mcpЭто запустит HTTP-сервер (по умолчанию порт 3000, как определено в src/http.ts ).
Или установите глобально:
npm install -g heroicons-mcpЗатем выполните:
heroicons-mcpРежим Stdio
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. Режим Stdio
Часто используется для прямой интеграции с такими инструментами, как Claude Desktop или MCP Inspector, взаимодействуя через стандартный ввод/вывод.
Для разработки (с использованием Bun):
bun run src/entry.ts --stdioКонфигурация с помощью инструментов ИИ
Пример: Клод Десктоп
Чтобы использовать этот MCP-сервер в Claude Desktop :
Откройте файл конфигурации Claude Desktop:
code ~/Library/Application\ Support/Claude/claude_desktop_config.json(Или используйте предпочитаемый вами редактор) 2. Добавьте сервер в раздел mcpServers .
Вариант А: через 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 .
Сохраните файл и перезапустите Claude Desktop.
Теперь вы должны увидеть сервер «heroicons», доступный на панели инструментов Клода.
Примечание: команда npx heroicons-mcp --stdio является рекомендуемым способом для режима stdio.
Доступные инструменты (MCP)
Этот сервер MCP предоставляет следующие инструменты помощникам по кодированию на базе ИИ:
список_всех_иконок
Описание: Список всех доступных Heroicons, опционально отфильтрованных по стилю (контурный, сплошной).
Параметры:
style(необязательно: "outline" | "solid")
иконки_поиска
Описание: Поиск Heroicons по имени или ключевым словам во всех стилях.
Параметры:
query(строка),style(необязательно: "outline" | "solid")
получить_значок_примеры_использования
Описание: Извлекает пример использования JSX для определенного значка.
Параметры:
name(строка),style(строка: "outline" | "solid")
Пример использования
Вот как инструмент ИИ может использовать этот сервер MCP:
Пользователь задает инструменту искусственного интеллекта вопрос : «Найди мне иконку пользователя из Heroicons, желательно в сплошном стиле».
Инструмент ИИ вызывает
search_icons:
query: "пользователь"style: "твердый"
Сервер MCP отвечает списком соответствующих сплошных иконок Heroicons (например,
UserIcon,UserCircleIcon,UserPlusIcon).Пользователь запрашивает у инструмента : «Показать пример использования UserIcon».
Инструмент ИИ вызывает
get_icon_usage_examples:
name: "UserIcon"style: "твердый"
Сервер MCP отвечает примером кода JSX:
import { UserIcon } from "@heroicons/react/24/solid";
function Example() {
return (
<div>
<UserIcon className="w-6 h-6 text-blue-500" />
</div>
);
}Локальное тестирование MCP с помощью Inspector
Вы можете протестировать сервер MCP (режим stdio) локально с помощью MCP Inspector .
Сначала убедитесь, что проект построен:
bun run buildЗатем запустите Inspector и подключите его к своему серверу с помощью команды node ./build/entry.js с флагом --stdio :
npx @modelcontextprotocol/inspector node ./build/entry.js --stdioОткроется интерфейс инспектора, позволяющий интерактивно тестировать ресурсы и инструменты, предоставляемые вашим сервером 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 toolsget_icon_usage_examplesB
Get usage examples for an icon
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Icon component name, e.g. BeakerIcon | |
| style | Yes | Icon style: solid or outline |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Icon style: solid or outline (optional) |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category to filter by (optional) | |
| limit | No | Max results to return | |
| query | Yes | Search term for icon name or category | |
| style | No | Icon style: solid or outline |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
v1.0.0- First observed
get_icon_usage_examples - First observed
list_all_icons - First observed
search_icons
TDQS
Scored across 3 tools
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.
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.
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.
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
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Related MCP Servers
- AlicenseAqualityAmaintenanceA Model Context Protocol (MCP) server that helps large language models index, search, and analyze code repositories with minimal setup141,020 PyPI1,000MIT
- AlicenseCqualityDmaintenanceA Model Context Protocol server that enables AI agents to generate, fetch, and manage UI components through natural language interactions.340 npm7ISC
- AlicenseAqualityFmaintenanceMCP 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 Hugeicons52,051 npm26MIT
- AlicenseBqualityDmaintenanceMCP server that allows FE/UI/Designers to retrieve SVG icons via the Iconify API by simply asking LLMs rather than manually searching websites.331 npm4MIT