Skip to main content
Glama

Move a page

move_page
Destructive

Moves or renames a page (another folder, another slug, or both) in one change: its route, its file on template sites (src/pages mirrors the folders, imports follow), every internal link to it in the site's code and CMS items (Link to, a href, the nav and footer), a redirect from the old address when it was published, and the site plan's entry (purpose, notes and SEO move with it). Works on template sites and Vite React sites whose routes are written as literal paths; the home page and pages with a variable part keep their address (collection pages move with update_collection settings.urlFolder). Addresses are lowercase words with dashes, up to 5 folder levels; an address another page, folder or collection uses is refused with address_clash and the reason (a collection's item level, /blog/, belongs to its items unless the collection reserves that slug). dryRun says what would change first. Never move a page by editing routes by hand. Writes unsaved changes the user reviews and saves in Xodia, and the site plan follows in the same change.

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": {
      "from": "<from>",
      "to": "<to>",
      "projectId": "<projectId>"
    },
    "name": "move_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesIts new address ("/company/about"): another folder, another slug, or both
fromYesThe page's current address ("/about")
branchNoOptional branch; default the branch the workspace has open
dryRunNoOnly say what would change (files, links, redirects); writes nothing
redirectNoOmit: a redirect from the old address only when the page was published (saved before this change); true: always; false: never
projectIdYesProject id from list_projects

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The annotations already flag destructive and non-read-only, and the description goes well beyond them: it discloses the exact side effects (file move, import rewrites, link rewriting in code and CMS items, redirect creation, site-plan follow-along), the address_clash refusal with reason, and that writes are unsaved changes the user reviews in Xodia. This is unusually rich behavioral context for a mutation tool.

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 content is front-loaded and nearly every clause carries information an agent needs (side effects, exceptions, clash behavior). It is dense to the point of being a single long paragraph with stacked parentheticals, which slightly hurts scannability but not substance.

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?

With no output schema, the description must carry the behavioral burden, and it does: it covers side effects, failure modes (address_clash), preview mode, redirect defaults, and the unsaved-changes review model. An agent could call this correctly and interpret results without additional context.

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 would be 3, but the description adds real semantics: redirect's default is conditional on prior publication, and dryRun previews files/links/redirects. Address constraints (lowercase words with dashes, up to five folder levels) also enrich 'to'. The from/to relationship is made explicit as folder change, slug change, or both.

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 names a specific verb (move/rename) and resource (page), and enumerates exactly what changes: route, file location, imports, internal links, redirect, and site-plan entry. It is clearly distinguishable from siblings like move_file and update_collection, the latter of which is explicitly cited for collection pages.

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 states supported site types (template sites and Vite React sites with literal route paths), the exceptions (home page and pages with variable segments keep their address; collection pages move via update_collection settings.urlFolder), and a prohibitive rule (never edit routes by hand). That is explicit when-to-use and when-not guidance tied to concrete alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources