Pixelesq

Rename or move page

update_page

Destructive

Rename a page, move it to a new address (slug), or both. The name is what the dashboard lists; the address is the page's path on the site. Moving a published page is live at once: the page is served at the new address and the old address shows not found, because no redirect is made. Confirm a move of a published page with the user first, and afterwards offer a redirect from the old address with create_redirect. The new address must be free: another page, a collection entry, a redirect from that path, or a reserved list-page path (ending in /page/ or containing /filter/) blocks it, and the error names what blocks it and what to do. A page that belongs to a collection entry takes its address from the entry (update_entry). The SEO title and description are update_page_meta.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "projectId": "<projectId>",
      "pageId": "<pageId>"
    },
    "name": "update_page"
  }
}

Input Schema

Name	Required	Description
`name`	No	New page name
`slug`	No	New address as a path that starts with a slash, e.g. /demo. A missing leading slash is added and a trailing one dropped.
`pageId`	Yes	The page ID
`projectId`	Yes	The project ID

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the destructiveHint and openWorldHint annotations, the description discloses the key destructive behavior: moving a published page is live immediately, the old address returns not found, and no redirect is created. It also explains slug-collision blocking rules and that the error identifies the blocker and remedy, which materially improves safe invocation.

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 dense but front-loaded: it states the core action first, then the live-move risk, then alternatives. Every sentence carries operational information, and there is no repetition of schema or annotation details.

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?

For a destructive mutation tool with no output schema, it covers the essential operational context: immediate effect on published pages, confirmation guidance, collision rules, error behavior, and which sibling tools handle adjacent updates. Nothing critical for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds meaningful semantic context for slug beyond the schema by explaining what counts as an unavailable address, including pages, collection entries, redirects, and reserved list-page paths. It also clarifies that name is the dashboard-facing label while slug is the site path.

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 opens with a specific verb and resource: 'Rename a page, move it to a new address (slug), or both.' It also distinguishes the tool from siblings by naming update_entry for collection-entry addresses, update_page_meta for SEO fields, and create_redirect for follow-up redirects.

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?

It gives explicit when-to-use guidance and names concrete alternatives: use update_page_meta for SEO title/description, update_entry when the page belongs to a collection entry, and create_redirect after a move. It also states a clear precondition: confirm a move of a published page with the user first.

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

All Pixelesq 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.