Fabrement

Save single page

fabrement-save-single-page

Create or change a single-page bundle — render.php + optional style.css, view.js, hooks.php — that fills a template's CONTENT area with a layout a block cannot express. Send files whole, or change an existing bundle with edits (fragment replacements per file) + expectedHash from get-single-page. summary is required on every save; description and logic on create and whenever php/js/hooks change. Returns the path a contentSource rule points at. Rules: get-skill-doc {id:"single-page-contract"} — read it before the first call.

Input Schema

TableJSON Schema

Name	Required	Description
`js`	No	view.js contents (enqueued in the footer). Omit to keep; delete with remove.
`css`	No	style.css contents (enqueued when present). Omit to keep; delete with remove.
`php`	No	The complete render.php contents. Required when creating; omit to keep.
`name`	Yes	Bundle slug (lowercase, hyphens; the folder name).
`edits`	No	Fragment replacements per file of the EXISTING bundle, instead of re-sending it. A file is sent whole OR edited, not both.
`hooks`	No	hooks.php — PHP run on `init` before render, on every FRONT-END request (never admin, REST, cron or WP-CLI): the only place to touch the MAIN query (pre_get_posts); every callback guards is_admin(), is_main_query() and the exact view. Omit to keep; delete with remove.
`logic`	No	How it WORKS: the query it runs, the URL params it reads, the meta keys, what an empty result renders. This is what the next session reads instead of your PHP.
`title`	No	Human name shown in the pickers (default: the slug).
`remove`	No	Files to delete: css, js, hooks. An EMPTY value ("") never deletes — it counts as not sent. render.php cannot be removed (delete the bundle instead).
`summary`	Yes	REQUIRED on every save: what you did THIS save. Kept as the bundle history (last 10) — the next session reads it for context.
`contexts`	No	Views this body was written for: "singular:post", "archive:project", "blog-home". A note for the next session and for list-*; nothing enforces it — the platform only checks singular-vs-archive when a rule is wired.
`requires`	No	What it needs to work: {postTypes:[…], meta:[…]}. A note for whoever copies the bundle to another site; nothing checks it at runtime.
`description`	No	What the page SHOWS — how the next session recognises it in a listing.
`expectedHash`	No	`hash` from the get tool. If any file changed since, nothing is saved.

Output Schema

TableJSON Schema

Name	Required	Description
`hash`	No	Of the saved bundle — expectedHash for the next save.
`name`	Yes
`path`	Yes
`hasJs`	No
`logic`	No
`title`	No
`hasCss`	No
`contexts`	No
`hasHooks`	No
`requires`	No
`hasListing`	No
`description`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the concurrency guard (expectedHash — nothing is saved if a file changed), the conditional requirements for summary/description/logic, and the return value. It still omits failure modes and whether an update is overwrite-in-place, but covers the key behavioral traits effectively.

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 purpose, then workflow, then a terse Rules line. Dense but every clause carries information (file list, edits mechanism, hash guard, return value, prerequisite). The opening sentence is long, which is the only structural cost.

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 14-parameter tool with nested edit objects, no annotations, and an output schema, the description supplies the missing workflow context: the read-before-write contract, the whole-vs-edit decision, and the hash precondition. Remaining gaps (failure behavior, idempotency) are minor given the rich schema.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it specifies that summary is required on every save and that description and logic are required on create and whenever php/js/hooks change, and it frames edits as mutually exclusive with whole-file sends.

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 pair (create or change) and a concrete resource (single-page bundle) with its constituent files, and articulates the intent: fills a template's CONTENT area with a layout a block cannot express. This explicitly distinguishes it from the block-oriented sibling fabrement-create-block.

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?

Gives clear when-to-use context (layout a block cannot express) and the conditional workflow: send files whole, or use `edits` + expectedHash from get-single-page for an existing bundle. It also names a prerequisite (read the single-page-contract skill doc before first call). It stops short of explicitly naming sibling alternatives to use instead, so a 4 rather than 5.

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

All Fabrement tools Inspect

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

Need Help?