Sleek

Get a design run

get_design_run

Read-onlyIdempotent

Poll a run that design returned as 'queued' or 'running'. Wait a few seconds between polls. On 'completed', data.result.operations lists the saved screens and theme changes. Call show_project with this runId to show your user what the run made, inline. Use screenshot only where your client cannot show apps. Then share projectUrl. On 'failed', relay data.error.message to your user, with data.error.url if present. A failed run, including a cancelled one, keeps what it saved in that same list and uses credits only when the list is not empty. Check it before resending the brief.

Input Schema

Name	Required	Description	Default
`runId`	Yes	Run id from data.runId in a design result.
`projectId`	Yes	Project id from an item's id in list_projects, or data.id in create_project.

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"
+]

Changed1 schema field changedOct 16, 2026

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.7/5.0

Behavior5/5

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

Although annotations already declare this as read-only, idempotent, non-destructive, and closed-world, the description adds substantial behavioral context beyond them. It describes polling cadence, state transitions, what `data.result.operations` contains, how to surface completed work, and how to handle `failed` runs including saved items and credit usage. There is no contradiction with the read-only annotation.

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?

The description is front-loaded with the core polling instruction and then covers each relevant state in sequence. Every sentence adds operational value: polling cadence, completed results, display fallback, error relay, and failed-run credit behavior. There is no redundant restatement of the tool name or schema.

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 stateful polling tool, the description covers the full lifecycle: queued/running polling, completed results, failed error handling, and the fallback display path. Output schema exists, so return values need not be exhaustively documented, but the description still gives useful result-field context. Nothing an agent needs in order to call and act on this tool correctly appears to be 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 coverage is 100%, so both required parameters are already well documented in the input schema. The description references the runId in the context of passing it to `show_project`, but it adds little parameter-level meaning beyond the schema. Baseline 3 is appropriate when the schema carries the parameter documentation.

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?

The description states a specific verb and resource: polling a design run returned as 'queued' or 'running'. It clearly separates this from the sibling tool `design` that starts runs, and from `show_project`/`screenshot` for displaying results. An agent can identify exactly what this tool does without opening the schema.

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?

It gives explicit when-to-use guidance: poll only queued/running runs, with a delay between polls. It also names alternatives and conditions: use `show_project` with this runId to show results inline, and use `screenshot` only when the client cannot show apps. Failure handling and checking a failed run before resending the brief are also specified.

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.