Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@icon-mcp-server generate a 512px gradient app icon with the letter 'G' on a rounded square"
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.
中文名称：图标生成 MCP 服务 English name：icon-mcp-server 分类 / Category：开发者工具 / Developer Tools · 图像生成 / Image Generation
A Model Context Protocol (MCP) server that generates software / app icons locally with Pillow — no external API, no network calls, no keys required.
一个基于 Pillow 的本地 MCP 服务，用于生成软件 / 应用图标（PNG / ICO / ICNS）。 无需外部 API、无需联网、无需密钥。
Renders PNG / ICO / ICNS files with gradients, shapes, borders, drop shadows, and centered text or emoji — perfect for quickly bootstrapping app icons, favicons, tray icons, or placeholder assets.
推荐使用 uvx 拉起（无需预装，自动创建临时环境）：
{
"mcpServers": {
"icon-generator": {
"command": "uvx",
"args": ["icon-mcp-server"]
}
}
}环境变量 / Environment variables：无需（本服务完全离线运行，不依赖任何 API Key）。
托管部署兼容性 / Hosted deployment：
完全支持魔搭 MCP 广场「可托管部署」模式（Hosted / SSE）。
在托管模式下，generate_icon 和 generate_icon_set 会写入服务器磁盘，用户无法直接下载文件。
托管模式推荐使用 generate_icon_base64 工具，它直接返回 base64 编码的 PNG（客户端可渲染 data:image/png;base64,... URL）。
本地部署（stdio）时，全部 4 个工具都能正常使用。
Related MCP server: Toolkits MCP
Tool | Purpose | 用途 |
| Discover available styles, shapes, and default palette | 查询可用样式、形状与默认调色板 |
| Render a single PNG / ICO / ICNS file to disk | 渲染单个 PNG / ICO / ICNS 文件到磁盘 |
| Render a multi-size PNG set + aggregated Windows | 渲染多尺寸 PNG 集 + 聚合 Windows |
| Render and return inline base64 PNG (no disk write) | 渲染并返回内嵌 base64 PNG（不写盘，适合托管模式） |
5 visual styles: gradient, solid, outlined, shape, mono
6 silhouette shapes: circle, square, rounded, triangle, hexagon, diamond
Multi-resolution output: single PNG, full PNG set, or aggregated Windows .ico
Optional .icns for macOS bundles
4× supersampling + LANCZOS downscale → crisp results even at 16 px
Base64 preview mode for MCP clients that cannot read local files
Zero external services — everything runs offline via Pillow
pip install icon-mcp-serverOr run without installing / 或免安装运行：
pipx run icon-mcp-server以下配置与顶部「服务配置」章节等效，供不同客户端场景选择。如果你正在把本服务提交给魔搭 MCP 广场，请使用顶部的 uvx 配置。
pip install 后（console script 在 PATH 上）{
"mcpServers": {
"icon-generator": {
"command": "icon-mcp-server",
"args": []
}
}
}{
"mcpServers": {
"icon-generator": {
"command": "python",
"args": ["-m", "icon_mcp_server"]
}
}
}Param | Type | Default | Notes |
| str |
| Centered label / initials / single emoji |
| enum |
|
|
| enum |
|
|
| int (px) |
| Clamped to 16..2048 |
| color |
| Text / silhouette color |
| color |
| Background or gradient start |
| color / null |
| Gradient end (ignored when null) |
| float (deg) |
|
|
| float |
| Text height as fraction of icon size |
| float |
| Only for |
| float |
| Stroke width as fraction of size |
| color |
| Stroke color |
| bool |
| Soft drop shadow behind silhouette |
// generate_icon
{
"out_path": "./out/app.png",
"text": "Q",
"style": "gradient",
"shape": "rounded",
"bg_color": "#4F8DFD",
"bg_color_2": "#8E5BFF",
"gradient_angle": 135,
"size": 512
}// generate_icon_set → writes app_16.png … app_512.png + app.ico
{
"out_dir": "./dist/icons",
"base_name": "app",
"text": "A",
"style": "solid",
"shape": "circle",
"bg_color": "#FF7043",
"include_ico": true,
"png_sizes": [16, 32, 48, 64, 128, 256, 512]
}git clone <your-fork-url> icon-mcp-server
cd icon-mcp-server
python -m venv .venv
# Windows PowerShell:
.venv\Scripts\Activate.ps1
# macOS / Linux:
# source .venv/bin/activate
pip install -e ".[dev]"
icon-mcp-server --self-test # renders samples into ./_icon_self_test
python -m icon_mcp_server --versionOne-time setup:
pip install --upgrade build twineBuild & upload:
# 1. Bump version in pyproject.toml (and src/icon_mcp_server/__init__.py)
# 2. Clean previous artifacts
rmdir /s /q dist 2>nul || rm -rf dist
# 3. Build sdist + wheel
python -m build
# 4. Validate
twine check dist/*
# 5. Upload to TestPyPI first (recommended)
twine upload --repository testpypi dist/*
# 6. Smoke-test install from TestPyPI
pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ icon-mcp-server
icon-mcp-server --self-test
# 7. Publish to real PyPI
twine upload dist/*twineAPI token (recommended): set TWINE_USERNAME=__token__ and
TWINE_PASSWORD=<your-pypi-token>, or configure ~/.pypirc:
[distutils]
index-servers = pypi, testpypi
[pypi]
username = __token__
password = pypi-xxxxxxxxxxxxxxxxxxxxxxxx
[testpypi]
repository = https://test.pypi.org/legacy/
username = __token__
password = pypi-xxxxxxxxxxxxxxxxxxxxxxxxTrusted Publisher (OIDC) — no token needed. Configure it in the PyPI
project settings and publish from a GitHub Actions workflow using
pypa/gh-action-pypi-publish.
MIT — see LICENSE.
Render a single icon and save it to out_path.
out_path : str
Destination file path. Extension determines the format unless fmt is given.
Supported extensions: .png (default), .ico, .icns.
text : str
Short label drawn in the center (initials, single glyph, or emoji).
style : str
One of gradient / solid / outlined / shape / mono.
size : int
Edge length in pixels, 16..2048.
shape : str
One of circle / square / rounded / triangle / hexagon / diamond.
fg_color, bg_color, bg_color_2, border_color : str
CSS-like color strings (#RRGGBB or named colors).
gradient_angle : float
Gradient direction in degrees (0 = left→right, 90 = top→bottom).
font_scale : float
Text height as fraction of the icon size (0.05..1.2).
corner_radius : float
Corner radius fraction for shape='rounded' (0..0.5).
border_width : float
Stroke width as a fraction of the icon size (0..0.15).
shadow : bool
Add a soft drop shadow behind the icon silhouette.
fmt : str, optional
Force output format (png / ico / icns).
| Name | Required | Description | Default |
|---|---|---|---|
| fmt | No | ||
| size | No | ||
| text | No | ||
| shape | No | rounded | |
| style | No | gradient | |
| shadow | No | ||
| bg_color | No | #4F8DFD | |
| fg_color | No | #FFFFFF | |
| out_path | Yes | ||
| bg_color_2 | No | #8E5BFF | |
| font_scale | No | ||
| border_color | No | #FFFFFF | |
| border_width | No | ||
| corner_radius | No | ||
| gradient_angle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains the output side effect, extension/format resolution, and parameter effects. However, it does not disclose overwrite behavior, return value, or error behavior, so transparency is partial rather than complete.
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 one-sentence purpose is front-loaded, and the remaining space is a dense, well-organized parameter list. For 15 parameters, every line adds needed information and there is no filler.
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?
The description is nearly complete for a complex 15-parameter tool with no output schema: it covers all parameter semantics, defaults, ranges, and output formats. It only misses a few contextual details such as overwrite behavior, return value, and explicit guidance on choosing among sibling tools.
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 0%, and the description fully compensates: every parameter has meaningful semantics, including enum values for style and shape, numeric ranges for size/font_scale/corner_radius/border_width, color syntax, gradient-angle orientation, and fmt override behavior.
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 opening sentence names a specific action and resource: 'Render a single icon and save it to out_path.' The qualifier 'single' and the file destination clearly separate it from generate_icon_set and generate_icon_base64, so an agent can identify the tool without inspecting the schema.
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?
There is no explicit mention of sibling tools or when-not-to-use conditions. However, the phrasing 'single icon' and 'save it to out_path' implies the file-based single-icon use case, which gives some routing guidance by contrast with the base64 and icon-set siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an icon and return it as a base64-encoded PNG string (no disk write).
Useful for previews inside MCP clients that cannot read local files.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| text | No | ||
| shape | No | rounded | |
| style | No | gradient | |
| shadow | No | ||
| bg_color | No | #4F8DFD | |
| fg_color | No | #FFFFFF | |
| bg_color_2 | No | #8E5BFF | |
| font_scale | No | ||
| border_color | No | #FFFFFF | |
| border_width | No | ||
| corner_radius | No | ||
| gradient_angle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait—no disk write—and the output format, which is valuable. However, it does not cover other behavioral aspects such as determinism, errors, or any hidden side effects.
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 two sentences with no filler. The core action and return format are front-loaded, followed by the practical use case. Every sentence earns its place.
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 13 parameters, no output schema, and no annotations, the description is not complete enough for confident use. It states the return type and use case, but lacks parameter semantics, error behavior, and explicit routing versus sibling tools.
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?
There are 13 parameters with 0% schema description coverage, and the description adds no parameter-level guidance. It never mentions size, colors, shape, style, or any of the many options, leaving the agent to guess from names and defaults alone.
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 uses a specific verb ('Render') and resource ('an icon'), states the return format as a base64-encoded PNG string, and explicitly notes 'no disk write', which distinguishes it from the sibling generate_icon tool. Even without naming the sibling, the no-disk-write qualifier clearly differentiates its purpose.
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?
It gives a clear context for use: 'previews inside MCP clients that cannot read local files.' This tells the agent when this variant is preferable, though it does not explicitly mention alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a multi-resolution icon set: several PNGs + an aggregated .ico.
The largest PNG is drawn once at high resolution and downscaled with LANCZOS for every other size, so all outputs share the same design.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | ||
| shape | No | rounded | |
| style | No | gradient | |
| shadow | No | ||
| out_dir | Yes | ||
| bg_color | No | #4F8DFD | |
| fg_color | No | #FFFFFF | |
| base_name | No | icon | |
| png_sizes | No | ||
| bg_color_2 | No | #8E5BFF | |
| font_scale | No | ||
| include_ico | No | ||
| border_color | No | #FFFFFF | |
| border_width | No | ||
| corner_radius | No | ||
| gradient_angle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the rendering process (high-res draw + LANCZOS downscaling) and that all outputs share the same design, which is useful. However, it doesn't mention side effects like file creation, overwrite behavior, or error handling, which are missing.
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 short and front-loaded with the main purpose. Each sentence adds value, but lacks detail on parameters. It is concise without verbosity, though the omission of parameter guidance is a structural gap.
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 16 parameters, no output schema, and no annotations, the description is incomplete. An agent cannot correctly call this tool without understanding parameter semantics, validation rules, or how outputs are generated. The description covers only the high-level rendering process.
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 0%, so the description must explain the 16 parameters. It does not mention any parameters at all, leaving the agent to infer from property names like 'text', 'shape', 'style'. This is insufficient for such a large parameter set.
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 states a clear action (render) and resource (multi-resolution icon set) and specifies outputs (PNGs + .ico). It distinguishes from siblings by focusing on the multi-resolution aspect, though it doesn't explicitly compare to generate_icon or generate_icon_base64.
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?
There is no guidance on when to use this tool versus generate_icon (single resolution) or generate_icon_base64 (base64 output). It implies a use case for multi-resolution but doesn't explicitly state alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the available styles, shapes, and default palette values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It clearly indicates a read-only 'Return' operation and names the content categories returned, which is transparent for a simple listing tool. However, it does not mention output format, ordering, or potential size, but these are not critical for a no-parameter list operation.
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 sentence with no filler. It front-loads the action ('Return') and immediately enumerates the concrete output categories, making every word informative.
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 no-parameter, informational listing tool without an output schema, the description adequately states what the agent will receive. It could additionally hint that these returned values are meant to be used with the sibling generate tools, but that is optional rather than necessary for a correct call.
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 tool has zero parameters)Skip so there is nothing for the description to clarify about inputs. The baseline for no-parameter tools is 4, and the description appropriately avoids inventing parameter details that do not exist.
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 uses a specific verb ('Return'), names the resource ('available styles, shapes, and default palette values'), and clearly indicates a listing operation that is distinct from the sibling generate tools. However, it does not explicitly differentiate itself from those siblings by name or state what it is not, so it falls just short of a 5.
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 gives no guidance on when to use this tool versus the sibling generation tools. There is no stated precondition, no 'use this before generating icons' context, and no exclusion of alternatives, so the agent must infer its role from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0generate_icongenerate_icon_base64generate_icon_setlist_icon_stylesScored across 4 tools
Most tools have clearly distinct purposes: listing styles, rendering to base64 for previews, rendering to a file, and rendering a multi-resolution set. generate_icon and generate_icon_base64 overlap conceptually (both render a single icon), but their output modes (file vs. base64 string) are distinct enough to avoid confusion.
All tool names follow a consistent snake_case verb_noun pattern (list_*, generate_*) with the target clearly indicated (styles, icon_base64, icon, icon_set). The compound names are descriptive and align with the underlying actions, making the naming predictable.
Four tools is well-scoped for an icon generation server: one for metadata/discovery, two for single-icon output variants, and one for multi-resolution sets. Each tool earns its place without redundancy or bloat.
The tool surface covers the full icon-generation workflow: discover available styles, preview as base64, save a single icon in multiple formats, and produce a full icon set. There are no obvious dead ends or missing operations for the stated purpose.
Generate PWA icon sets and iOS splash screens from a text prompt or an existing image.
Generate and vectorize clean, editable SVG graphics from text, images, or both.
Generate logos, social posts, app screenshots, comic panels & visual-novel assets from prompts.
AI-agent image generation: cohesive sets & illustrations. Resize a set or export icons, free.
