Check an uploaded zip for unsafe files WITHOUT deploying anything. Free, never 402, burns no preview quota — use this while iterating on the zip (scan → fix → upload_url again → scan). When the content is clean and the human wants to SEE it, call inspect to deploy a throwaway preview Worker. Verdict here is advisory: inspect re-checks before deploying.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full transparency responsibility. It explicitly discloses side-effect behavior (no deployment), cost behavior (free, never 402, burns no preview quota), and reliability semantics (verdict advisory; inspect re-checks before deploying). This is highly transparent for a tool with no annotations.
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 information-dense and every sentence contributes: it states the safety behavior, cost/quota guarantees, iterative usage workflow, sibling alternative, and advisory nature of the result. It is front-loaded and stays focused.
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 single-parameter scan tool, the description covers when, why, how, and what not to expect, and it even routes to inspect when appropriate. The only gap is that the return value is only called 'verdict' without describing the concrete output shape, which matters more because no output schema is provided. Still, the description is close to 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?
There is only one parameter, uploadId, and the schema provides no description. The tool description indirectly clarifies the parameter by talking about an uploaded zip and the upload_url workflow, but it never explicitly states that uploadId comes from upload_url or what format/scope the value has. It adds some semantic context but does not fully compensate for the 0% schema coverage.
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 names a concrete action and resource: 'Check an uploaded zip for unsafe files' while explicitly saying that nothing is deployed. It also distinguishes the tool from its sibling 'inspect' by contrasting no-deploy scan vs deploy-as-throwaway-preview, so an agent can tell them apart.
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 an explicit workflow 'scan → fix → upload_url again → scan' and tells when to switch to inspect: when the content is clean and the human wants to SEE it. It also warns the verdict is advisory, so the agent knows not to rely on it as final.
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.
claim and publish_website both describe taking a website live, creating real ambiguity about which tool to call once a preview is ready. scan and inspect also overlap in that both check for unsafe files, but the descriptions clearly separate free scanning from paid preview deployment. Other tools are distinct enough given their detailed descriptions.
The set mixes single-word verbs (claim, edit, inspect, renew, scan) with verb_noun pairs (connect_custom_hostname, publish_website, render_page, upload_url), and preview_status reads more like a status endpoint than an action. However, all names are snake_case and mostly descriptive, making the inconsistency moderate rather than chaotic.
10 tools is within the reasonable range for a publishing workflow, and each lifecycle step from upload through preview, claim, renew, edit, and custom hostname is represented. render_page feels somewhat tangential to the site-hosting domain, but it does not significantly bloat the set.
The main publish workflow is well covered: upload, security scan, preview, status, claim, renew, edit, and custom hostname. Obvious lifecycle gaps remain, such as no way to list live sites, read remaining lease duration for a live site, or delete/unpublish a site. There is also no dedicated 'get live URL' tool, though claim likely returns it.