Which integrations are available for this server?

Provides access to AWS cloud technology icons for use in architecture diagrams, including services across compute, storage, networking, and more. Provides access to Google Cloud Platform (GCP) technology icons for use in architecture diagrams, including services across compute, storage, networking, and more. Provides access to Kubernetes and container ecosystem icons for use in architecture diagrams, including cluster components, workloads, and networking.

How do I use tech-icons?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@tech-icons search for AWS Lambda icon" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

tech-icons

by zhiweio

Overview Schema Related Servers Score Discussions

Python

Local

tech-icons

English | 中文

The missing icon layer for AI-assisted architecture diagramming. Give your LLMs the power to see and place cloud icons across AWS, Azure, GCP, Kubernetes, on-prem infrastructure, and 20+ other vendors — directly, without switching tabs or hunting through vendor docs.

✨ Features

🔍 Multi-Tier Search — Exact ID → Keyword → Fuzzy → Semantic embedding search, layered for precision and recall
🎨 Dual Format Support — SVG and PNG icons across 21 vendors. Parameterized: image_type="svg" (default) or image_type="png", with automatic fallback
🔗 Cross-Vendor Concepts — compare_icons("kubernetes") returns the K8s icon from AWS, Azure, GCP, and Kubernetes vendor in one call
🌐 Streamable HTTP + stdio — Run locally (stdio) or as a web service (--transport http), or both (--transport dual)
🖥️ Built-in Web UI — --web launches a local icon browser (FastAPI + SPA) for visual exploration
📦 Zero Build, Works Everywhere — Icons are bundled in the wheel; no local build step, works with uvx directly
⚡ FastMCP Framework — Modern decorator-based tool registration with automatic JSON Schema generation
🧩 Extensible — format="ppt_master" generates placeholders for ppt-master; format="inline_group" composes directly into SVG architecture diagrams

Related MCP server: diagram-ai-generator

📋 Table of Contents

tech-icons

🚀 Quick Start

Run directly (no install needed)

# stdio MCP server — ready for Claude Desktop, Cursor, etc.
uvx tech-icons

# With semantic search (sentence-transformers embeddings)
uvx --with 'tech-icons[semantic]' tech-icons

# Launch the web icon browser
uvx --with 'tech-icons[web]' tech-icons --web --open

# Run as a Streamable HTTP service
uvx --with 'tech-icons[web]' tech-icons --transport http --port 8000

Run from this repository (development)

git clone https://github.com/zhiweio/tech-icons.git
cd tech-icons
uv run tech-icons

That's it. The published wheel bundles the full icon catalog (~1.4 MB metadata + SVGs)—no local build step, no asset download.

📦 Installation & Requirements

Requirement	Details
Python	≥ 3.10
Package Manager	uv (recommended), pip, pipx
Core Dependencies	`fastmcp`, `pyyaml`, `rapidfuzz`
Web UI (optional)	`fastapi`, `uvicorn` (`[web]` extra)
Semantic Search (optional)	`sentence-transformers`, `numpy` (`[semantic]` extra)
Everything	`[all]` extra = `[web,semantic]`

# Install with all features
uvx --with 'tech-icons[all]' tech-icons

# Or install globally
uv tool install 'tech-icons[all]'
tech-icons --web

Extras at a glance

Extra	Adds	When to use
none	Core MCP server (stdio)	Claude Desktop, Cursor, any MCP client
`[web]`	FastAPI + uvicorn	`--web` browser UI, `--transport http`
`[semantic]`	sentence-transformers	Tier-4 semantic search for vague queries
`[all]`	both of the above	Full functionality

🔧 Usage Modes

tech-icons supports five distinct operating modes, selected by CLI flags:

tech-icons                                    # stdio MCP (default)
tech-icons --transport http --port 8000       # Streamable HTTP MCP
tech-icons --transport dual                   # stdio + HTTP simultaneously
tech-icons --web --open                       # Local browser UI
tech-icons --ppt-master aws --target ./icons/  # Bulk icon export

1. MCP Server (stdio)

The default mode. The server reads MCP JSON-RPC messages from stdin and writes responses to stdout. This is what MCP clients like Claude Desktop and Cursor expect.

uvx tech-icons
# or with semantic search:
uvx --with 'tech-icons[semantic]' tech-icons

How it works: The client process spawns uvx tech-icons as a child process, communicates via stdin/stdout. One process per client session. No ports, no network—pure local IPC.

2. MCP Server (Streamable HTTP)

Run as a persistent HTTP service. Multiple clients can connect simultaneously. Uses the Streamable HTTP protocol for full bidirectional communication including streaming responses.

uvx --with 'tech-icons[web]' tech-icons --transport http --host 0.0.0.0 --port 8000

How it works: Uvicorn ASGI server starts, serving the MCP endpoint at http://host:port/mcp. Clients connect over HTTP/2 with streaming support. The server stays running—start once, many clients connect.

3. Dual Transport (stdio + HTTP)

Run both transports simultaneously on a single process with a shared engine instance. Perfect for development workflows where you want local IDE integration and a network-accessible service.

uvx --with 'tech-icons[web]' tech-icons --transport dual --port 8000

How it works: asyncio.gather() runs run_stdio_async() and run_http_async() concurrently. Both share the same SearchEngine instance (loaded once). Use Ctrl+C to stop.

4. Web UI

Launch a local icon browser with full-text search, vendor/category filters, paginated catalog, and SVG preview/download.

uvx --with 'tech-icons[web]' tech-icons --web --port 8765 --open

Opens http://127.0.0.1:8765 in your browser. The web UI uses the same SearchEngine class as the MCP server—no logic duplication.

5. PPT-Master Export

Batch-export SVG icons into a ppt-master template directory. Supports vendor names, comma-separated icon IDs, or all.

# Export a single vendor
uvx tech-icons --ppt-master aws --target ./templates/icons/

# Export specific icons
uvx tech-icons --ppt-master aws/compute/lambda,gcp/compute/cloud-run

# Export everything
uvx tech-icons --ppt-master all

# Use symlinks (no file copy overhead)
uvx tech-icons --ppt-master aws --symlink

🖥️ MCP Client Configuration

Claude Desktop / Claude Code

{
  "mcpServers": {
    "tech-icons": {
      "command": "uvx",
      "args": ["tech-icons"]
    }
  }
}

With semantic search

{
  "mcpServers": {
    "tech-icons": {
      "command": "uvx",
      "args": ["--with", "tech-icons[semantic]", "tech-icons"]
    }
  }
}

Streamable HTTP (remote / self-hosted)

{
  "mcpServers": {
    "tech-icons": {
      "url": "http://your-server:8000/mcp",
      "transport": "http"
    }
  }
}

Cursor / Windsurf / other MCP-compatible editors

Use the same stdio configuration as Claude Desktop above. For HTTP transport, check your editor's MCP documentation for HTTP endpoint support.

🐳 Docker

Pre-built Docker image with both MCP server and Web UI modes. Choose via the SERVER_MODE environment variable.

Quick Start

# Build the image
docker build -t tech-icons .

# Run as MCP Streamable HTTP server (default)
docker run -p 8765:8765 tech-icons

# Run as Web UI (icon browser)
docker run -p 8765:8765 -e SERVER_MODE=web tech-icons

docker-compose

# MCP server mode
docker compose --profile mcp up -d

# Web UI mode
docker compose --profile web up -d

Environment Variables

Variable	Default	Description
`SERVER_MODE`	`http`	`http` = MCP Streamable HTTP server, `web` = FastAPI web UI
`HOST`	`0.0.0.0`	Bind address (always `0.0.0.0` inside the container)
`PORT`	`8765`	Listen port
`LOG_LEVEL`	`info`	Python log level

Claude Desktop Configuration (Docker)

Connect Claude Desktop to a containerized tech-icons via Streamable HTTP:

{
  "mcpServers": {
    "tech-icons": {
      "type": "streamableHttp",
      "url": "http://localhost:8765/mcp"
    }
  }
}

Note: The container binds 0.0.0.0:8765. If running the container on a remote host, replace localhost with the host's IP address.

🛠️ Tools & API Reference

tech-icons exposes 7 tools, 1 resource, and cross-vendor concept groups:

Tools

Tool	Parameters	Returns	Description
`search_icons`	`query` (required), `vendor`, `category`, `limit`	`list[dict]`	Multi-tier search: exact ID → keyword → fuzzy → semantic
`get_icon`	`id` (e.g., `aws/compute/lambda`)	`dict`	Full metadata: vendor, category, name, aliases, tags, description, path
`get_icon_image`	`id`, `format` (default: `raw`), `image_type` (default: `svg`)	`str` or `list`	Icon content in chosen format and image type (SVG or PNG); `download` returns `Image` attachment
`list_categories`	`vendor` (optional)	`list[str]`	All icon categories, optionally filtered by vendor
`list_vendors`	none	`dict[str, int]`	Vendor name → icon count mapping (21 vendors)
`list_concepts`	none	`list[str]`	Cross-vendor concept names (e.g., `kubernetes`, `serverless`)
`compare_icons`	`concept` (e.g., `kubernetes`)	`dict`	Icons from all vendors for a concept, grouped by vendor

All parameters with Annotated[type, "description"] type hints auto-generate JSON Schema via FastMCP.

Resource

URI	MIME Type	Content
`icon://catalog`	`application/json`	Full 5,200+ entry icon catalog with all metadata

LLM Usage Examples

Find an icon for a specific AWS service:

search_icons(query="Lambda")

Compare Kubernetes icons across clouds:

compare_icons(concept="kubernetes")

Get a data URI for embedding in an HTML architecture diagram:

get_icon_image(id="gcp/compute/cloud-run", format="data_uri")

Get a PNG icon for a Kubernetes component:

get_icon_image(id="kubernetes/compute/pod", image_type="png", format="data_uri")

List all Azure database services:

search_icons(query="database", vendor="azure", category="databases")

Explore the full catalog:

read_resource("icon://catalog")

🎨 Format Options

Each format serves a distinct integration scenario:

Format	Output	Use Case	Example
`raw`	SVG XML string	Inspection, direct embedding	`"<svg xmlns=\"...\">...</svg>"`
`path`	Absolute filesystem path	Local tooling, file references	`"/path/to/icons/aws/compute/lambda.svg"`
`base64`	Base64-encoded SVG	Binary transport, JSON payloads	`"PHN2ZyB4bWxucz0i..."`
`data_uri`	`data:image/svg+xml;base64,...`	HTML `<img>` tags, CSS backgrounds	`"data:image/svg+xml;base64,..."`
`inline_group`	`<g viewBox="...">...</g>`	Direct SVG composition in diagrams	`"<g viewBox=\"0 0 64 64\"><path d=\"...\"/></g>"`
`ppt_master`	`<use data-icon="tech-icons/..."/>`	ppt-master skill placeholder	`"<use data-icon=\"tech-icons/aws/compute/lambda\"/>"`
`download`	Text summary + `Image` attachment	Download the SVG file	Text + `Image(data=..., format="svg+xml")`

🏷️ Icon ID Convention

All icons follow a consistent canonical ID format:

{vendor}/{category}/{name}

Examples:

aws/compute/lambda — AWS Lambda
azure/databases/cosmos-db — Azure Cosmos DB
gcp/serverless-computing/cloud-run — Cloud Run
microsoft/365/teams — Microsoft Teams
cncf/orchestration/kubernetes — Kubernetes
devicon/framework/react — React

IDs are lowercase, with hyphens for multi-word names. Use list_categories(vendor="aws") to explore available categories for a vendor.

🏗️ Architecture & Design

Key Design Decisions

Single SearchEngine, multiple interfaces — The SearchEngine class has one instance. The MCP server, FastAPI web app, and ppt-master CLI all wrap it—no logic duplication.
Tiered search with early termination — Search stops at the first tier that returns ≥ limit results. Most queries hit Tier 1 (exact ID) or Tier 2 (keyword index) and never reach fuzzy or semantic—fast and cheap.
Bundled catalog in wheel — icons.json, keyword_index.json, and SVGs are packaged via hatchling. importlib.resources.files() resolves paths at runtime, works in both dev (uv run) and installed (uvx, pipx) environments.
Lazy loading — The engine loads catalog data from disk only on first access (_ensure_loaded()). In stdio mode, engine.load() is called explicitly before mcp.run().
FastMCP decorator pattern — Each tool is a standalone function decorated with @mcp.tool. Python type hints (Annotated[str, "desc"], Literal["aws", ...]) auto-generate JSON Schema. No manual inputSchema writing.
Cross-vendor concept registry — enrichments.yaml defines technology concepts (e.g., "kubernetes") and maps them to icon IDs across vendors. Concept metadata is loaded on engine initialization and available as engine.concepts.

Technology Stack

Component	Technology	Rationale
MCP Framework	FastMCP 3.4	Decorator-based, auto Schema, stdio+HTTP dual transport
Search Engine	Custom (4-tier)	Exact → keyword → fuzzy → semantic, early termination
Fuzzy Matching	rapidfuzz	Token-sort ratio scoring, C-accelerated
Semantic Search	sentence-transformers	all-MiniLM-L6-v2, optional extra
Web UI	FastAPI + SPA	Shared engine instance, CORS-enabled
Build System	hatchling	PEP 517, supports bundling data files
Package Manager	uv	Fast resolver, `uvx` for one-shot runs

🔗 Integrations

ppt-master

The ppt_master format generates <use data-icon="tech-icons/..."/> elements compatible with ppt-master's embed_icons.py hook. Use --ppt-master to bulk-export icons:

uvx tech-icons --ppt-master aws --target ./templates/icons/
uvx tech-icons --ppt-master aws/compute/lambda,gcp/compute/cloud-run --symlink

Architecture Diagrams

Use format="data_uri" for HTML <img> tags, or format="inline_group" for direct SVG <g> element composition:

<!-- data_uri: embed in HTML -->
<img src="DATA_URI_OUTPUT" alt="AWS Lambda" class="tech-icon--md" />

<!-- inline_group: embed in SVG canvas -->
<svg viewBox="0 0 800 400">
  <g transform="translate(50, 50)">
    INLINE_GROUP_OUTPUT
  </g>
</svg>

See docs/integration-arch-diagram.md for complete examples with CSS styling, multi-cloud layouts, and vendor color conventions.

Semantic Search

Add [semantic] extra to enable the 4th search tier. Useful for vague queries ("that thing for serverless") where keyword matching falls short:

uvx --with 'tech-icons[semantic]' tech-icons

🔬 Development

# Clone and set up
git clone https://github.com/zhiweio/tech-icons.git
cd tech-icons
uv sync --group dev

# Run tests
uv run pytest tests/ -v

# Lint + type check
uv run ruff check tech_icons/ tests/
uv run mypy tech_icons/

# Format
uv run ruff format tech_icons/ tests/

# All checks (format + lint + typecheck + test)
make all

Project Structure

tech-icons-abilities/
├── tech_icons/                # Main package
│   ├── server.py              # FastMCP server + CLI (main entry point)
│   ├── search.py              # 4-tier search engine
│   ├── formats.py             # 6 SVG output format adapters
│   ├── concepts.py            # Cross-vendor concept registry
│   ├── normalize.py           # SVG normalization & catalog generation
│   ├── _paths.py              # Runtime path resolution (importlib.resources)
│   ├── web/
│   │   ├── app.py             # FastAPI HTTP API
│   │   └── static/            # SPA frontend (index.html + assets)
│   ├── bridges/
│   │   └── ppt_master.py      # ppt-master icon export bridge
│   ├── catalog/               # Pre-built data files (bundled in wheel)
│   │   ├── icons.json         # 3,140+ entries with full metadata
│   │   ├── keyword_index.json # Inverted keyword index
│   │   ├── embeddings.npz     # Sentence embeddings (optional)
│   │   ├── embedding_ids.json # Embedding-to-ID mapping
│   │   └── enrichments.yaml   # Cross-vendor concept definitions
│   └── icons/                 # Bundled SVG files (~3,140 files)
├── tests/                     # pytest test suite (258+ tests)
├── scripts/
│   ├── build_catalog.py       # Catalog build pipeline
│   └── normalize_icons.py     # SVG normalization script
├── docs/                      # Documentation, screenshots
├── pyproject.toml             # Build config, dependencies, tooling
├── Makefile                   # Development task runner
└── README.md                  # This file

Running Tests

uv run pytest tests/ -v          # All tests
uv run pytest tests/test_server.py -v  # Server-specific
uv run pytest tests/ -v --cov   # With coverage

Tooling

Formatter: ruff (line-length: 120)
Linter: ruff (E, W, F, I, N, UP, B, A, S, T20, RUF)
Type checker: mypy (disallow-untyped-defs)
Test runner: pytest + pytest-asyncio (asyncio_mode=auto)

❓ FAQ

Q: Do I need to build the catalog locally? A: No. icons.json and SVGs are bundled in the wheel. uvx tech-icons works immediately.

Q: How is this different from the AWS/Azure/GCP icon libraries? A: tech-icons aggregates icons from 6 vendors into a single, searchable MCP server with consistent IDs and a cross-vendor concept system. Instead of hunting through multiple icon sets, you ask the LLM and it retrieves the right icon.

Q: Can I use this without an MCP client? A: Yes. Use --web for a browser UI, --transport http for a REST-ish API, or import SearchEngine directly in Python (from tech_icons import SearchEngine).

Q: Does semantic search require GPU? A: No. The default all-MiniLM-L6-v2 model runs on CPU. Embeddings are precomputed—only the query vector is generated at runtime.

Q: Can I add my own icons or vendors? A: Yes. Put SVG files under assets/your-vendor-*, update tech_icons/normalize.py with a collector function, then run scripts/build_catalog.py. See Development above.

Q: What MCP protocol version does this support? A: FastMCP 3.4 supports MCP protocol version 2025-03-26. All transports (stdio, Streamable HTTP) use this protocol.

🏅 Icon Sources & Attributions

tech-icons aggregates icons from the following sources. The project itself (server, search engine, tooling) is MIT-licensed, but the bundled icon files retain their original licenses and terms. Please review each source's license before redistributing or modifying the icons.

Source	Vendor(s)	License / Terms	Notes
AWS Architecture Icons	`aws`	AWS Terms of Service	Free to use for architecture diagrams.
Azure Architecture Icons	`azure`	Microsoft Terms	Free to use for architecture diagrams.
Google Cloud Icons	`gcp`	Google Cloud Brand Guidelines	Free to use for architecture diagrams.
Microsoft 365 Architecture Icons	`microsoft` (365)	Microsoft Terms
Dynamics 365 Icons	`microsoft` (dynamics-365)	Microsoft Terms
Microsoft Entra Architecture Icons	`microsoft` (entra)	Microsoft Terms
Microsoft Fabric Icons	`microsoft` (fabric)	Microsoft Terms
Power Platform Icons	`microsoft` (power-platform)	Microsoft Terms
CNCF Artwork	`cncf`	CNCF Trademark & Logo Guidelines	Trademarks owned by CNCF and respective projects.
Devicon	`devicon`	MIT License	Icon fonts and SVGs for software technologies.
Developer Icons	`developer`	MIT License	Flat, colored technology icons.
mingrammer/diagrams	`alibabacloud`, `digitalocean`, `elastic`, `firebase`, `generic`, `gis`, `ibm`, `kubernetes`, `oci`, `onprem`, `openstack`, `outscale`, `programming`, `saas`	MIT License	PNG icons from the Python diagrams library (also supplements `aws`, `azure`, `gcp` with PNG variants).

Note: This project does not claim ownership of any bundled icon files. The icons are provided as-is from their respective upstream sources for convenience in AI-assisted diagramming workflows. The MIT license of this project applies to the server code, search engine, tooling, and documentation — not to the third-party icon assets.

📄 License

Project code (server, search engine, tooling, docs): MIT © zhiweio

Bundled icons: Each icon set retains its original license and terms as listed in Icon Sources & Attributions.

Available Tools

7 tools

compare_iconsA

Get all vendor icons for a concept (e.g., 'kubernetes' returns the K8s icon from AWS, Azure, and GCP).

Use list_concepts first to discover names.

ParametersJSON Schema

Name	Required	Description	Default
`concept`	Yes	Concept group name (e.g., kubernetes, serverless)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden; it clearly indicates a read operation returning multiple items. Although minimal, it is sufficient for this simple 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?

Only two sentences: first states purpose with example, second provides usage tip. No redundancy or fluff.

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

Completeness5/5

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

For a single-parameter tool with an output schema and clear prerequisite, the description covers everything needed for correct invocation.

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 already describes 'concept' as 'Concept group name'. The description adds an example but no additional semantic value beyond what the schema provides, so baseline 3 is appropriate.

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 tool 'Get all vendor icons for a concept' and distinguishes from siblings like get_icon and search_icons by specifying cross-vendor comparison with an example (kubernetes).

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?

Provides explicit prerequisite instruction to 'Use list_concepts first', guiding the agent on proper sequencing, though it doesn't mention when not to use or compare directly to alternatives.

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

get_iconA

Get full details for a specific icon by its canonical ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Icon ID (e.g., aws/compute/lambda)

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description must disclose traits. It only says 'Get full details' without specifying what details are included, whether it's read-only, or any side effects. Minimal disclosure beyond basic operation.

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?

Single sentence, front-loaded with verb and resource, no extraneous information. Highly concise.

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 simple tool with one parameter and output schema, description is adequate but could be improved by mentioning that it returns icon metadata (e.g., name, vendor, category). Output schema partially compensates.

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 coverage is 100% and already describes the id parameter with an example. The description adds 'by its canonical ID' which reinforces meaning but does not add significant new semantics beyond 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?

Description clearly states verb 'Get', resource 'full details for a specific icon', and constraint 'by its canonical ID'. It effectively distinguishes from siblings like compare_icons, list_*, 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 Guidelines4/5

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

The description implies usage when you have a specific icon ID and need details, but does not explicitly state when not to use or suggest alternatives. The context from sibling names aids differentiation.

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

get_icon_imageB

Get icon image content in a specified format and image type (SVG or PNG).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Icon ID (e.g., aws/compute/lambda)
`format`	No	Output format	raw
`image_type`	No	Image format to serve (svg or png, default: svg). Falls back to available format.	svg

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, or side effects. It only restates the parameters.

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 sentence, concise, and front-loaded with the verb 'Get'. Every word is necessary and no filler.

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?

With no output schema, the description should explain return values (e.g., what each format returns). It does not mention the return type, error conditions, or behavior when format is 'download'. Incomplete for a 3-parameter tool.

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 coverage is 100% so baseline is 3. The description adds minimal context by naming the image types (SVG, PNG), which is also implied by the schema's enum. No additional meaning beyond 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 uses a specific verb 'Get' with a clear target 'icon image content' and mentions the two image types (SVG or PNG). It differentiates from sibling tools like get_icon (likely returns metadata) and compare_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?

No guidance on when to use this tool versus alternatives. For example, it does not clarify when to use format vs image_type or how it differs from get_icon.

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

list_categoriesB

List all available icon categories, optionally filtered by vendor.

ParametersJSON Schema

Name	Required	Description	Default
`vendor`	No	Filter by vendor

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No behavioral details beyond basic listing. No disclosure of read-only nature, output format, or filtering semantics. With no annotations, this is insufficient.

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?

Extremely concise single sentence that conveys the core functionality. No wasted words.

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?

For a simple listing tool with one optional parameter and an output schema, the description is sufficient. Minor omission: doesn't state default behavior when no vendor filter is applied.

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's mention of filtering echoes the schema's parameter description. With 100% schema coverage, no additional semantic value is added.

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?

Clearly states the action (list) and the resource (icon categories), and mentions optional filtering by vendor. Differentiates from sibling tools like list_vendors and list_concepts.

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 vs siblings such as list_concepts or list_vendors. The description only states functionality without contextual usage.

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

list_conceptsA

List all cross-vendor concept group names (e.g., kubernetes, serverless, object-storage).

Use compare_icons to retrieve the icons in a group.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations and minimal description. Does not disclose side effects, pagination, or ordering. However, output schema may cover return structure.

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?

Two sentences, front-loaded with purpose, no filler words. Efficient and clear.

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 zero parameters and existing output schema, description is sufficient but could mention ordering or uniqueness for completeness.

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?

No parameters, so description adds meaning by stating it lists concept group names, which is appropriate baseline for zero parameters.

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?

Clearly states 'List all cross-vendor concept group names' with examples like kubernetes, serverless. Distinct from siblings by directing to compare_icons for icons.

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?

Explicitly says to use compare_icons for icons, implying this tool only lists names. Does not detail when not to use, but context from siblings provides some guidance.

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

list_vendorsA

List all vendors with their icon counts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are present, so the description must disclose behavior. It implies read-only ('list') but does not mention if there are limits, pagination, or ordering. For a simple parameterless tool, this is minimally adequate but lacks depth.

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 superfluous words. It is front-loaded and efficient.

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

Completeness5/5

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

For a tool with zero parameters and an output schema (present), the description is complete—it specifies what is listed and that counts are included. No additional context seems necessary.

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 schema has no parameters; the description adds 'with their icon counts,' which clarifies what the response includes beyond the empty schema. Baseline for zero parameters is 4.

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 action ('List all vendors') and what is included ('with their icon counts'), distinguishing it from sibling tools like list_categories and list_concepts.

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 alternatives (e.g., search_icons) or any prerequisites. The description is too brief to provide usage context.

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

search_iconsA

Search cloud tech icons by query. Supports exact ID, keyword, fuzzy, and semantic matching.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return (default 10)
`query`	Yes	Search query (name, ID, or description)
`vendor`	No	Filter by vendor: aws, azure, gcp, microsoft, cncf, devicon, developer
`category`	No	Filter by category (e.g., compute, databases)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description carries full transparency burden. It discloses support for multiple search modes (exact, keyword, fuzzy, semantic), adding value beyond schema. However, it does not mention pagination, rate limits, or result handling.

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?

Two very concise sentences with no fluff. Key information (verb, resource, search modes) is front-loaded. Every word earns its place.

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 output schema existence and 4 parameters, the description is adequate but incomplete. It misses guidance on when to use this vs siblings like get_icon or list_categories, and lacks details on sorting or default behavior. Still functional.

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?

Schema descriptions cover all parameters (100% coverage). The description adds context by specifying matching types, enhancing the query parameter's meaning. Does not detail other parameters beyond schema, but the added value justifies above-baseline score.

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?

Description clearly states the tool's function: 'Search cloud tech icons by query.' It specifies supported matching types (exact ID, keyword, fuzzy, semantic), distinguishing it from siblings like get_icon (single icon) and compare_icons (comparison).

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?

No explicit when-to-use or when-not-to-use guidance. Usage is implied via search capabilities, but no mention of alternatives like get_icon for exact ID or list_categories for browsing. The description lacks context for choosing this tool over siblings.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: listing vendors, categories, concepts, searching, getting icon details, getting icon images, and comparing icons across vendors. There is no ambiguity or overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_vendors, get_icon, search_icons). The naming is predictable and uniform.

Tool Count5/5

Seven tools is appropriate for a read-only icon service. It covers discovery (list_*, search_icons), retrieval (get_icon, get_icon_image), and cross-vendor comparison (compare_icons) without being excessive or insufficient.

Completeness5/5

The tool surface fully supports browsing and retrieval of cloud tech icons: vendors, categories, concepts, search, icon details, image downloads, and cross-vendor comparison. No obvious gaps for the domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

crowvault
io.github.rajeswaran140
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Developer Tools CI/CD & DevOps
2
infyicon-mcp A
io.github.krupalghori44-dev
Search 161,000+ free hand-drawn icons and fetch ready-to-embed SVG or PNG from any MCP client.
Design Tools Developer Tools
81
MCP Toplist A
com.mcptoplist
Search 77,000+ MCP servers ranked by real adoption data to find the right one for any task.
Search Developer Tools
23
CostPilot
com.mcpgatepro
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Cloud Platforms Finance Monitoring
1

Related MCP Servers

PickAPIcon MCP
Art & Culture Search Developer Tools
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.
Updated a year ago (2025-05-26 02:36 UTC)
3
30
4
MIT
diagram-ai-generator
Software Architecture AI & Machine Learning
carlosmgv02
A
license
Not graded
quality
C
maintenance
Professional AI-powered architecture diagram generator with multi-cloud support and MCP server integration. Generates beautiful, accurate diagrams with provider-specific icons for AWS, Azure, GCP, Kubernetes, and more.
Updated a year ago (2025-10-02 16:32 UTC)
10
MIT
mcp-icon
Design Tools Search
hustcc
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server for semantic SVG icon search. Generate infographic SVG icons by keyword — over 100,000 icons with semantic search support.
Updated 6 months ago (2026-02-26 01:37 UTC)
1
20
MIT
archdiagram
Software Architecture Developer Tools
bharathgnana
A
license
Not graded
quality
A
maintenance
MCP server for generating architecture diagrams with official vendor icons from natural language descriptions. Provides tools to validate specs, render diagrams, search icon catalog, and list available services.
Updated 2 months ago (2026-07-01 02:52 UTC)
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zhiweio/tech-icons'

If you have feedback or need assistance with the MCP directory API, please join our Discord server