Sleek

Design screens with AI

design

Run Sleek's design agent to create or edit screens from a plain-language brief. Send the whole request as ONE message, such as 'a food delivery app with onboarding, restaurants, dish detail, cart, tracking, and profile'. The agent plans the screens together, so separate calls produce mismatched screens. A run spends workspace credits when it completes or saves changes. By default this waits for the run to finish. If it returns 'queued' or 'running', poll get_design_run. Only one run can be active per project. On CONFLICT, poll get_design_run until the run settles, then retry. cancel_design_run stops it sooner. If a failed run has data.error.url, your user has to act there, such as topping up credits, before you retry. On completion, share projectUrl with your user and call screenshot.

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	Wait for the run to finish before returning. The wait is capped at 270 seconds, after which you get status 'running' back and poll get_design_run. Set false to return immediately and poll from the start, which is the better choice if your client times tool calls out sooner than that.
`message`	Yes	The full design brief, as one message. Name every screen you want in this single request.
`screenId`	No	Edit this existing screen instead of creating new ones. Use the screenId from list_components, or from a previous run's data.result.operations (via design or get_design_run). It is not the component id.
`imageUrls`	No	HTTPS image URLs for visual input, such as screenshots, logos, or style references.
`projectId`	Yes	Project id from an item's id in list_projects, or data.id in create_project.
`referenceId`	No	Design reference to imitate, from list_references.
`idempotencyKey`	No	Pick a unique key for each new design request, such as a UUID. Reuse it for retries to return the original run without a second charge.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`projectUrl`	Yes	Open link for the project. Share it with your user.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only state the basic safety profile (readOnly=false, idempotent=false, destructive=false, openWorld=false); the description goes well beyond them with credit consumption on completion/save, the default blocking wait, the concurrency limit of one active run per project, CONFLICT resolution, and the data.error.url escalation that requires end-user action. That is exactly the non-obvious behavior an agent needs before invoking.

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 purpose followed by operational rules, with near-zero filler; every sentence carries an instruction (wait semantics, polling, credits, CONFLICT, post-run screenshot). It is dense and slightly long for a single description, which keeps it just short of ideal.

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?

Given an output schema exists, the description does not need to restate return values, and it correctly focuses on the edges that matter: status values that require polling, failure URLs requiring user action, credit spend, and the required post-completion handoff (share projectUrl, call screenshot). Nothing needed to call this correctly is missing.

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 value on top: it explains why 'wait' defaults to true and when to set it false, that 'message' must name every screen in one request, and that 'screenId' edits rather than creates. It does not add syntax or format details beyond the schema for imageUrls/referenceId.

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?

Opens with a specific verb+resource ('Run Sleek's design agent to create or edit screens') and immediately scopes the input modality ('from a plain-language brief'). It is clearly distinguishable from siblings like get_design_run and cancel_design_run, which are named later as follow-up/abort paths.

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?

Explicit when-to-use rules: send everything as ONE message with a worked example, never split across calls because 'separate calls produce mismatched screens'. It also gives the alternative path (cancel_design_run to stop sooner) and the exact recovery procedure for queued/running and CONFLICT states.

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

All Sleek 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.