Carryo Website Publisher

Save a Private Website Draft

website.save_draft

Saves supplied HTML as a new private Carryo website draft for review before publication. Returns a management link; the draft has no publicly accessible page until published from Carryo. Passwords and restricted access are configured in the Carryo web app. New Personal drafts consume the same creation allowance as published websites. Personal is the default destination; workspaceId selects a user-chosen team. Image assets use relative HTML paths and exactly one source: a fileId matching a host-supplied imageFiles attachment, or a fetchable HTTP(S) sourceUrl. Carryo imports and hosts its own copy. Base64 image bytes and data URLs are unsupported. Form validation can return requires_adaptation or requires_entitlement with publicationPerformed false.

Input Schema

TableJSON Schema

Name	Required	Description
`forms`	No	Optional definitions for JavaScript/React forms using window.CarryoForms.submit(key, values), which resolves on acceptance and rejects on failure. Stable keys and field names identify forms across edits. Static collection forms are inferred from data-carryo-form="key" and named controls without duplicate definitions; placeholder submit handlers can block collection. Local calculator/filter forms use data-carryo-local and do not collect responses. Existing external endpoints retain their destination. Visitor acknowledgement is disabled unless explicitly enabled.
`assets`	No	Optional image assets to add or replace. Each entry requires a relative HTML path and exactly one of fileId (matching imageFiles[].file_id) or sourceUrl (a fetchable HTTP(S) image URL). Existing images are preserved when omitted. The hosted-image allowance applies to the final website collection; replacing an existing path does not use another slot. Base64 bytes and data URLs are unsupported.
`fileName`	Yes	Short internal file name, for example client-proposal.html, board-deck.html, report.html, or landing-page.html.
`expiresAt`	No	Optional ISO-8601 expiration timestamp
`customSlug`	No	Optional user-chosen URL ending using lowercase letters, numbers, and hyphens. An automatic URL is generated when omitted.
`imageFiles`	No	Optional image attachments supplied by a compatible host, with file_id and download_url. Each attachment is mapped to a relative HTML path by an assets entry with the matching fileId. Temporary download URLs are import sources, not hosted image URLs. Clients without file input support can omit this field.
`htmlContent`	Yes	Complete HTML for the private Carryo draft page, presentation, slide deck, proposal, report, landing page, dashboard, invitation, portfolio, or one-page website.
`workspaceId`	No	Optional exact workspaceId of the Carryo team explicitly selected by the user. The default destination is Personal when omitted.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No
`forms`	No
`status`	No
`draftId`	No	Carryo private draft identifier
`message`	No
`guidance`	No
`expiresAt`	No	Optional ISO-8601 expiration timestamp
`manageUrl`	No	Carryo URL where the user can review access settings and publish the draft
`workspaceId`	No	Workspace that owns the draft; omitted for Personal
`currentVersionNumber`	No
`publicationPerformed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 10, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description fully discloses behavioral traits beyond annotations: no public page until published, management link returned, consumption of creation allowance, form validation errors (requires_adaptation/requires_entitlement with publicationPerformed false), image hosting behavior, and restrictions on unsupported formats. With annotations only indicating non-read-only/non-destructive, the description carries the full burden and does so thoroughly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but structured efficiently: core behavior first, then asset constraints, then form behavior, then validation notes. Some redundancy exists between the top-level description and schema field descriptions (e.g., base64 unsupported appears twice), and the form-related sentences could be tighter. However, the front-loading is good and every sentence contributes meaningful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 params, nested assets/forms, sibling publish/edit tools, no output schema details), the description covers all critical aspects: what the tool does, when to use it, what to know about assets and forms, what errors to expect, and what the response contains (management link, publicationPerformed). The presence of an output schema further reduces the need to explain return values, and the description already addresses key lifecycle behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds meaning beyond the schema: it explains the mutual exclusivity of fileId and sourceUrl, the relationship between assets and imageFiles, the behavior of forms and static collection forms, the meaning of workspaceId vs personal default, and the lifecycle of drafts (no public page until published). The description enriches every parameter's semantics, not just repeating names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence clearly states the tool's action ('Saves supplied HTML as a new private Carryo website draft for review before publication'), identifies the resource (private website draft), and differentiates it from siblings by emphasizing 'private' and 'draft' before publication. This distinguishes it from website.publish, website.edit, and website.read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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 vs alternatives: it saves a draft for review before publication, notes that published websites use website.publish, and explains that editing existing websites would use website.edit. It also provides clear conditions for asset handling and form definitions, and mentions the alternative of workspaceId for team selection versus personal default. The description covers when to use it and what to avoid (e.g., base64 image bytes, data URLs).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Carryo Website Publisher tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?