48-hour HTTPS previews of prebuilt static sites and HTML slides. No server builds or backends.
Scored across 6 tools
Each tool has a clearly distinct action and target: create/update/delete modify previews, get_preview_status reads public preview state, get_operation_status tracks prepared operation state, and get_deploy_instructions provides publication guidance. Despite create and update sharing a preparation flow, their descriptions make the boundary clear.
All tool names use a consistent snake_case verb_noun pattern (create_preview, delete_preview, get_preview_status, update_preview, etc.). The get_* tools vary only in the noun being fetched, which is predictable.
Six tools is well-scoped for a temporary static preview service: four lifecycle operations plus status and instruction readers. No tool feels redundant or missing from a count perspective.
The surface covers create, read/status, update, delete, and deployment guidance, which is strong lifecycle coverage. A list_previews operation is absent, so an agent cannot enumerate existing previews, but this is a minor gap given the browser-confirmed management model.
Prepare a new temporary static preview. Supply exactly one of small files or ZIP archive_base64. No backend/build. Requires explicit consent; returns an approval link, not a published URL. User must confirm in their browser.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| accept_terms | Yes | ||
| archive_base64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true and non-idempotent, so the mutation profile is covered. The description adds non-obvious workflow context beyond that: an approval link is returned rather than a published URL, the user must confirm in the browser, and consent is mandatory. It still omits preview lifetime/expiry and any rate or size ceilings beyond 'small'.
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 action, then constraints, then outcome. Every sentence carries information; only the final consent sentence slightly overlaps the earlier 'Requires explicit consent' clause.
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 consent-gated, non-publishing preview creation tool with no output schema, the description covers the essential workflow: what is created, the input constraint, the consent gate, and the fact that approval happens out of band in a browser. It does not point at get_preview_status or get_operation_status for follow-up, which is a minor omission.
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?
With 0% schema description coverage, the description carries the full burden, and it partially compensates: the mutual-exclusivity rule between files and archive_base64 is stated and 'explicit consent' maps to accept_terms. But it does not explain the per-file path/content/encoding fields, the nested file structure, or any size limits, leaving meaningful gaps.
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 ('Prepare a new temporary static preview') and the qualifiers 'new' and 'temporary static' distinguish it from update_preview and delete_preview. It stops short of explicitly naming a sibling or contrasting its role, so it is clear but not maximally differentiated.
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?
'Supply exactly one of small files or ZIP archive_base64' and 'Requires explicit consent' give real calling context, and 'No backend/build' narrows the scope of what is acceptable. However, there is no explicit when-to-use vs when-not guidance relative to siblings like update_preview or get_preview_status; usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare deletion of an existing preview. Does not delete until its owner confirms in the browser holding the management key.
| Name | Required | Description | Default |
|---|---|---|---|
| preview_id | Yes | ||
| confirm_delete | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely useful behavior beyond that: this is a deferred, two-phase deletion gated on owner confirmation in the browser holding the management key, revealing an auth/workflow constraint the annotations 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?
Two tight sentences with zero filler; the deferred-deletion behavior is front-loaded right after the purpose statement.
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 adequately covers the destructive workflow and its confirmation gate, which is the hardest part. It remains incomplete on parameter semantics (undocumented confirm_delete) and offers no return information, though no output schema exists to compensate.
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% across two parameters, so the burden falls on the description. It only alludes to an 'existing preview' (preview_id) and never explains confirm_delete, its required const=true value, or the management key, leaving the parameters essentially undocumented.
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 ('Prepare deletion of an existing preview'), distinguishing it from siblings like create_preview and update_preview. The 'prepare' framing signals a two-phase operation, though the name delete_preview could momentarily suggest an immediate delete.
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?
Usage is implied rather than stated: the description explains that deletion only completes after owner confirmation, which is important context for when the call is appropriate. However, it names no alternatives or explicit conditions for choosing this over update_preview or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain remote browser-confirmed AIfra publication of ready static files, limits and current terms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description does not contradict it. The description adds that the content covers instructions, limits, and current terms, but it does not disclose return format, whether information is fetched live, or any other behavioral details beyond the annotation.
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 a single sentence, front-loaded with the action ('Explain') and the subject. It is concise with no filler or redundant repetition of the tool name.
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 zero-parameter, read-only informational tool with no output schema, the description covers the essential content areas: publication process, limits, and current terms. It is slightly incomplete in clarifying what 'remote browser-confirmed' means, but overall an agent has enough context to invoke and use the tool appropriately.
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 tool takes zero parameters and the schema describes no properties, so there is nothing the description needs to explain. The baseline score for zero-parameter tools is 4, and the description does not need to compensate for any schema gaps.
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 the specific verb 'Explain' and names the exact resource: remote browser-confirmed AIfra publication of ready static files, along with limits and current terms. It distinguishes itself from the preview/status siblings by being the only instructions-focused tool, though 'AIfra' and 'remote browser-confirmed' are jargon that could confuse an agent.
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?
Usage is implied: an agent would call this when deployment instructions, limits, or terms are requested. However, there is no explicit guidance about when to prefer this over siblings like get_preview_status or get_operation_status, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read whether a prepared operation is pending, complete, failed or uncertain. Returns no file content or management key. Never assume pending means published.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, so the description adds useful behavioral context beyond that: it returns no file content or management key, and it warns that a pending status must not be treated as published. These are meaningful caveats not inferable from 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?
Three short sentences, each earning its place: the first defines the action and possible outcomes, the second states exclusions, and the third provides an important interpretive caveat. The key purpose is front-loaded.
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 read-only status tool, the description covers the essential outcomes, exclusions, and an important semantic warning. It does not mention error cases like unknown operation IDs, but the scope is simple enough that this is not a critical gap.
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, operation_id, and the schema documents its format via a regex pattern. The description ties the parameter to 'a prepared operation' but does not explain how to obtain or validate an operation_id. This is adequate but minimal compensation for the absence of schema descriptions.
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 ('Read') and resource ('a prepared operation'), and enumerates the possible statuses: pending, complete, failed, or uncertain. This clearly differentiates it from sibling get_preview_status, which is scoped to previews rather than prepared operations.
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 clearly indicates this tool is for reading the status of a prepared operation, which tells an agent when to reach for it over the preview-status sibling. It does not explicitly name alternatives or state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read public status, URL and original expiry of an existing preview.
| Name | Required | Description | Default |
|---|---|---|---|
| preview_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating a safe, non-destructive read. The description adds specificity about what is read (status, URL, original expiry), which is valuable context beyond the annotations. It does not contradict the annotations and adds useful detail about the operation's scope.
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?
A single, well-structured sentence that front-loads the verb 'Read' and immediately states the target and the fields. There is zero filler, and every word adds value. It is appropriately sized for the simplicity of the operation.
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 read operation with one parameter and no output schema, the description covers the essential semantics: what is read and from what. It doesn't mention error cases (e.g., non-existent preview) or the exact response format, but for a read-only tool with annotations indicating safety, this is largely sufficient. The openWorldHint suggests the world may change, but that's annotation-provided. The description is adequate for an agent to know what to expect.
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 for the parameter. The only parameter is preview_id, with a pattern suggesting an ID format, but the description does not explicitly state that preview_id is the identifier of the preview to read. The phrase 'existing preview' hints at it, but no explicit mapping is given. This is minimal compensation for a low-coverage schema.
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 clearly states the action ('Read') and the resource ('existing preview'), and specifies the exact data returned (public status, URL, original expiry). It is immediately distinct from sibling tools like create_preview, delete_preview, and update_preview, which are mutations, and from get_deploy_instructions/get_operation_status, which target different resources.
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 implies usage context: it is for reading preview metadata, not for creating, updating, or deleting. While it doesn't explicitly name alternatives or exclusion conditions, the purpose is clear enough that an agent would not confuse it with the mutation tools. However, it doesn't mention when to prefer this over get_operation_status, which could also relate to preview state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepare replacement of an existing temporary static preview. Supply exactly one of small files or ZIP archive_base64. No backend/build. Requires explicit consent; returns an approval link, not a published URL. User must confirm in their browser. Requires the browser holding the existing management key; expiry is unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| preview_id | Yes | ||
| accept_terms | Yes | ||
| archive_base64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations, which only declare destructive/openWorld/non-idempotent. The description adds the consent-gated two-step flow ('returns an approval link, not a published URL; user must confirm in their browser'), the browser-bound management-key requirement, that no backend/build occurs, and that expiry is unchanged. These are exactly the behavioral facts an agent needs before invoking a destructive staging tool.
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 tight sentences, front-loaded with the purpose and then each subsequent clause adding distinct operational value (mutual exclusivity, no build, consent flow, auth requirement, unchanged expiry). 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?
With no output schema and no annotations describing returns, the description correctly covers the return behavior (approval link, not published URL) and the confirmation flow. It is nearly complete, missing only explicit documentation of preview_id's expected format and the accept_terms flag.
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?
With 0% schema description coverage, the description must carry parameter meaning, and it does cover the key constraint that files and archive_base64 are mutually exclusive. But it leaves preview_id format, accept_terms semantics (only loosely via 'requires explicit consent'), and the encoding option unexplained, so it only partially compensates for the coverage gap.
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: 'Prepare replacement of an existing temporary static preview.' The word 'existing' implicitly separates it from create_preview, and 'prepare replacement' clarifies this is a staged operation rather than a direct write. It stops short of naming sibling tools explicitly, so it lands at a clear-but-not-sibling-differentiating 4.
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?
'Supply exactly one of small files or ZIP archive_base64' gives a real usage constraint, and 'existing' implies the update-vs-create split. However, it never explicitly says when to pick this over create_preview or delete_preview, nor names an alternative, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_preview2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / archiveRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "download_url": {
- "maxLength": 8192,
- "type": "string"
- },
- "file_id": {
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "file_name": {
- "maxLength": 240,
- "type": "string"
- },
- "mime_type": {
- "maxLength": 100,
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
-}delete_preview1 field changedInput schema / additionalPropertiesAdded value: +falseupdate_preview2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / archiveRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "download_url": {
- "maxLength": 8192,
- "type": "string"
- },
- "file_id": {
- "maxLength": 256,
- "minLength": 1,
- "type": "string"
- },
- "file_name": {
- "maxLength": 240,
- "type": "string"
- },
- "mime_type": {
- "maxLength": 100,
- "type": "string"
- }
- },
- "required": [
- "download_url",
- "file_id"
- ],
- "type": "object"
-}create_previewdelete_previewget_deploy_instructionsget_operation_statusget_preview_statusupdate_previewPublish a single HTML file as a live HTTPS site in seconds. Versioned deploys, no delete tool.
Host static HTML pages, generate PDFs, screenshots, scrape JS sites, run sandboxed JavaScript.
Publish HTML, Markdown, PDF, or images as instant shareable links with expiry and passwords.
Publish and update safe static HTML reports, presentations, and explainers with controlled sharing.
Add one secure layer between your agents and this server.
