Read remaining preview time. uploadId is the UUID (a preview URL is OK). Does not scan, does not reset the clock, never 402. If claimable is false, the preview was deleted — call upload_url, PUT a new zip, inspect, then claim. Do not inspect or claim the old id. Do not pay. Use this instead of inspect when you only need the clock.
| Name | Required | Description | Default |
|---|---|---|---|
| uploadId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself, and it does so clearly: 'Does not scan, does not reset the clock, never 402.' It also explains the deletion condition via claimable false. This goes far beyond the minimal 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?
Every sentence is functional: the operation is front-loaded, followed by side-effect guarantees, the deletion branch, the proper recovery workflow, and guidance on when to use inspect instead. The length is justified by the amount of useful, non-obvious context.
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?
The description covers the action, the parameter, side effects, failure behavior, and the correct alternative path. The main gap is that it leaves the response shape implicit rather than stating exactly what fields the tool returns, and there is no output schema to fill in that detail.
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 only states uploadId is a required string, so the description adds essential meaning by saying it is a UUID and that a preview URL is acceptable. Since schema description coverage is 0%, this parameter guidance fully compensates.
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 begins with a clear verb and object: 'Read remaining preview time.' It also distinguishes itself from inspect by saying 'Use this instead of inspect when you only need the clock,' so the tool's role is immediately unambiguous.
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 description explicitly states when to use this tool versus inspect, and gives a clear failure workflow: if claimable is false, call upload_url, PUT a new zip, re-inspect, then claim. It also warns against acting on the old id and against paying, which prevents costly mistakes.
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.