Custom transparent PNG icons in your project's style, added by your coding agent. Free starter set.
Scored across 4 tools
Each tool targets a distinct source+action: generate a new icon, edit an existing one, search the free catalogue, or search the user's own account history. The descriptions explicitly tell the agent when to pick edit_app_icon over generate_app_icon and find_my_icon over generate_app_icon, eliminating overlap.
All four names follow a strict verb_noun_icon pattern (edit_app_icon, find_free_icon, find_my_icon, generate_app_icon). No mixed conventions or vague verbs.
Four tools is a lean but well-scoped set for an icon generation service; each covers a genuinely different workflow (create, modify, browse free, browse owned). Slightly minimal since there is no delete or explicit list tool, but nothing feels redundant.
The core lifecycle — generate, edit, reuse from free catalogue, reuse from own history — is covered, and style management is handled via the CLAYCUT.md convention rather than a tool. Minor gaps: no delete/manage operation for owned icons and no explicit 'list all icons' beyond find_my_icon's recent fallback.
Change one thing about an icon that is almost right, keeping everything else as it is. Needs a paid Claycut key and costs one icon. Returns a download URL for the edited transparent PNG.
Use it instead of generate_app_icon when the user likes an icon but wants a detail fixed: a new generation redraws the whole object and loses what they liked. Pass the icon's URL (a Claycut asset URL, or any public PNG) and a short instruction. Up to three changes per call; describe the end state to draw ("the grey plate behind the star becomes clear violet crystal"), not what to remove. Name what must not change if it's at risk. Always edit the original, not a previous edit, and add the result to the '## Icons' list in CLAYCUT.md.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | Public URL of the PNG to edit | |
| instruction | Yes | What to change, as the end state to draw |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the paid-key requirement, a per-call credit cost ('costs one icon'), the return value ('download URL for the edited transparent PNG'), and the per-call change limit. It stops short of error modes or what happens when the edit fails, which keeps it from a 5.
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?
Front-loaded with the purpose, then usage and rules of thumb in a compact block; the sentence about describing end state versus removal is genuinely load-bearing. Slightly dense, but no sentence is 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?
For a two-parameter mutation tool with no output schema and no annotations, the description covers auth, cost, expected return, editing constraints, and the downstream workflow step (adding the result to '## Icons' in CLAYCUT.md). An agent has everything needed to invoke it correctly.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: image_url accepts a Claycut asset URL or any public PNG, and instruction should describe the end state to draw rather than what to remove, plus a three-change cap that the schema's maxLength does not convey.
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 first sentence states a specific verb and resource ('Change one thing about an icon') and immediately frames the scope ('keeping everything else as it is'), which is the defining characteristic versus a full regeneration. It names the sibling generate_app_icon explicitly, so an agent can route between them without opening either 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?
Explicit when-to-use ('when the user likes an icon but wants a detail fixed') and when-not ('a new generation redraws the whole object and loses what they liked'), naming the alternative tool. It also gives operational rules: up to three changes, always edit the original not a previous edit, and name what must not change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a free, ready-made transparent PNG icon from the Claycut catalogue. No API key needed. The free set only comes in the clay, editorial and plush house styles, so use it when the project's CLAYCUT.md style is one of those (or the user has no key); otherwise it won't match the project. Returns download URLs for matches, or the full list of available words.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | ||
| concept | Yes | The subject, e.g. "wallet", "rocket", "inbox" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose real behavior: no API key required, the free set is limited to three house styles, and it returns download URLs for matches or the full word list otherwise. It does not cover failure modes, rate limits, or cost implications beyond 'free', which keeps it from a 5.
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?
Four short, front-loaded sentences with no filler. The core action leads, the key constraint follows, and the return behavior closes it out; every sentence carries information an agent needs.
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?
There is no output schema, and the description compensates by describing the return value (download URLs, or the full word list on no match). With no annotations, it adequately covers key/safety context, though it leaves error and no-match handling only partially specified.
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 coverage is 50%: the concept param is documented in the schema, while style has only an enum with no description. The description reinforces the style constraint by naming the same three styles and explaining they are the free set's limit, which adds value, but it adds no syntax or matching semantics for concept.
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?
States a specific verb+resource with scope: "Find a free, ready-made transparent PNG icon from the Claycut catalogue." The word "free" and "catalogue" implicitly distinguish it from the sibling tools (find_my_icon, generate_app_icon, edit_app_icon), but none of those siblings is named, so the differentiation is left to inference.
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?
Gives an explicit selection condition: use it when the project's CLAYCUT.md style is clay/editorial/plush, or the user has no key; otherwise it won't match the project. That is a clear when/when-not rule, though no alternative tool is named for the cases where this tool is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find icons this Claycut account already generated or edited, so you can reuse one instead of paying for a new generation. Needs a Claycut key; free. Check here before generate_app_icon. Returns concept, style, date and download URL for matches, or the account's recent icons if nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| concept | No | Word to search past concepts for, e.g. "wallet"; omit to list recent icons |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the auth requirement ('Needs a Claycut key'), the cost profile ('free'), and the fallback behavior when nothing matches. It omits rate limits or whether matches are scoped strictly to the account, so it falls just short of full behavioral coverage.
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?
Three tight sentences with the purpose and the cost rationale front-loaded, followed by prerequisites and return shape. Every clause earns its place, including the return-value summary that compensates for the absent output schema.
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 one-parameter, read-only lookup with no output schema and no annotations, the description covers purpose, prerequisite, cost, the call-ordering with generate_app_icon, and the shape of returned fields. Nothing an agent needs in order to call it correctly is missing.
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 coverage is 100% and the single parameter is already documented, including the 'omit to list recent icons' behavior. The description restates that behavior rather than adding new syntax, format, or matching semantics, so the baseline 3 applies.
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?
States a specific verb and resource ('Find icons this Claycut account already generated or edited') with an explicit scope restriction to the caller's own account. It also differentiates itself from siblings by naming generate_app_icon and positioning itself as the prior step.
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?
Explicitly tells the agent when to call it ('Check here before generate_app_icon') and why (avoid paying for a new generation), plus the condition for the alternate mode ('omit to list recent icons'). The alternative and its selection condition are both named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a custom transparent PNG app icon or UI illustration of any subject, in the project's own style. Needs a paid Claycut key. Returns a download URL for the finished asset.
Every icon in a project follows one style guide, CLAYCUT.md at the repo root. Before the first call:
If CLAYCUT.md exists, use its style line exactly as written (don't reword it) and skip to step 5.
Otherwise read the project's design system: design docs, Tailwind config, CSS variables and theme tokens, brand colours, fonts, existing icons and illustrations. If there is none, work out what the project is for and who uses it (README, package.json, landing copy, routes) and invent a style that suits it.
Write the style line (at most 300 characters): rendering technique, material, shape language, palette as colour names, lighting, level of detail. It must describe a single solid object that a background remover can cut out: no scenes, no near-white or glassy subjects, no hairline-only line art, no text. Don't mention subject, background or composition; Claycut adds those. Only use a house style (clay, editorial, plush) if it genuinely fits the project, never as a fallback.
Create CLAYCUT.md with: a '## Style line' section holding the exact line, why it fits (palette, material, tone and the files it came from), and an '## Icons' list. Generate one representative icon, show it to the user and adjust the line until they approve it.
Call with style "custom" and style_description set to that line (or the house style name if CLAYCUT.md names one), then add each icon to the '## Icons' list as concept -> file path. Check that list before generating (and find_my_icon for icons this account made in other projects), and reuse one that already exists.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Use "custom" with the style line from CLAYCUT.md; a house style name only if CLAYCUT.md says so. | custom |
| concept | Yes | The subject, e.g. "wallet", "rocket", "inbox" | |
| style_description | No | The exact style line from CLAYCUT.md. Required when style is custom. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does: it discloses the paid-key prerequisite, states the return value (a download URL for the finished asset), and enumerates hard subject constraints (solid single object, no scenes, no near-white/glassy subjects, no hairline line art, no text) that a caller could not infer elsewhere.
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?
Front-loaded with the outcome, then a numbered five-step procedure that mostly earns its length because the pre-call setup is genuinely nontrivial. It is on the long side for a tool description and some of the style-authoring prose borders on prompt content, but nothing is redundant.
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?
No output schema and no annotations, yet the description covers prerequisites, the style pipeline, the return value, and the deduplication path. An agent has everything needed to call it correctly on the first attempt.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: the style line must be copied verbatim from CLAYCUT.md and not reworded, and a house style name may only be passed if CLAYCUT.md names one. That explains how to derive style_description, which the schema only labels.
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?
States a specific verb ('Generate'), resource ('transparent PNG app icon or UI illustration'), and scope ('in the project's own style'). The first sentence alone separates it from edit_app_icon and the two find_* siblings.
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?
Gives an explicit gated workflow: check CLAYCUT.md first, fall back to reading the design system, invent a style only if none exists, get user approval, then call. It also names find_my_icon and the '## Icons' list as the reuse path before generating anything new.
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.
edit_app_iconfind_free_iconfind_my_icongenerate_app_iconGenerate matching icon sets, spot illustrations and transparent design assets for sites and apps.
A coding agent searches the Icons8 library by keyword and style, then adds the selected icon or illustration to the project. Icons8 draws all of it: 420,000+ icons (130+ styles) and 110,000+ illustrations (340+ styles), so one project doesn't end up with mixed looks. The server lives at https://mcp.icons8.com/mcp/ and signs people in through their Icons8 account in the browser. Downloading PNG is free as long as the project links back to Icons8. SVG is on the paid plan, and that plan makes the link optional.
Icons for agentic development: search & fetch 366,000+ open-source icons as SVG/PNG. No API key.
Multilingual semantic SVG icon search with previews for AI coding agents. 20,000+ icons.
Add one secure layer between your agents and this server.
