Skip to main content
Glama
chacebot

MCP Icon Generator

by chacebot
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

MCP Icon Generator

An MCP (Model Context Protocol) server that provides tools for generating app icons with custom text, colors, and sizes.

Installation

Clone this repository:

git clone https://github.com/chacebot/mcp-icon-generator.git
cd mcp-icon-generator
npm install

For PNG generation (recommended), install Sharp:

npm install sharp

Related MCP server: Web Icons Generator CLI MCP

Features

This server provides the following tools for icon generation:

  • generate_app_icon - Generate a single app icon image with custom text and colors

  • generate_ios_app_icon_set - Generate a complete iOS AppIcon.appiconset with all required sizes

Quick Start

  1. Install dependencies:

    npm install
npm install sharp  # Optional but recommended for PNG generation

  2. Configure your MCP client (Claude Desktop, Cursor, etc.):

    {
  "mcpServers": {
    "icon-generator": {
      "command": "node",
      "args": ["/path/to/mcp-icon-generator/src/index.js"]
    }
  }
}

Tools

generate_app_icon

Generate a single app icon image with customizable properties.

Parameters:

  • text (required): Text to display on the icon (e.g., "K" for Kanban)

  • outputPath (required): Full path where the icon PNG file should be saved

  • size (optional): Icon size in pixels (default: 1024)

  • backgroundColor (optional): Background color in hex format (default: "#FFFFFF")

  • textColor (optional): Text color in hex format (default: "#000000")

  • fontSize (optional): Font size as a percentage of icon size, 0.0-1.0 (default: 0.7)

  • fontFamily (optional): Font family name (uses system default if not specified)

Example:

{
  "text": "K",
  "outputPath": "/path/to/icon.png",
  "size": 1024,
  "backgroundColor": "#FFFFFF",
  "textColor": "#000000",
  "fontSize": 0.7
}

generate_ios_app_icon_set

Generate a complete iOS AppIcon.appiconset directory with all required icon sizes and Contents.json.

Parameters:

  • text (required): Text to display on the icon

  • appiconsetPath (required): Path to the AppIcon.appiconset directory

  • backgroundColor (optional): Background color in hex format (default: "#FFFFFF")

  • textColor (optional): Text color in hex format (default: "#000000")

  • fontSize (optional): Font size as a percentage (default: 0.7)

Example:

{
  "text": "K",
  "appiconsetPath": "/path/to/AppIcon.appiconset",
  "backgroundColor": "#FFFFFF",
  "textColor": "#000000"
}

Output Formats

  • With Sharp installed: Generates PNG files directly

  • Without Sharp: Generates SVG files (can be converted to PNG with external tools)

Use Cases

  • Generate app icons for iOS/Android apps

  • Create placeholder icons during development

  • Generate branded icons with custom text

  • Batch generate icons for multiple apps

License

MIT

Available Tools

2 tools
generate_app_iconC

Generate an app icon image with custom text, colors, and size

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoIcon size in pixels (default: 1024)
textYesText to display on the icon (e.g., 'K' for Kanban)
fontSizeNoFont size as a percentage of icon size (0.0-1.0, default: 0.7)
textColorNoText color in hex format (e.g., '#000000' for black, default: '#000000')#000000
fontFamilyNoFont family name (optional, uses system default if not specified)
outputPathYesFull path where the icon PNG file should be saved
backgroundColorNoBackground color in hex format (e.g., '#FFFFFF' for white, default: '#FFFFFF')#FFFFFF

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 only says 'generate' without revealing that the tool writes a file to outputPath, whether it overwrites existing files, or what the output/return behavior is. This is a significant transparency gap for a tool that performs a file-side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. It is front-loaded with the core purpose, though it could arguably add a bit more detail without becoming verbose.

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 7 parameters, no output schema, and no annotations, the description is too minimal to be fully contextual. It omits behavioral details like file saving, overwrite behavior, or any guidance on output, leaving significant gaps for an agent to infer.

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%, providing full meaning for all 7 parameters. The description adds only a high-level mention of text, colors, and size, which overlaps with schema. Baseline 3 is appropriate since the schema already 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 tool generates an app icon image with custom text, colors, and size, using a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool generate_ios_app_icon_set, so it lacks explicit sibling differentiation.

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 generate_ios_app_icon_set, nor does it mention any context, prerequisites, or exclusions. It simply states what the tool does without indicating appropriate use cases.

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

generate_ios_app_icon_setC

Generate a complete iOS AppIcon.appiconset with all required sizes from a single source icon

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText to display on the icon
fontSizeNoFont size as a percentage (default: 0.7)
textColorNoText color in hex format (default: '#000000')#000000
appiconsetPathYesPath to the AppIcon.appiconset directory
backgroundColorNoBackground color in hex format (default: '#FFFFFF')#FFFFFF

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose side effects. It states the output (a complete AppIcon set) but does not mention whether it creates or overwrites files in 'appiconsetPath', what dependencies exist, or how the text/color parameters relate to the claimed 'source icon'. This leaves important behavior undisclosed.

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, front-loaded sentence with no filler. It efficiently communicates the high-level purpose in minimal words, making it easy to scan. The minor inaccuracy in 'source icon' is a semantic issue, not a structure or conciseness issue.

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's complexity (5 parameters, side-effectful file writing), no annotations, and no output schema, the description is too short to be complete. It lacks crucial context about the target directory behavior, when to use this instead of the sibling, and how the text parameters map to the generated icon.

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 has 100% description coverage for all parameters, so the baseline is 3. The tool description adds no parameter-level details beyond that, and the mention of 'single source icon' does not match any parameter in the schema, so it provides no additional semantic value.

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 identifies the action ('Generate') and the specific deliverable ('a complete iOS AppIcon.appiconset with all required sizes'). It implicitly distinguishes itself from the sibling by emphasizing completeness, but the phrase 'from a single source icon' is confusing because the schema only contains text and color parameters, not an icon file.

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?

There is no guidance about when to use this tool versus the sibling tool 'generate_app_icon', nor any mention of prerequisites, alternatives, or exclusions. The description only states what it does, not when to choose it.

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

B3.2/5.0
Disambiguation5/5

The two tools are clearly distinct: generate_app_icon creates a single custom icon, while generate_ios_app_icon_set produces a complete iOS icon set from an existing source icon. There is no functional overlap; each serves a different stage in the icon creation workflow.

Naming Consistency5/5

Both tools follow a consistent 'generate_' prefix with a descriptive object ('app_icon', 'ios_app_icon_set'). This creates a predictable and recognizable naming pattern that aligns with common MCP server conventions.

Tool Count3/5

With only two tools, the server feels lightweight and minimally scoped. While the pair covers a specific workflow (single icon generation then iOS set creation), the count is at the lower boundary of what is reasonable and may be insufficient for broader icon generation needs.

Completeness2/5

The server name 'MCP Icon Generator' suggests a general-purpose icon generation tool, yet it only supports iOS icon sets. There is no Android, web favicon, or other platform support, and no functionality to resize or convert existing icons beyond the iOS set. This leaves significant gaps for a generic icon generator.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/chacebot/mcp-icon-generator'

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