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?
With no annotations, the description carries full responsibility for behavioral disclosure and does this well. It states that nothing is deployed, that the operation is free and quota-safe, and that the verdict is advisory because inspect re-checks before deploying. These details go well beyond what the schema or annotations reveal.
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 tight and front-loaded: the first sentence states the purpose, the second gives usage context, the third covers the alternative. Every sentence earns its place and no information is repeated.
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 tool with one required parameter, no nested objects, and no output schema, the description is remarkably complete. It gives the operational workflow, cost implications, the advisory nature of the result, and when to hand off to inspect. Nothing material 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?
The schema describes only 'uploadId' as a string, so the description must compensate. It does so by tying the parameter to the 'uploaded zip' and the upload_url workflow, making the meaning clear. It stops just short of explicitly stating that 'uploadId' is the value returned by upload_url.
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 uses a specific verb and resource ('Check an uploaded zip for unsafe files') and scopes it with a clear exclusion ('WITHOUT deploying anything'). It also distinguishes itself from the sibling inspect, which deploys a throwaway preview Worker.
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 loop ('scan → fix → upload_url again → scan') and the exact condition for switching to a sibling ('When the content is clean and the human wants to SEE it, call inspect to deploy'). It also adds decision-relevant context: free, never 402, and does not burn preview quota.
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.
Each tool has a clearly distinct role in the website lifecycle: upload, scan, inspect, check status, claim, edit, renew, connect domain, and run the full publish flow. Even publish_website, which orchestrates other steps, is clearly higher-level and wouldn't be confused with individual action tools.
All names are lowercase snake_case and mostly verb-first (claim, edit, inspect, renew, scan, upload_url, publish_website). A couple are noun-noun compounds like preview_status and connect_custom_hostname, but the overall pattern is predictable and readable.
Nine tools is a good scope for a website publishing/hosting service. Each tool covers an essential step without unnecessary redundancy, and the pipeline from upload to claim to renew is clearly represented.
The tool set covers the core workflow comprehensively: upload, scan, preview, claim, edit, renew, and custom domains. A minor gap is that there is no direct tool to check the live site's remaining lease time, which is relevant for renewal eligibility, though the workflow works around it through publish/renew context.