Skip to main content
Glama
SeeYangZhi

Lucide Icons MCP

by SeeYangZhi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

lucide-icons-mcp

Ask DeepWiki

A Model Context Protocol (MCP) server exposing Lucide React icons as resources and tools for LLMs and agentic applications. Built with Bun and the MCP TypeScript SDK.

What is Lucide?

Lucide is a beautiful & consistent icon toolkit made by the community. It's an open-source icon library that provides over 1,500+ carefully crafted icons in a single, consistent style. Originally forked from Feather Icons, Lucide has grown into one of the most popular icon libraries for modern web development.

Related MCP server: heroicons-mcp

What is MCP?

The Model Context Protocol (MCP) is a standard for AI tools to request specific context from sources outside their main training data.

This MCP server allows AI coding assistants and other agentic applications to access information about Lucide React icons, enabling better assistance with icon search, discovery, and implementation.

Features

  • 🔍 Icon Search: Search through 1,500+ Lucide icons by name or category

  • 📂 Category Browsing: List icons by categories (Design, Communication, Media, etc.)

  • 💡 Usage Examples: Get React/JSX code examples for any icon

  • 🔧 Icon Information: Detailed information about each icon

  • 🚀 MCP Integration: Ready for Claude Desktop and other MCP clients

  • 🌐 Dual Mode: HTTP server or stdio-based MCP server

  • 📊 Comprehensive Coverage: All Lucide icons with proper JSX usage

Prerequisites

Getting Started (Development)

1. Clone the repository

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

2. Install Bun (if you don't have it)

Refer to the official Bun installation guide.
After installation, restart your terminal and check:

bun --version

3. Install dependencies

bun install

4. Build the project

This compiles the TypeScript source to JavaScript in the build directory.

bun run build

Usage

HTTP Mode

You can run the HTTP server using npx:

npx lucide-icons-mcp

This starts the HTTP server (defaults to port 3000).

Or install globally:

npm install -g lucide-icons-mcp

Then run:

lucide-icons-mcp

Stdio Mode

npx lucide-icons-mcp --stdio
# or if installed globally
lucide-icons-mcp --stdio

Local Development

There are two main ways to run the MCP server:

1. HTTP Mode

Suitable for clients that support communication over HTTP.

For development (using Bun):

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

2. Stdio Mode

Often used for direct integration with tools like Claude Desktop or the MCP Inspector.

For development (using Bun):

bun run src/entry.ts --stdio

Configuration with AI Tools

Example: Claude Desktop

To use this MCP server in Claude Desktop:

  1. Open your Claude Desktop configuration file:

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

  1. Add the server to the mcpServers section:

Option A: via npx (Recommended):

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

Option B: Pointing directly to the build output:

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

  1. Save the file and restart Claude Desktop.

  2. You should now see the "lucide-icons" server available in Claude's tools panel.

Tools Available (MCP)

This MCP server exposes the following tools to AI coding assistants. Each icon can belong to multiple categories, providing flexible search and discovery capabilities.

1. search_icons

  • Description: Search for Lucide icons by name or category. Returns icons with their complete category arrays.

  • Parameters:

    • query (string): Search term for icon name or category

    • category (optional string): Filter by specific category

    • limit (optional number): Maximum results to return

  • Returns: Array of icons with name and categories (string array)

2. search_categories

  • Description: Search for icon categories by category name using partial matching

  • Parameters:

    • query (string): Search term for category name

    • limit (optional number): Maximum results to return

  • Returns: Array of categories with name and iconCount

3. fuzzy_search_icons

  • Description: Fuzzy Search for icons from lucide by icon name

  • Parameters:

    • query (string): Search term for icon

    • limit (optional number): Maximum results to return

  • Returns: Array of icons with name and categories (string array)

4. fuzzy_search_categories

  • Description: Fuzzy Search for icon categories by category name

  • Parameters:

    • query (string): Search term for category name

    • limit (optional number): Maximum results to return

  • Returns: Array of categories with name and iconCount (string array)

5. get_icon_usage_examples

  • Description: Get usage examples for a Lucide React icon by the exact name

  • Parameters:

    • name (string): Search term for icon

  • Returns: React/JSX usage examples for a specific Lucide icon

6. list_all_icons_by_category

  • Description: List all icons in a specific category

  • Parameters:

    • category (string): Category name to list icons for

    • limit (optional number): Maximum results to return

7. list_all_categories

  • Description: List all available icon categories with their icon counts

Example Usage

Here's how an AI tool might use this MCP server:

Example 1: Finding Icons

User: "Find me icons related to ArrowRight"

AI tool calls search_icons:

{
  "query": "ArrowRight",
  "limit": 5
}

Response: Lists icons like ArrowRight

Example 2: Getting Usage Examples

User: "Show me how to use the ArrowRight icon"

AI tool calls get_icon_usage_examples:

{
  "name": "ArrowRight"
}

Response:

import { ArrowRight } from "lucide-react";

function Example() {
  return (
    <div>
      <ArrowRight />
    </div>
  );
}

Example 3: Browsing Categories

User: "What design-related icons are available?"

AI tool calls search_categories:

{
  "query": "design"
}

Then calls list_icons_by_category":

{
  "category": "Design",
  "limit": 10
}

Icon Categories

Lucide icons are organized into categories such as:

  • Accessibility

  • Accounts & access

  • Animals

  • Arrows

  • Brands

  • Buildings

  • Charts

  • Communication

  • Connectivity

  • Cursors

  • Design

  • Coding & development

  • Devices

  • Emoji

  • File icons

  • Finance

  • Food & beverage

  • Gaming

  • Home

  • Layout

  • Mail

  • Mathematics

  • Medical

  • Multimedia

  • Nature

  • Navigation

  • Notification

  • People

  • Photography

  • Science

  • Seasons

  • Security

  • Shapes

  • Shopping

  • Social

  • Sports

  • Sustainability

  • Text formatting

  • Time & calendar

  • Tools

  • Transportation

  • Travel

  • Weather

Testing MCP Locally with Inspector

You can test the MCP server locally using the MCP Inspector.

First, ensure the project is built:

bun run build

Then launch the Inspector:

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

This opens the Inspector interface for interactive testing of your MCP server.

Development Scripts

  • bun run dev: Starts the server in HTTP mode for development

  • bun run dev:stdio: Starts the stdio MCP server for development

  • bun run build: Compiles TypeScript to JavaScript (output in build/)

  • bun run lint: Lints the codebase using ESLint

  • bun run lint:fix: Automatically fixes linting issues

  • bun run crawl: Crawls Lucide website to update icon data

  • bun run pre-build: Crawls data, builds icon metadata, and fixes linting

Data Sources

This project includes a web crawler that automatically extracts icon information from the Lucide website, ensuring up-to-date icon data and categories.

Resources

License

This project is licensed under the MIT License. See LICENSE for details.

This project references icons from Lucide (https://lucide.dev/), which are licensed under their ISC License:

ISC License

Copyright (c) for portions of Lucide are held by Cole Bemis 2013-2022 as part of Feather (MIT). All other copyright (c) for Lucide are held by Lucide Contributors 2022.

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Available Tools

7 tools
fuzzy_search_categoriesC

Fuzzy Search for icon categories by category name

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return
queryYesSearch term for category name

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('Fuzzy Search') without details on permissions, rate limits, error handling, or what 'fuzzy' entails (e.g., partial matches, typos). This leaves significant gaps for a search tool.

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 waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

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

Completeness2/5

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

Given the complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., how 'fuzzy' works, return format) and doesn't compensate for the absence of structured data, making it inadequate for full agent understanding.

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%, so the schema already documents both parameters ('query' and 'limit') adequately. The description adds no additional meaning beyond implying 'category name' for the query, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.

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 ('Fuzzy Search') and resource ('icon categories by category name'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_categories' or 'list_all_categories', which prevents a perfect score.

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 like 'search_categories' or 'list_all_categories'. There is no mention of context, prerequisites, or exclusions, leaving the agent without usage direction.

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

fuzzy_search_iconsB

Fuzzy Search for icons from lucide by icon name

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return
queryYesSearch term for icon name

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. It mentions 'fuzzy search' but doesn't explain what that entails (e.g., tolerance for typos, ranking of results). It also omits key behavioral details like whether results are paginated, the default sorting, or any rate limits. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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 to parse quickly. Every part of the sentence earns its place by specifying the action, resource, and source.

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 (search with two parameters) and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior (e.g., result format, error handling) and usage context. With no annotations and incomplete behavioral transparency, it falls short of being fully complete for effective agent use.

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 clear descriptions for both parameters ('query' and 'limit') in the input schema. The description adds no additional parameter semantics beyond implying the query is for icon names. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 ('Fuzzy Search') and resource ('icons from lucide by icon name'), making the purpose immediately understandable. It distinguishes from siblings like 'search_categories' or 'list_all_icons_by_category' by specifying it searches icons by name. However, it doesn't explicitly contrast with 'search_icons' (a sibling tool), leaving some ambiguity about the difference between 'fuzzy_search_icons' and 'search_icons'.

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 like 'search_icons' or 'list_all_icons_by_category'. It doesn't mention prerequisites, such as needing a query term, or clarify the 'fuzzy' aspect (e.g., approximate matching vs. exact). Without this context, an agent might struggle to choose between similar tools.

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

get_icon_usage_examplesC

Get usage examples for a Lucide React icon

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesIcon name, e.g. 'home' or 'user'

TDQS

C2.9/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. While 'Get' implies a read operation, it doesn't specify what 'usage examples' entail (e.g., code snippets, descriptions, or visual previews), potential errors (e.g., invalid icon names), or response format. The description lacks details on rate limits, authentication needs, or data freshness.

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.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'usage examples' include (e.g., React code snippets, prop details), how results are structured, or error handling. For a tool with no structured output documentation, the description should provide more context about the return values.

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 input schema has 100% description coverage, with the 'name' parameter clearly documented as 'Icon name, e.g., 'home' or 'user''. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples. With 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 tool's purpose with a specific verb ('Get') and resource ('usage examples for a Lucide React icon'). It distinguishes from sibling tools like 'fuzzy_search_icons' or 'list_all_icons_by_category' by focusing on usage examples rather than searching or listing icons. However, it doesn't explicitly contrast with siblings in the description text itself.

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. It doesn't mention prerequisites (e.g., needing a valid icon name), exclusions, or compare it to sibling tools like 'search_icons' which might return similar information. Usage is implied but not explicitly stated.

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

list_all_categoriesA

List all available icon categories with their icon counts

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It indicates a read-only list operation, which is safe, but does not disclose behavioral traits like pagination, rate limits, or error conditions. It adds value by specifying the inclusion of icon counts, but lacks deeper 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 that front-loads the core purpose ('List all available icon categories') and adds a useful detail ('with their icon counts') without any wasted words. It is appropriately sized for a simple tool.

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?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It clearly states what the tool does and what it returns. A minor gap is the lack of output format details, but for a list tool with no complex schema, this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing instead on the tool's output semantics (categories with icon counts), which is valuable beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List') and resource ('all available icon categories'), including the additional detail of 'with their icon counts' that distinguishes it from simply listing category names. It precisely communicates what the tool returns without ambiguity.

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

Usage Guidelines4/5

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

The description implies usage for retrieving a comprehensive list of categories with counts, but does not explicitly contrast when to use this versus sibling tools like 'search_categories' or 'list_all_icons_by_category'. It provides clear context (all categories, with counts) but lacks explicit alternatives or exclusions.

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

list_all_icons_by_categoryC

List all icons in a specific category

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryYesCategory name to list icons for
limitNoMax results to return (optional)

TDQS

C2.9/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 it's a listing operation but doesn't mention whether it's read-only, if there are rate limits, authentication requirements, pagination behavior, or what the return format looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple listing tool, making it efficient and easy to parse.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral traits like pagination. For a tool with 2 parameters and no structured output documentation, more context is needed to fully understand how to use it effectively.

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 description mentions 'specific category' which aligns with the 'category' parameter, but doesn't add meaning beyond what the schema provides. With 100% schema description coverage, the schema already documents both parameters well, so the description meets the baseline without compensating further.

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 in a specific category'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_all_categories' or 'search_icons', which could cause confusion about when to use this specific listing tool versus others.

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. With siblings like 'list_all_categories', 'search_icons', and 'fuzzy_search_icons', there's no indication of when filtering by category is preferred over other search methods or when to list categories instead of icons.

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

search_categoriesB

Search for icon categories by category name using partial matching

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return
queryYesSearch term for category name

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'partial matching' which adds some context about search behavior, but doesn't describe important aspects like pagination, rate limits, authentication requirements, error conditions, or what the return format looks like. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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 contains no wasted words. It's appropriately sized for a simple search tool and front-loads the essential information about what the tool does.

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 2 parameters, 100% schema coverage, but no annotations and no output schema, the description provides basic purpose and some behavioral context ('partial matching'). However, it doesn't compensate for the lack of output schema by describing return values, and with no annotations, it should provide more behavioral transparency about what to expect from the operation.

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 already fully documents both parameters ('query' and 'limit'). The description adds minimal value beyond the schema by implying the 'query' parameter is used for 'category name' searching with 'partial matching', but doesn't provide additional syntax, format, or usage details. This meets the baseline expectation when schema coverage is high.

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') and resource ('icon categories'), specifying the search field ('by category name') and matching method ('using partial matching'). It distinguishes from 'list_all_categories' by indicating search functionality, though it doesn't explicitly differentiate from 'fuzzy_search_categories' which might use different matching algorithms.

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 for searching categories with partial matching on names, but doesn't provide explicit guidance on when to use this tool versus alternatives like 'fuzzy_search_categories' or 'list_all_categories'. No exclusions or prerequisites are mentioned, leaving usage context somewhat ambiguous.

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 lucide by name or category using partial matching

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNocategory to filter by (optional)
limitNoMax results to return
queryYesSearch term for icon name

TDQS

B3.2/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 only states the search functionality. It doesn't disclose behavioral traits like whether this is a read-only operation, performance characteristics, rate limits, authentication needs, or what happens when no results are found. For a search tool with zero annotation coverage, this is inadequate.

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 communicates the core functionality without any wasted words. It's appropriately sized and front-loaded with the essential information.

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

Completeness2/5

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

Given the tool has no annotations and no output schema, the description should do more to explain what the tool returns, error conditions, or behavioral constraints. For a search tool with 3 parameters and multiple sibling tools, the current description is insufficiently complete.

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 already documents all three parameters (query, category, limit) with their descriptions and constraints. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.

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 ('Search for'), resource ('icons from lucide'), and method ('by name or category using partial matching'). It distinguishes from siblings like 'list_all_icons_by_category' by specifying search functionality, though it doesn't explicitly differentiate from 'fuzzy_search_icons' which may have similar functionality.

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 for searching by name or category with partial matching, but doesn't explicitly state when to use this tool versus alternatives like 'fuzzy_search_icons' or 'search_categories'. It provides some context but lacks clear guidance on tool selection among siblings.

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. 7 tool updatesv1.0.0
    • First observedfuzzy_search_categories
    • First observedfuzzy_search_icons
    • First observedget_icon_usage_examples
    • First observedlist_all_categories
    • First observedlist_all_icons_by_category
    • First observedsearch_categories
    • First observedsearch_icons
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 7 tools

Disambiguation3/5

There is significant overlap between fuzzy_search_categories and search_categories (both search categories by name, just with different matching algorithms), and between fuzzy_search_icons and search_icons (both search icons, with fuzzy vs partial matching). This creates ambiguity about which tool to use for similar tasks. However, the other tools (get_icon_usage_examples, list_all_categories, list_all_icons_by_category) have distinct purposes.

Naming Consistency5/5

All tools follow a consistent snake_case naming pattern with clear verb_noun structure (e.g., fuzzy_search_categories, list_all_categories, get_icon_usage_examples). The naming is predictable and readable throughout the set, with no deviations in style or convention.

Tool Count4/5

With 7 tools, the count is well-scoped for an icon library server, allowing coverage of categories, icons, and usage examples. It's slightly on the higher side due to redundant search tools, but overall reasonable and not excessive for the domain.

Completeness4/5

The tool set covers key operations for an icon library: listing categories and icons, searching icons and categories, and getting usage examples. There are minor gaps, such as no tool for getting detailed icon metadata (e.g., SVG data or tags) or managing icons, but core workflows for discovery and usage are well-covered.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • 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
    17 npm
    4
    MIT

  • heroicons-mcp

    SeeYangZhi
    A
    license
    A
    quality
    D
    maintenance
    heroicons-mcp is a Model Context Protocol (MCP) server that exposes Heroicons. It allows LLMs and agentic applications to search, list, and generate usage examples of icons in React applications.
    3
    3 npm
    MIT

  • Hugeicons

    xiaobenyang-com
    A
    license
    B
    quality
    D
    maintenance
    Hugeicons MCP Server is a TypeScript based server that provides integrated tools and resources for the Hugeicons icon library, supporting icon search, retrieval, and usage guides for multiple platforms.
    5
    2
    Apache 2.0

  • icogenie-mcp

    albertnahas
    A
    license
    Not graded
    quality
    C
    maintenance
    AI-powered SVG icon generation MCP server. Generate production-ready SVG icons from text descriptions with customizable styles, sizes, and themes.
    109 npm
    6
    MIT