Skip to main content
Glama

Claycut

by io.github.vincentzhang15
OverviewDiscussionsAdmin

generate_app_icon

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:

  1. If CLAYCUT.md exists, use its style line exactly as written (don't reword it) and skip to step 5.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Input Schema

NameRequiredDescriptionDefault
styleNoUse "custom" with the style line from CLAYCUT.md; a house style name only if CLAYCUT.md says so.custom
conceptYesThe subject, e.g. "wallet", "rocket", "inbox"
style_descriptionNoThe exact style line from CLAYCUT.md. Required when style is custom.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Claycut toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources