Skip to main content
Glama
kuklaph
by kuklaph

Edit Cascade Asset

cascade_edit

Update an existing Cascade CMS asset by sending its full replacement body. Requires the asset id.

Instructions

Edit an existing Cascade CMS asset.

Accepts the full asset body (same envelope shape as cascade_create). The workflow is symmetric when cascade_read is called with read_mode: "raw": modify the raw asset envelope and pass the same envelope back to cascade_edit. Some asset types require a prior cascade_check_out.

Payload conventions:

  • Edit replaces the asset body, so send the full object as read — do not try to send only the fields you are changing.

  • When constructing an edit payload from scratch (not round-tripping a read), still omit optional fields you have no intention of setting; don't invent defaults.

  • Prefer id over path on every id/path pair (metadataSetId over metadataSetPath, etc.). Cascade resolves paths server-side.

  • Text encoding: same rules as cascade_create — rich-text fields must be well-formed XML with only the five XML built-in entities (&, <, >, ", '). See resource cascade://text-encoding.

Args:

  • asset (object, required): Single-key envelope (same as cascade_create). Inner object must include id to identify the existing asset.

Returns: Cascade OperationResult: { success: true } On failure: { success: false, message: "" }

Examples:

  • Use when: "Update a page's metadata" -> Read first with cascade_read; modify asset.page.metadata; pass { asset: asset.asset } back.

  • Use when: "Change a block's structured data" -> { asset: { xhtmlDataDefinitionBlock: { id: "...", structuredData: { ... } } } }

  • Use when: "Rewrite a symlink's target" -> { asset: { symlink: { id: "...", linkURL: "https://new.example.com" } } }

  • Don't use when: The asset doesn't exist — use cascade_create.

  • Don't use when: You want a partial patch — Cascade's edit replaces the asset body; always send the full object.

Error Handling:

  • "Asset not found" when id doesn't resolve

  • "Permission denied" when credentials lack edit rights

  • "Asset is checked out by another user" when the asset is locked

  • "Validation error" when required fields are missing or malformed. Responses are JSON text; structuredContent is authoritative when the response fits. Oversized responses return bounded _cache metadata for cascade_read_response. For cascade_read, read_mode controls preview versus raw Cascade payload shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoThe asset payload to edit. Must include `id` to identify the target asset. Parent-folder fields are ignored on edit — use move to relocate.
Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false) are present. The description adds important behavioral details: edit replaces the entire asset body (not a partial patch), some types require check-out, and error conditions (not found, permission, locked, validation). This goes beyond the annotations, though the replacement behavior could be seen as partially contradicting destructiveHint=false, but it is not a true contradiction.

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 long but well-structured into sections (intro, workflow, conventions, args, returns, examples, don't use, errors). Every sentence adds value; however, some redundancy exists (e.g., error handling is repeated in two places). Front-loaded with the core verb+resource.

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 of editing assets (multiple types, check-out requirement, full replacement semantics), the description covers workflow, parameter structure, return format (OperationResult), and common errors. No output schema exists, but returns are described. For a mutation tool, this is highly complete.

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 coverage is 100% with a single 'asset' parameter. The description adds crucial meaning: 'Must include id to identify the target asset', 'Parent-folder fields are ignored on edit', and payload conventions like preferring id over path. This significantly enhances the bare schema.

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 begins with 'Edit an existing Cascade CMS asset,' which clearly states the verb ('edit') and resource ('Cascade CMS asset'). It explicitly distinguishes from sibling tools like cascade_create, cascade_read, and cascade_move by contrasting when to use this tool vs. others.

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 provides explicit guidance on when to use the tool (examples like 'Update a page's metadata'), when not to use it ('Don't use when: The asset doesn't exist — use cascade_create'), prerequisites ('requires a prior cascade_check_out'), and the recommended workflow (symmetric with cascade_read in raw mode).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kuklaph/cascade-cms-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server