cancel_requestWithdraw a pending request you created — a credential request from request_external_resource, a custom-domain setup request from publish_app, or an open screenshot job from screenshot_preview (jobId from that tool). Only pending requests can be cancelled — completed ones are final. Use when the user says to stop or they don't want to proceed.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| projectId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only readOnlyHint=false and destructiveHint=false, so the description adds the meaningful behavioral constraint that only pending requests are cancelable and that you can only cancel requests you created. It does not describe side effects (e.g., state changes or response), but the core behavioral limits are disclosed.
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 two efficiently worded sentences. The primary purpose is front-loaded, followed by the constraint and usage trigger. No redundant phrases or unnecessary details are present.
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 simple two-parameter cancel operation, the description covers the what, when, and the pending/complete distinction. However, it omits how the agent obtains the required identifiers for the non-screenshot request types (no mention of returned fields), and it does not define projectId. Given no output schema and 0% schema coverage, these gaps make calling the tool correctly less certain.
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 0%, so the description must compensate. While it mentions 'jobId from that tool' for screenshot_preview, it does not explicitly map jobId or projectId for the other request types, nor does it explain what projectId represents. The agent is left to infer that the identifiers come from the respective tools, which is underspecified for reliable invocation.
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 ('Withdraw') and resource ('a pending request you created'), and enumerates the three exact request types with their originating tools. This clearly distinguishes the tool's scope from all sibling tools, leaving no ambiguity about what it operates on.
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 invocation context: 'Use when the user says to stop or they don't want to proceed.' It also sets a clear exclusion — 'Only pending requests can be cancelled — completed ones are final' — which prevents misuse on completed requests. The enumeration of source tools further guides when this is the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct, but there is some overlap among file-modifying tools (edit_file, write_file, apply_patch) and between run_code_in_vm and run_code_in_browser. Detailed descriptions and clearly scoped use cases help agents select correctly.
Most tools follow a verb_noun snake_case pattern (create_project, list_files, execute_sql), but a few deviate (apply_patch, card_upload_asset, run_code_in_vm). Overall readable and predictable, with only minor inconsistencies.
With 46 tools, the server exceeds the typical well-scoped range and approaches the extreme threshold. While the broad scope of a full development platform justifies many tools, this count may overwhelm agents and increase misselection risk.
The tool surface covers the full development lifecycle: project creation, file operations, database management, resource provisioning, deployment, testing, and debugging. Minor gaps exist (e.g., no delete_project or checkpoint management), but core workflows are well-supported.