Skip to main content
Glama
Sign In

Xodia

by ai.xodia
OverviewDiscussionsAdmin

Get site plan

get_site_plan
Read-only

Reads the site plan (.xodia/plan.json) on a branch: a short summary (title, pages by status, the sitemap tree with each page's status and section count, the shared nav and footer, motion, inspiration sites still to study, pages changed since they were wireframed or built, open plan requests, and with sinceEtag what changed since that read), then the site as it is now (every page with its file, status and top-level sections by data-section id, the nav and footer links, the theme tokens) and how the plan compares with it (in sync, changes on the site the plan doesn't have yet, items waiting for the owner's review, plan changes not built yet), then the whole plan as JSON and its etag for update_site_plan, then Xodia's section library (types and their layouts) and page templates: short by default, every layout's build note with catalogue "full". Page statuses come from the site: a page is built when its route exists with real sections, wireframed while a section is still marked data-placeholder, planned when it isn't on the site. Reads only, writes nothing: sync_site_plan applies the changes. Says so when there is no plan yet (sync_site_plan makes one from the site), and lists the problems when the file isn't valid. Skills site-plan and section-layouts say how to fill and follow it.

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>"
    },
    "name": "get_site_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
typesNoWith catalogue "full": only these section types (like ["hero", "pricing"]); unknown names are listed as such
branchNoDefault: the branch the workspace has open. Pass the request's branch when a request names one.
catalogueNoThe section library and page templates under the plan. "short" (default): each type's layout ids and each template's stack. "full": every layout's one-line build note, each template's purpose and the motion intents; pass types to list only some. "none": leave them out (when you already have them).
projectIdYesProject id from list_projects
sinceEtagNoThe etag from your last get_site_plan or update_site_plan. When the plan changed since, the summary lists the pages added, removed and changed, and whether the nav and footer or other parts changed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

The annotations already declare readOnlyHint and destructiveHint=false, and the description adds genuinely new behavior: how page statuses are derived (built = route exists with real sections, wireframed = data-placeholder section, planned = not on site), what happens when no plan exists, and that invalid files yield a problem list rather than an error. It also explains the sinceEtag diff semantics. This is context the agent cannot get from the structured fields.

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

Conciseness3/5

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

The description is a single sprawling sentence-chained paragraph of roughly 250 words with nested parenthetical lists, which makes it hard to scan quickly. It is front-loaded with the resource and contains little true filler, but the structure works against fast comprehension for a tool an agent may call repeatedly.

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?

There is no output schema, so the description carries the full burden of explaining return content, and it does so exhaustively: summary contents, current site shape, plan-vs-site comparison, raw plan JSON and etag, and the section library/template levels. Edge cases (no plan, invalid file) and the read-only guarantee are covered, so nothing needed to call it correctly 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, and the description earns above that by explaining the effect of catalogue "full" (every layout's build note) and that types narrows the library with unknown names reported. sinceEtag behavior is described in the schema and reinforced in prose. It adds meaning rather than repeating syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a specific verb and resource: reading the site plan (.xodia/plan.json) on a branch, then documents the three-part payload (plan summary, current site, comparison). It clearly positions itself against sync_site_plan and update_site_plan, so an agent can tell what it is and is not, but the purpose statement is buried under a long enumeration of returned fields rather than stated crisply up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the alternatives and the condition that selects them: 'Reads only, writes nothing: sync_site_plan applies the changes', and notes sync_site_plan creates a plan when none exists. The catalogue "none" parameter also documents when to skip the library 'when you already have them'. There is no explicit statement of when to call this tool at all (e.g., before any plan edit), but the routing to siblings is clear.

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