Carryo Website Publisher

Edit Website Images

website.edit_images

Destructive

Adds, replaces, or removes hosted images on an existing Carryo website without replacing its HTML. Reusing a path replaces that image without consuming another image slot; new paths are subject to the website image allowance. Returns hosted-image metadata and URLs. New paths appear in the page when referenced by its HTML. Pass attached images through imageFiles. For one attachment, assets needs only its relative website path; Carryo matches the attachment automatically. For multiple attachments, use fileIndex (0 for the first imageFiles entry). Do not invent file IDs or ask for a public URL when attachment upload is available. Known fileId references and fetchable HTTP(S) sourceUrl imports also work. Carryo imports and hosts its own copy. Base64 image bytes and data URLs are unsupported.

Input Schema

TableJSON Schema

Name	Required	Description
`assets`	No	Optional image assets to add or replace. Each entry requires a relative website path. With one imageFiles attachment, path alone uses that attachment. Otherwise select exactly one source: fileIndex (zero-based imageFiles position), a known fileId, or a fetchable HTTP(S) sourceUrl. Never guess generated file IDs. Existing images are preserved when omitted; replacing an existing path does not use another slot. Base64 bytes and data URLs are unsupported.
`linkId`	Yes	Carryo page link identifier to update
`imageFiles`	No	Optional image attachments supplied through the host's file upload support. The host supplies file_id and download_url. Map each attachment to a website path in assets: with one attachment, path alone is sufficient; with multiple attachments, use fileIndex. The assistant does not need to know generated file IDs or download URLs. Temporary URLs are import sources, not hosted image URLs. Clients without file input support can omit this field.
`removeAssetPaths`	No	Optional relative asset paths to remove from the page asset bundle.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No
`forms`	No
`linkId`	No	Carryo page link identifier
`status`	No
`message`	No
`guidance`	No
`shareUrl`	No	Primary share URL
`assetUrls`	No	URLs for added or replaced assets
`updatedAt`	No	ISO-8601 update timestamp
`currentVersionNumber`	No
`publicationPerformed`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 25, 2026

changedInput schema / properties / assets / description

Previous value: -"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."New value: +"Optional image assets to add or replace. Each entry requires a relative website path. With one imageFiles attachment, path alone uses that attachment. Otherwise select exactly one source: fileIndex (zero-based imageFiles position), a known fileId, or a fetchable HTTP(S) sourceUrl. Never guess generated file IDs. Existing images are preserved when omitted; replacing an existing path does not use another slot. Base64 bytes and data URLs are unsupported."

changedInput schema / properties / assets / items / properties / fileId / description

Previous value: -"Attachment file_id matching a host-supplied imageFiles entry. Mutually exclusive with sourceUrl."New value: +"Known attachment file_id matching an imageFiles entry. Prefer fileIndex if the host-generated ID is not visible. Mutually exclusive with fileIndex and sourceUrl."

addedInput schema / properties / assets / items / properties / fileIndex

Added value: +{
+  "description": "Zero-based position in imageFiles: 0 selects its first attachment. Use this when the host generates file IDs during upload. May be omitted when imageFiles contains exactly one attachment. Mutually exclusive with fileId and sourceUrl.",
+  "maximum": 19,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / assets / items / properties / sourceUrl / description

Previous value: -"Fetchable HTTP(S) image URL for Carryo to import and host. Mutually exclusive with fileId. Data URLs and base64 bytes are unsupported."New value: +"Fetchable HTTP(S) image URL for Carryo to import and host. Mutually exclusive with fileId and fileIndex. Data URLs and base64 bytes are unsupported."

changedInput schema / properties / imageFiles / description

Previous value: -"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."New value: +"Optional image attachments supplied through the host's file upload support. The host supplies file_id and download_url. Map each attachment to a website path in assets: with one attachment, path alone is sufficient; with multiple attachments, use fileIndex. The assistant does not need to know generated file IDs or download URLs. Temporary URLs are import sources, not hosted image URLs. Clients without file input support can omit this field."

First observedSep 10, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description elaborates further: reusing a path does not consume an image slot; new paths are subject to allowance; images are hosted by Carryo (imports); and unsupported formats are disabled. This adds significant behavioral detail beyond the annotations.

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 well-structured, starting with the core action and quickly giving the most important constraint (reuse vs. new paths). It then covers attachment handling in a logical order. It's a bit long but every sentence contributes; no fluff.

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 tool's complexity (multiple ways to specify sources, slots, removal, output schema providing return info), the description covers everything an agent needs: how to use attachments, when to use each source type, restrictions, and the fact that it returns metadata. The output schema handles return values, so no missing pieces.

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?

The schema has near-complete descriptions for all parameters, but the description adds crucial operational meaning: how to map attachments to paths, the semantics of fileIndex (0-based), and the interaction between assets and imageFiles. It clarifies that fileId is only for known IDs and not to be guessed.

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 description clearly states the verb ('Adds, replaces, or removes') and resource ('hosted images on an existing Carryo website'), and distinguishes it from website.edit by noting it does not replace the HTML. It also covers key behavior like slot usage and return values.

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?

Provides explicit when-to-use guidance: for adding/replacing/removing images on a website, with alternatives clearly implied (use website.edit for full HTML editing). It gives detailed instructions on how to handle attachments (single vs multiple, fileId vs fileIndex) and what not to do (don't invent IDs or ask for public URL).

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?