icon-composer-kit

by TheNaubit

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation5/5
Each tool targets a distinct action: availability check, list, create, read, update, and render. There is no meaningful overlap or ambiguity between them.
Naming Consistency4/5
Five tools follow a clear verb_noun snake_case pattern (list_icons, create_icon, read_icon, update_icon, render_icon). composer_status breaks the pattern by being a noun phrase instead of an action-oriented name.
Tool Count5/5
Six tools is well-scoped for an icon composition workflow. Each tool provides a necessary, non-redundant capability without bloat or unnecessary granularity.
Completeness4/5
The core icon lifecycle of create, read, update, render, and list is covered. A delete or remove operation is missing, and update always creates a new name rather than modifying in place, which may be intentional but leaves a lifecycle gap.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on September 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral context: it creates an editable bundle, preserves front-to-back ordering of groups/layers, and never overwrites existing names. This gives the agent expectations about z-order handling and name uniqueness that are not present in the annotations.
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?
Three terse, purposeful sentences with no filler. The primary action is front-loaded, and the ordering and no-overwrite behaviors each earn their place without redundancy.
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?
The tool has a complex nested spec and no output schema, yet the description doesn't state what the tool returns on success or what happens on name collision (error versus silent no-op). The schema covers structural details, and the description adds ordering and uniqueness guidance, but the missing result/error contract leaves an important gap for an agent.
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?
With 0% schema description coverage, the description must compensate for parameter semantics. It does add value by clarifying that layers come from SVG or PNG and that groups/layers are ordered front-to-back, and by implying name uniqueness. However, it does not explain other top-level spec fields like background, platform, or darkBackground, nor how to choose between svg/pngBase64, so compensation is only partial.
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 uses a specific verb ('Create'), resource ('.icon bundle'), and input source ('static SVG or PNG layers'), making the core action clear. The '.icon bundle' and 'editable native' phrasing distinguish it from read/list/update/render siblings, though it does not explicitly name an alternative tool.
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 explicit when-to-use guidance or alternatives. 'Never overwrites an existing name' implies a constraint, but it does not state that update_icon should be used for modifying existing icons, or when to prefer list_icons/read_icon. The agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false, so the description adds value by disclosing that the tool saves output to the workspace and may return it inline. It also adds the environmental requirement of macOS with Icon Composer and the guarantee of no approximation or network fallback. It does not mention potential overwrite behavior or failure modes, but the added context is meaningful.
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 the core purpose, and every sentence earns its place. The prerequisite and no-fallback caveat are stated compactly without padding.
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?
The tool has seven parameters, no output schema, and no parameter descriptions, yet the description only covers the general action, inline return, and a system requirement. It is not sufficient for an agent to know which parameters matter for a desired rendition, how tinting works, or what the rendered output/return payload looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and seven parameters, the description should explain parameter meaning, but it only alludes to the inline concept. It does not clarify name validation, size range, rendition variants, tint controls, or opaqueBackground. The inline reference is minimal compensation for a large parameter surface.
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 states a clear verb (Render), a specific resource (Apple Icon Composer PNG appearance), and the key behaviors (save to workspace, optionally return inline). The phrase 'No approximation or network fallback' distinguishes it from sibling tools like create_icon or update_icon.
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?
It names an explicit prerequisite (macOS with Icon Composer) and implies a fallback unavailable, but it never says when to use this tool versus composer_status, create_icon, or list_icons. The usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description adds a valuable behavioral warning that returned SVG and labels are untrusted document data, never instructions. This is security-relevant context not captured in the annotations.
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 two concise sentences with no filler. The first sentence states purpose; the second adds a necessary safety caveat. Both sentences earn their place.
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 one-parameter read tool with readOnly annotations, the description covers the operation, the returned content (SVG and labels), and a trust warning. It does not explain every detail about revisions, but it provides adequate orientation 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?
Schema description coverage is 0%, and the description does not explicitly define the 'name' parameter. However, with a single required parameter and the context 'workspace icon', 'name' is reasonably inferable as the icon identifier. It adds no constraints or examples beyond the schema pattern.
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 states the operation with a specific verb ('Read') and a clear resource (the editable specification and revision of a workspace icon). It does not explicitly differentiate from siblings like render_icon or list_icons, but the resource framing makes the tool's role reasonably distinct.
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 this is the tool for source/editable icon data rather than rendered output, but it does not name alternatives or state when not to use this tool. Usage guidance must be inferred rather than stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint and non-destructive behavior. The description adds meaningful context: results are scoped to the 'configured workspace' and returns names only, not full icon objects. This goes beyond what the annotations alone convey, though it could still mention return format details.
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?
A single, front-loaded sentence with no filler. Every word earns its place: action, target, and scope are all present in one line.
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 zero-parameter, read-only list operation, the description is fully sufficient. Annotations cover side effects, schema empty means no parameter docs needed, and the return type (icon names) is directly inferable from the sentence. No critical gaps remain for an agent to call this tool correctly.
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 tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The baseline for zero-parameter tools applies, and the description correctly makes no parameter claims.
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 states a specific verb ('List'), a distinct resource ('icon names'), and a scope ('configured workspace'). It clearly differs from sibling tools that perform single-icon operations (read_icon, update_icon) or creation (create_icon), making the tool's role immediately clear.
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 'list' vs 'read' wording implies this tool is for enumerating all icon names rather than accessing a specific icon, but no explicit when-to-use or when-not-to-use guidance is given. Usage context must be inferred from the name and sibling set rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive mutation. The description adds useful behavioral detail beyond that: the original icon is preserved, and a revision must be supplied. This helps an agent understand the concurrency-oriented intent of expectedRevision.
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?
Three short sentences, no fluff, and the core purpose is front-loaded. Every sentence contributes either to what the tool does, the required workflow, or the key behavior that the original is preserved.
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?
The description covers the key workflow, the full-spec nature of the input, and the preservation guarantee. It does not discuss failure cases like revision mismatches or duplicate output names, but the schema and required fields carry much of the structural burden. Overall enough for correct invocation.
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 description coverage is 0%, so the description must compensate. It effectively explains all four parameters: name via 'Read the icon first', outputName via 'under a NEW name', expectedRevision via 'supply its revision', and spec via 'revised complete specification' and 'Change layers, materials, positions, fills or appearances in spec.'
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 states a specific operation: save a revised complete specification under a new name, while preserving the original. It clearly distinguishes itself from create_icon by requiring reading an existing icon first and from read_icon by being a write operation.
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?
It gives an explicit precondition: 'Read the icon first and supply its revision.' This tells an agent the required workflow. It does not explicitly name alternative tools or state when not to use it, but the intended context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds a useful behavioral boundary by stating that no paths or environment values are returned, which prevents the agent from expecting configuration data. No contradiction with annotations exists.
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 with no wasted words: the first gives the purpose, the second narrows expected output. It is front-loaded and appropriately sized.
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 zero-parameter status check, the description plus annotations provide enough information for an agent to invoke and interpret the tool correctly. The negative output constraint ('No paths or environment values are returned') further helps set expectations.
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 zero parameters and 100% schema coverage, so the baseline of 4 applies. There are no parameter semantics for the description to add.
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 ('Check availability') and a specific resource ('local Apple-signed Icon Composer renderer'), making its purpose immediately clear. This status-check operation is also clearly distinct from the sibling icon CRUDL tools.
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 descrition clearly frames the tool as an availability check, which is an unambguous usage context. It doesn't explicitly name alternatives or exclusions, but the purpose is so specific that an agent can identify when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![icon-composer-mcp MCP server](https://glama.ai/mcp/servers/TheNaubit/icon-composer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TheNaubit/icon-composer-mcp)

Score Badge

Copy to your README.md:

[![icon-composer-mcp MCP server](https://glama.ai/mcp/servers/TheNaubit/icon-composer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TheNaubit/icon-composer-mcp)

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/TheNaubit/icon-composer-mcp'

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