Skip to main content
Glama
vuluu2k

WebCake Landing MCP

by vuluu2k

add_section

Append new sections to a page without resending the entire source. Dry-run validation prevents errors before committing.

Instructions

Appends one or more SECTIONS to an existing page WITHOUT re-sending the whole source — the incremental-build path that avoids large create_page payloads. The backend appends section(s) to the END of page server-side and rejects duplicate element ids, so the caller sends only the new section(s) (no whole-source get+put). DEFAULTS to dry_run=true (validates the section(s) + previews the request; caches the payload as draft_id so you never have to re-send sections between dry-run → real call); dry_run=false to actually append. On validation failure also returns a draft_id — call patch_page({ draft_id, patches, dry_run:false }) to fix ONLY the bad elements without rebuilding the batch. Needs WEBCAKE_API_BASE + WEBCAKE_JWT.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoDefault TRUE — validate the section(s) and preview the request without writing. Set false to actually append.
page_idYesThe page id to append to (from create_page or list_pages; must be owned by the account).
draft_idNoA draft id returned by a previous add_section call (dry_run=true or validation failure). Loads the cached section payload — no need to re-send the sections JSON. Use for dry-run → real call transitions and fix-after-error rounds.
sectionsNoOne section node, or an array of section nodes, to append to the END of `page` (object/array or JSON string). Each is a normal section element { id, type:'section', responsive, children, … } with a UNIQUE id; they stack vertically after the existing sections. Author SPARSE nodes — omit properties/runtime/empty events+children/per-breakpoint config; the server hydrates them from factory defaults. Required unless draft_id is supplied.
Behavior5/5

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

Annotations are minimal, so the description carries full burden. It discloses that the backend appends to the end, rejects duplicate element ids, defaults dry_run=true, caches payload as draft_id, and returns draft_id on validation failure. It also requires WEBCAKE_API_BASE and WEBCAKE_JWT, providing ample behavioral context.

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 a single dense paragraph that covers all aspects, though it repeats the dry_run explanation and could benefit from bullet points for readability. It is front-loaded with the core action but lacks structure.

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

Completeness3/5

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

No output schema is provided, and the description does not mention what successful real call returns (e.g., updated page or status). It assumes knowledge of 'sparse nodes' and 'factory defaults', and does not explain return values. This leaves gaps for an AI agent.

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%, but description adds significant meaning: for 'sections', it explains sparse nodes and server hydration; for 'dry_run', it clarifies default and purpose; for 'draft_id', it describes cache usage. This goes beyond the schema's basic descriptions.

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 tool appends sections to an existing page without re-sending the whole source, distinguishing it from create_page. It specifies the verb 'appends' and the resource 'SECTIONS to an existing page', and contrasts with the 'incremental-build path' that avoids large payloads.

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 explains when to use this tool (for incremental section addition), when not to (instead use patch_page for fixing errors), and provides alternatives (calling patch_page with draft_id). It also details the dry-run vs. real call workflow and how to handle validation failures.

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/vuluu2k/webcake-landing-mcp'

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