Skip to main content
Glama
kuklaph
by kuklaph

Create Cascade Asset

cascade_create

Creates a new asset (page, file, folder, block, etc.) in Cascade CMS by sending a typed envelope matching the REST API schema. Returns the new asset's ID on success.

Instructions

Create a new asset in Cascade CMS.

The request body wraps a typed envelope under asset — one of 48 envelope keys (page, file, folder, symlink, textBlock, feedBlock, indexBlock, xmlBlock, xhtmlDataDefinitionBlock, twitterFeedBlock, reference, template, xsltFormat, scriptFormat, user, group, role, assetFactory, contentType, destination, editorConfiguration, metadataSet, pageConfigurationSet, publishSet, dataDefinition, sharedField, site, workflowDefinition, workflowEmail, wordPressConnector, googleAnalyticsConnector, fileSystemTransport, ftpTransport, databaseTransport, cloudTransport, and the *Container types). This matches the upstream Cascade REST API Asset schema exactly. Returns the new asset's ID on success.

Payload conventions (apply to every create call):

  • Send ONLY the fields you actually need to set. Every optional field should be omitted unless you have a real value to provide — Cascade applies its own defaults server-side. Do not pad payloads with "reasonable defaults" like reviewOnSchedule: false or shouldBePublished: true when you do not need to override them.

  • For every <thing>Id / <thing>Path pair (parentFolderId vs parentFolderPath, siteId vs siteName, contentTypeId vs contentTypePath, metadataSetId vs metadataSetPath, ...), prefer the id form when you know the id. Path is a valid fallback and Cascade resolves it server-side — don't round-trip through cascade_read just to look up an id.

  • Text encoding: rich-text fields (xhtml, WYSIWYG structuredData text, xmlBlock xml) must be well-formed XML — named HTML entities like   and astral-plane Unicode (including emoji) crash the render. See resource cascade://text-encoding for the per-field-category rules.

Args:

  • asset (object, required): Single-key envelope. Key is the camelCase type; value is the asset body. Common shapes (only required fields shown — add optionals only when you need to set them):

    • { page: { name, parentFolderId OR parentFolderPath, siteId OR siteName, contentTypeId OR contentTypePath, ... } }

    • { file: { name, parentFolderId OR parentFolderPath, siteId OR siteName, text? OR data?, ... } }

    • { folder: { name, parentFolderId OR parentFolderPath, siteId OR siteName, ... } }

    • { textBlock: { name, parentFolderId OR parentFolderPath, siteId OR siteName, text, ... } }

    • { xmlBlock: { name, parentFolderId OR parentFolderPath, siteId OR siteName, xml, ... } }

    • { symlink: { name, parentFolderId OR parentFolderPath, siteId OR siteName, linkURL, ... } } Admin-area types (assetFactory, contentType, transports, workflow*, *Container) use parentContainerId/Path instead of parentFolderId/Path.

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

Examples:

  • Use when: "Create a page under /about" -> { asset: { page: { name: "team", parentFolderPath: "/about", siteName: "www", contentTypePath: "/standard-page" } } }

  • Use when: "Upload a text file" -> { asset: { file: { name: "robots.txt", parentFolderPath: "/", siteName: "www", text: "User-agent: *" } } }

  • Use when: "Create a text block" -> { asset: { textBlock: { name: "greeting", parentFolderPath: "/blocks", siteName: "www", text: "Hello" } } }

  • Don't use when: The asset already exists — use cascade_edit.

  • Don't use when: You want to duplicate an existing asset — use cascade_copy.

Error Handling:

  • "Parent folder not found" when parentFolderId/parentFolderPath is invalid

  • "Asset name collision" when an asset with the same name exists in the parent

  • "Permission denied" when credentials lack create access on the parent

  • "Invalid content type" when contentTypeId/contentTypePath doesn't resolve. 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 create. `type` chooses the branch (page/file/folder/block/symlink get strict validation; other types pass through).
Behavior5/5

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

Beyond annotations (readOnlyHint false, etc.), the description details the creation behavior: returns asset ID, error handling cases (parent folder not found, asset name collision, permission denied), and text encoding warnings. No contradiction with 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 lengthy due to the complexity of handling 48 asset types, but it is well-structured: purpose, payload conventions, shapes, examples, error handling. Could be slightly more concise, but the structure earns a high score.

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 asset types), lack of output schema, and rich annotations, the description covers purpose, usage, parameters, return value, error handling, examples, and alternatives. It is comprehensive.

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 single parameter 'asset' is explained in depth: envelope structure, common shapes for all asset types, required fields, admin-area differences, and payload conventions (prefer IDs, omit optionals). This adds immense value beyond the schema's minimal description.

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 starts with 'Create a new asset in Cascade CMS,' a specific verb+resource. It distinguishes from sibling tools (cascade_edit, cascade_copy) by stating when not to use it.

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 'Use when' examples and 'Don't use when' with alternatives. Also includes payload conventions for every create call, guiding proper usage.

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