Skip to main content
Glama

Sync site plan with the site

sync_site_plan

Brings the site plan (.xodia/plan.json) in line with the site on a branch and writes it as an unsaved change, the same as the Plan tab's sync. Xodia reads the site's files (unsaved changes included): pages and their paths, the top-level sections on each page by their data-section ids and in order, the nav and footer links and the theme tokens. The site is the truth for what exists, the plan for intent: pages and sections on the site join the plan, sections follow the site's order, the nav, footer and brand colours and fonts follow the site, and statuses are read from the code. Anything that would drop intent (a built page gone from the site, a removed section with a purpose or notes) is kept for the owner to review in the Plan tab, never removed. With no plan on the branch (or one with no pages), it makes the plan from the site and first stamps missing data-section ids on the page files and the layout (shown in Save like any edit). Use it after you add, rename, remove or reorder pages or top-level sections outside a plan request, when unsure whether the plan matches; requests from Xodia sync on their own when you reply. Answers what changed, what waits for review and the new etag. Nothing is written when the plan already matches. Refuses with site_unreadable when Xodia can't read the site right now (nothing changes; carry on).

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": "sync_site_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
etagNoOptional: the etag from your last get_site_plan; when given and the plan changed since, it answers plan_conflict and writes nothing.
branchNoDefault: the branch the workspace has open. Pass the request's branch when a request names one.
renamesNoPages you renamed or moved in code, old path to new, so the plan moves their entries (purpose, notes, SEO) instead of treating them as a removed page and a new one. Optional: Xodia also matches by page file and section ids.
projectIdYesProject id from list_projects

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations: writes an unsaved change rather than saving, never drops intent (orphaned pages/sections are kept for owner review), bootstraps missing data-section ids into page and layout files when no plan exists, and returns a site_unreadable refusal with no side effects. The annotations already cover the safety profile, and this adds the reconciliation invariants an agent needs.

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?

Front-loaded with the action and outcome, and almost every clause carries operational meaning (site-as-truth rules, bootstrap behavior, refusal case). It is a dense single block, though, and some clauses about data-section ids could be tightened for faster parsing.

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 reconciliation tool with no output schema, the description explains what the answer contains (what changed, what waits for review, the new etag), what happens to conflicting intent, and the failure mode. Nothing essential for correct invocation is missing.

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?

Schema description coverage is 100%, so etag, branch, renames and projectId are already documented in the schema. The description reinforces the etag return value but adds no syntax or format detail for renames beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource — brings .xodia/plan.json in line with the site on a branch — and pins the outcome precisely (an unsaved change, same as the Plan tab's sync). That framing lets an agent tell it apart from get_site_plan (read) and update_site_plan (plan-driven edit) without opening their schemas.

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?

Gives an explicit trigger list (after adding, renaming, removing or reordering pages or top-level sections outside a plan request, or when unsure whether the plan matches) and an explicit exclusion: requests from Xodia sync on their own when you reply. It also notes the no-op case when the plan already matches.

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