Sleek

Design screens with AI

design

Destructive

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 uses workspace credits only 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, relay data.error.message to your user with that link. They have to act before you retry. On completion, call show_project with data.runId to show your user what the run made, inline. Use screenshot only where your client cannot show apps. Then share projectUrl with your user.

Input 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 instead of starting a second one.

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

Changed3 schema fields changedOct 19, 2026

addedOutput schema / properties / data / properties / error / properties / limit

Added value: +{
+  "description": "The plan or credit limit that caused this error.",
+  "enum": [
+    "agent_access",
+    "credits",
+    "projects"
+  ],
+  "type": "string"
+}

removedOutput schema / properties / data / properties / statusUrl

Removed value: -{
-  "description": "Relative REST path for polling this run.",
-  "type": "string"
-}

changedOutput schema / properties / data / required

Previous value: -[
-  "runId",
-  "status",
-  "statusUrl"
-]New value: +[
+  "runId",
+  "status"
+]

Changed2 schema fields changedOct 16, 2026

changedInput schema / properties / idempotencyKey / description

Previous value: -"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."New value: +"Pick a unique key for each new design request, such as a UUID. Reuse it for retries to return the original run instead of starting a second one."

changedOutput schema / properties / data / properties / error / properties / url / description

Previous value: -"Where the caller's user can resolve this error (e.g. top up credits). Relay it to the user."New value: +"Where the caller's user can resolve this error. Relay it to the user."

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true) by disclosing credit consumption timing ('only when it completes or saves changes'), the default blocking wait and its polling fallback, the one-active-run-per-project constraint, CONFLICT recovery, and the required user action when data.error.url is present. That is exactly the operational context an agent needs before firing a costly, state-changing run.

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 purpose and the single most important usage rule, then sequenced cleanly through credits, waiting/polling, conflicts, errors, and follow-up. It is dense and long, and the closing cluster of post-run instructions (show_project, screenshot, projectUrl) borders on overload for one tool, but none of it is 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?

For a costly, long-running, destructive mutation, the description covers initiation, waiting, polling, conflict recovery, failure handling, and the follow-up call chain — even though an output schema exists. Nothing an agent needs in order to invoke it correctly is absent.

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 semantic weight: it stresses that message must carry every screen in a single call, and that create-vs-edit is selected by supplying screenId. It also frames the run's identifiers (data.runId, projectUrl) that the parameters feed into.

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 Sleek's design agent to create or edit screens from a plain-language brief' — with both the create and edit modes named. It is immediately distinguishable from siblings like get_design_run, cancel_design_run, and show_project, which are each given explicit roles in the text.

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/when-not guidance: send everything as ONE message because separate calls produce mismatched screens; poll get_design_run on 'queued'/'running' or CONFLICT; use cancel_design_run to stop sooner; use show_project on completion and screenshot only where the client cannot render apps. Alternatives and their triggering conditions are all named.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.