Create Web Page

Update Page Meta

page_meta_update

Idempotent

Update internal page title, URL slug, and SEO title/description. For already-published pages, this saves an unpublished latest revision only. Do not call page_publish in the same assistant turn after this edit. Stop and tell the user the draft/preview was updated, then wait for a separate user message that explicitly asks to update the live link, publish, or make the changes public before calling page_publish. Do NOT call page_unpublish either — the live page should stay public; only unpublish when the user explicitly asks to take it down.

Input Schema

TableJSON Schema

Name	Required	Description
`slug`	No	Preferred public URL slug.
`title`	No	Internal page title shown in editor results.
`pageId`	Yes
`seoTitle`	No	SEO <title> tag value.
`editToken`	No
`seoDescription`	No	SEO meta description value.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`slug`	Yes
`title`	Yes
`pageId`	Yes
`status`	Yes
`actions`	Yes
`content`	No
`claimUrl`	Yes
`editToken`	Yes
`expiresAt`	Yes
`isClaimed`	Yes
`nextSteps`	No	Enrichment hints to present to the user. Address 'required' items before publishing.
`canPublish`	Yes
`previewUrl`	Yes
`isPublished`	Yes
`publishedUrl`	Yes
`missingFields`	No
`publishPolicy`	No	For edit tools on already-published pages, this is wait_for_separate_user_request to prevent same-turn publishing.
`liveUpdateMessage`	No	Plain-language instruction explaining that an edit to an already-published page is draft-only and must not be published until a later explicit user request.
`liveUpdateRequired`	No	True after an edit to an already-published page when the public live page still needs page_publish to reflect the latest revision.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the key non-obvious behavior: for already-published pages it saves only an unpublished latest revision and leaves the live page public. It also sets the expectation that the result is a draft/preview update, not a live change.

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

Conciseness5/5

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

The description is longer than average but every sentence carries essential operational instruction. Purpose is front-loaded, and the workflow constraints are sequenced clearly without repetition or filler.

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

Completeness4/5

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

The description addresses the most important contextual traps, especially accidental publish/unpublish, and an output schema exists to cover return values. However, it leaves a small gap by not defining editToken semantics or behavior for pages that are not already published.

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

Parameters3/5

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

The description reiterates title, slug, seoTitle, and seoDescription semantics that the input schema already documents. It does not explain the editToken parameter or clarify how pageId affects published-versus-draft behavior, so it adds little beyond the schema's own 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 opening sentence names the exact verb and resource: 'Update internal page title, URL slug, and SEO title/description.' This is more specific than the generic title and clearly distinguishes the tool's field scope from sibling tools like page_header_update or page_theme_update.

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 forbids calling page_publish in the same assistant turn and instructs waiting for a separate user message asking to publish or make changes public. It also explicitly forbids page_unpublish to keep the live page public, providing clear when-to-use and when-not-to-use guidance.

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

All Create Web Page 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?