Sleek

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

The description adds extensive behavior beyond the annotations: queued runs never start, running runs stop at the next step but remain 'running' until settling, settled states and error codes (cancelled, execution_failed, execution_timeout), retention of saved screens/theme changes, charging only when data.result.operations is non-empty, and the project lock. This is exactly the kind of context annotations cannot provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose and then proceeds through relevant behavioral details in short, information-dense sentences. Every sentence contributes distinct and useful information, with no wasted prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema and annotations, the description covers everything an agent needs: purpose, when to use, state transitions, error outcomes, charging, locking, and the polling requirement. No critical point is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters have schema-level descriptions, so the schema already explains runId and projectId sources. The description does not add parameter-level meaning beyond that, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Ask a design run to stop') and immediately gives a motivating scenario. It names the sibling tool 'get_design_run' for polling, so an agent can distinguish cancellation from status checking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear use case ('when the brief was wrong') and a prerequisite ('poll get_design_run before starting another run'). It does not explicitly state when not to use the tool or name a cancel alternative, so it falls short of a full 5.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds genuinely new behavioral context beyond them: creation is free and instant, only design runs spend credits, and the projectUrl should be shared with the user. It stops short of auth/permission details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action, followed by cost and sharing notes. Every sentence carries distinct information with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no explanation, yet the description still highlights the projectUrl for the user-sharing workflow. For a single-parameter creation tool, nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (name) and its schema description already covers it at 100% coverage, so the description adds no syntax or constraint detail. Baseline 3 applies when the schema carries the full parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an empty project') and immediately distinguishes the artifact as empty, which separates it from get_project/list_projects/delete_project siblings. The follow-on workflow reference makes the intent unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when to use it: create first, then call design and screenshot. It doesn't state explicit exclusions or when not to create a project, but the sequencing guidance is actionable.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses cascade scope ('all its screens') and irrecoverability ('Designs cannot be recovered'), plus the human-confirmation workflow required before invoking. These are consequential traits the structured hints do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the irreversible action and scope, then the guardrails. Every sentence earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive two-parameter tool with an output schema and full annotation coverage, the description supplies everything needed: scope, irreversibility, and the confirmation gate. No gaps remain for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so projectId and confirm are already fully documented in the schema, and the description adds no syntax or format detail beyond it. Per the rubric, full schema coverage sets the baseline at 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Permanently delete a project') and adds blast radius ('and all its screens'), so an agent immediately understands the operation. No sibling tool performs deletion, so it is clearly distinguished from create_project, get_project, and list_projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit preconditions ('Call only after your user confirms the exact project by name') and an explicit prohibition ('Never delete projects to tidy up on your own initiative'). Both the when and the when-not are spelled out, leaving nothing to inference for a high-risk operation.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context: it returns only the active version, the history payload can be large, and the returned screenId is the value design consumes. It stops short of discussing auth or guarantees around large payloads.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four compact sentences, front-loaded with the core purpose and followed by scope, alternatives, and routing. Slight redundancy with the schema on the allVersions payload warning keeps it from being perfectly lean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and rich annotations, the description need not explain return values, and it covers the key routing decisions an agent needs. What remains is minor (no mention of other nearby siblings), so it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters are already documented, and the description's note about allVersions history being large largely restates the schema's own warning. The screenId-vs-componentId clarification adds marginal value, making this baseline-3 with a small lift.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (fetch a screen's generated HTML) and pins the scope to the currently-shown version. It clearly separates itself from the design-family siblings by citing the design handoff and the design-run check, though it does not address other siblings like screenshot or list_components.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool (build handoff) and when not to (checking whether a design run worked), and points to allVersions for history. The alternative path and the disqualifying condition are both spelled out rather than inferred.

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

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

Annotations already cover readOnly/idempotent/non-destructive, yet the description goes well beyond them: it discloses the run state machine, that failed runs persist whatever was saved in the same operations list, and that billing applies only when that list is non-empty. This is material behavior an agent cannot infer from the annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tightly packed sentences, front-loaded with the poll loop, then outcomes, then the cost caveat. Every sentence carries an actionable instruction; nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so raw return values need no restating, and the description instead supplies the state-transition and billing semantics that the schema cannot express. For a polling tool with an open-world/polling risk, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both runId and projectId are already documented (runId from data.runId in a design result, projectId from list_projects/create_project). The description reinforces that the run comes from a prior design call but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the specific verb (poll) and resource (a design run) plus the exact states it applies to ('queued' or 'running'). It is trivially distinguishable from sibling tools like design, cancel_design_run, and screenshot without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit operating instructions: poll after design returns queued/running, wait a few seconds between polls, and branch on completed vs failed. It also gives a clear when-to-use rule ('Check it before resending the brief') and routes failures to the error message and optional error URL.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds that a projectUrl is returned and that existence can be confirmed, which is modest value; it doesn't mention failure behavior when the id is unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and output, then the usage guidance. No filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no prose, and annotations fully cover the read-only/idempotent profile. For a single-parameter read tool, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter, and the schema already explains where projectId comes from. The description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fetch a project') and names the notable return value ('projectUrl'), which distinguishes it from list_projects. It also routes a related need to list_components, so an agent can place it precisely among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit context ('confirm the project exists and share the URL with your user') and names an alternative (list_components) for a related task. It stops short of a full when-not rule, but the usage intent is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuinely non-obvious context: results omit generated HTML, which explains why the payload is light. It does not mention pagination behavior, though the limit/offset params and output schema cover that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Five short sentences with zero filler, front-loaded with the primary purpose before the routing instructions. Each sentence earns its place by directing the agent to a specific follow-up tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return value documentation is unnecessary. The description covers the metadata-only scope, the ID mapping for downstream calls, and when to prefer get_component, leaving nothing essential for correct invocation missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so projectId, limit and offset are already documented in the schema, making 3 the baseline. The description's ID guidance (screenId vs id) describes output item fields rather than the input parameters, so it adds little to input semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List a project's screen names and active version numbers'), and clarifies that 'components' in the tool name are actually screens, which the title 'List screens' only hints at. It distinguishes itself from get_component by noting this returns metadata 'without generated HTML'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: pass screenId to design, pass id as componentId to get_component or screenshot, and a stated exclusion ('Use get_component only when you need a screen's code'). This is textbook when-to-use/when-not/alternative guidance.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world semantics, so the safety profile is covered. The description adds real context beyond them: result ordering ('newest first') and what a project entity contains (screens, theme, design chat). It omits any mention of pagination behavior despite limit/offset existing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the action and ordering, with the usage hint following. Every clause carries information; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value details are not the description's burden. Scope, ordering, entity contents, and the duplicate-avoidance use case are all covered, which is sufficient for a simple two-parameter list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so limit and offset are fully documented in the schema with defaults and bounds. The description adds only the ordering rationale ('newest first'), which loosely motivates paging but gives no paging syntax or guidance. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List the workspace's projects'), adds scope and ordering ('newest first'), and implicitly contrasts with get_project by being plural/workspace-wide. An agent can distinguish it from list_components and get_project without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes pre-creation checks: 'Check here before create_project to avoid duplicates' names the alternative and the condition that selects it. It doesn't address when to use this vs get_project for retrieving a single known project, so it falls just short of full when/when-not coverage.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful workflow context: references are curated styles with preview images, and the chosen id should be passed to design.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the tool purpose before usage guidance. Each sentence carries distinct information without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a simple list tool: annotations cover safety, the output schema covers return structure, the input schema covers pagination, and the description covers the selection workflow with design.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so limit and offset are already fully documented. The description adds no additional meaning about these parameters, which is the expected baseline when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: listing curated app styles and their preview images. The reference-to-design workflow distinguishes it from sibling list tools and from design itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it: when the user asks for a look such as Airbnb, brutalist, or dark fintech. It also describes the alternative path when no reference is selected.

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

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

Annotations already establish the safe read-only, idempotent profile, so the bar is lower. The description adds real context: the output is a single inline image, rendering carries no cost, and the result is meant to be handed to the user for editing. It stops short of describing failure modes when no completed run exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the operation and its precondition front-loaded and no filler. Each sentence contributes (scope, cost, downstream handoff).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully notes the return is one inline image and gives the intended user handoff, covering most of what the agent needs. The unexplained 'projectUrl' reference is the one loose end in an otherwise complete picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema carries parameter meaning and 3 is the baseline. The description's 'up to four' merely restates the maxItems constraint, and it references a 'projectUrl' to send alongside the image that does not correspond to any parameter in the schema, which adds noise rather than clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Render up to four project screens as one inline image'), includes the scope cap and the precondition ('after a design run completes'). An agent can distinguish this from siblings like get_component or design 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The condition 'after a design run completes' gives implied timing, and the four-screen cap implies batching, but no alternative tool is named and no explicit when-not guidance is provided. Adequate but leaves routing to inference.

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