Skip to main content
Glama
Sign In

PixelGlass

by co.pixelglass
OverviewDiscussionsAdmin

Write a site page

write_site_page
Idempotent

On one site of the account, named in site. A whole file of the site folder, new or replaced: pages/about.liquid answers at /about, pages/about/team.liquid at /about/team, pages/<path>.html is served exactly as written, and assets/<file> at /site/assets/. A .liquid page may open with a front matter block — title, description, layout (theme, the default, or none), noindex — and its front matter and its Liquid are parsed before anything lands: a page that would not render is refused with the line, and the file is left as it was. Read pixelglass://site-pages/contract first. Each write is a commit in the person's name and live at once; site_pages_history and restore_site_pages take it back. Admins only.

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": {
      "site": "<site>",
      "path": "<path>",
      "content": "<content>"
    },
    "name": "write_site_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesThe file inside the site folder, like pages/about.liquid
siteYesThe site to work on, as list_sites names it
contentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations it discloses atomicity ('a page that would not render is refused with the line, and the file is left as it was'), immediate liveness ('live at once'), commit authorship in the person's name, and a restore path. That is substantive context the readOnly/destructive/idempotent hints cannot convey; the whole-file replacement is mitigated by documented history recovery, so it does not contradict destructiveHint=false.

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?

It is dense but nearly every clause carries load-bearing information, and the contract-file prerequisite sits early where an agent will see it. The telegraphic opening ('On one site of the account, named in site') and run-on middle sentence cost some readability.

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 3-parameter write tool with no output schema, the description covers the semantics of every input, the validation/rollback model, permissions, and where to find the formal contract. An agent has everything needed to call it correctly and to recover from a bad write.

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

Parameters5/5

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

Schema coverage is 67% and `content` is undocumented there, but the description compensates fully: it explains path routing for .liquid, .html and asset files, and lists the front-matter keys (title, description, layout with theme/default/none, noindex) that belong in `content`. This adds real meaning well beyond the schema.

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 states a precise verb and resource ('write' a 'whole file of the site folder, new or replaced') and enumerates exactly how each path shape maps to a served URL. The phrase 'new or replaced' implicitly distinguishes this upsert from edit_site_page, so an agent can select it without opening either schema.

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 gives a strong explicit prerequisite ('Read pixelglass://site-pages/contract first'), a permission gate ('Admins only'), and points to site_pages_history and restore_site_pages for rollback. It stops short of naming edit_site_page as the alternative for partial edits, so the when-not/when-alternative guidance is good but not exhaustive.

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

All PixelGlass toolsInspect
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.

Resources