Skip to main content
Glama
Sign In

Xodia

by ai.xodia
OverviewDiscussionsAdmin

Create a page

create_page

Adds a page the way the Pages panel does, on a Xodia template site: a page file that mirrors its folders (src/pages/services/web/Design.tsx) and its route in src/routes.tsx at //, inside the site's layout, with a starter section (data-section="page-header": the title tag, the h1 and a line to replace). parent is the folder it goes in; folderPage true makes the page at that folder's own address, with its file inside the folder (src/pages/what-we-do/WhatWeDo.tsx) and a starter list of links to the folder's pages to edit. 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). Refused with plan_limit past the plan's page limit, and with add_unsupported on sites whose pages are set up in code (add the route by hand there, skill create-page). Never write the route or page file yourself on a template site. A page per collection item is never a page: create_collection makes the collection page. 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": {
      "title": "<title>",
      "projectId": "<projectId>"
    },
    "name": "create_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoOptional: the last part of the address (lowercase, dashes); default from the title
titleYesThe page's name: its h1, its title tag and its label in the Pages panel
branchNoOptional branch; default the branch the workspace has open
parentNoThe folder the page goes in ("services" or "services/web", up to 5 levels); omit for the site root. Missing folders are made by the address
projectIdYesProject id from list_projects
folderPageNotrue: the page at the parent folder's own address (/services), its folder page. slug is ignored

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-destructive, closed-world; the description adds substantial behavior beyond them, notably that changes are written as unsaved edits the user reviews and saves, that the site plan is updated in the same change, and the exact content of the starter section. However, it does not describe the response payload or how a partial failure (e.g., clash created after folder creation) surfaces.

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?

Purpose is front-loaded and the word count is justified by the tool's complexity, with concrete path examples rather than vague prose. It loses a point for being a single dense paragraph of long sentences with no separation between the create semantics, address rules, and refusal modes, which makes it harder to scan.

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?

For a mutation tool with no output schema and a template-site-specific workflow, the description covers creation semantics, address validation, clash/limit handling, the unsaved-changes review step, and sibling boundaries. The main residual gap is what a successful call returns (created page identity/address), which the agent needs to chain into follow-up calls.

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 baseline is 3, but the description adds real meaning: address rules (lowercase words with dashes, max 5 folder levels), that missing folders are created by the address, and that slug is ignored when folderPage is true because the page takes the folder's own address. These clarify interaction between parent, slug, and folderPage beyond what either field documents alone.

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?

"Adds a page the way the Pages panel does, on a Xodia template site" gives a specific verb, resource, and mechanism, then immediately names the artifacts produced (page file mirroring folders, route in src/routes.tsx, starter section). It actively separates itself from siblings, saying a per-item page is not a page and pointing at create_collection, and warning not to hand-write routes on a template site.

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?

Explicit routing rules are stated for each ambiguous case: use create_collection for per-item pages, use the create-page skill plus manual route on non-template sites, and never write the route or page file yourself on a template site. It also enumerates the refusal conditions (address_clash, plan_limit, add_unsupported) so the agent knows when not to call.

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

All Xodia toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources