AI Separations

Run a full color separation

separate_image

Run the real separation engine on artwork: detected spot inks, one grayscale film-positive plate per ink (halftoned, dot-gain compensated, white underbase on dark garments) plus a composite print preview. With no key: free small preview. With free_email: ONE full separation per email address, plates delivered by email, no watermark. With api_key: metered (1 credit), plates emailed to deliver_email.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "separate_image"
  }
}

Input Schema

Name	Required	Description
`mode`	No	index = one ink per square pixel, no halftone; gray = one screen (black ink on light shirts, white on dark); sim = simulated process (default), spot = solid spot colors for flat logos, cmyk = 4-color process, dtf = DTG/DTF print file prep
`colors`	No	Force this many inks (omit = auto-detect)
`api_key`	No	AI Separations API key (metered, 1 credit)
`garment`	No	Shirt the art prints on: "dark" (black, default), "light" (white), a color name (Navy, Royal, Red, Maroon, Forest, Gold, Heather Grey, Charcoal, ...) or a hex like "#1f2a44". The separation is solved against that exact shirt color.
`palette`	No	Exact ink hex codes to separate to (optional)
`image_b64`	No	Base64 (or data URL) of the artwork — alternative to image_url
`image_url`	No	Public http(s) URL of the artwork (PNG/JPG, max 12 MB)
`underbase`	No	Print a white underbase (default: on for shirts darker than mid-grey)
`free_email`	No	Email for the one-per-email FREE full separation — plates are sent there
`deliver_email`	No	Where to email the full-resolution plates zip (defaults to free_email)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare the generic safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false). The description adds real operational context the annotations cannot: credit metering (1 credit), watermarking on the free tier, a one-per-email limit, email delivery of the plates zip, and default underbase behavior on dark garments.

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 sentences, each earning its place: sentence one defines the operation and outputs, sentences two and three tier the pricing/delivery paths. The most decision-relevant fact (what gets produced) is front-loaded and there is no filler.

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?

With no output schema, the description carries the burden of describing returns, and it does so concretely (per-ink halftoned plates plus a composite preview) while also covering the key-gated delivery and billing branches. For a 10-parameter tool with full schema coverage and no output schema, nothing an agent needs to invoke it correctly is missing.

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%, so every parameter already carries its own explanation, including the mode enum. The description reinforces a couple of behaviors (white underbase on dark garments, plates going to deliver_email) but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 and resource ("Run the real separation engine on artwork") and enumerates the concrete artifacts produced: detected spot inks, one grayscale film-positive plate per ink, white underbase, and a composite print preview. That output list is enough to distinguish it from the sibling estimate_screens, which measures rather than renders.

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?

Gives explicit, mutually exclusive invocation paths: no key for a free small preview, free_email for one full separation per address, api_key for metered runs. It does not name any sibling (e.g. check_credits or buy_credits for acquiring a key) or state when an agent should prefer estimate_screens first, so it stops short of full when/when-not/alternatives guidance.

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

All AI Separations tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?