Skip to main content
Glama

Fabrement

Save archive page

fabrement-save-archive-page

Create or change an ARCHIVE bundle — render.php looping the MAIN query (+ optional style.css, view.js, hooks.php, listing.php) — that fills a template's CONTENT area on an archive view. Send files whole, or change an existing bundle with edits (fragment replacements per file) + expectedHash from get-archive-page. summary is required on every save; description and logic on create and whenever php/js/hooks change. Returns the path for a contentSource rule; then assign-template-archive. listing.php is the OTHER way into the same bundle: the rows alone, included by the archive-list block wherever it sits in the archive record's content, so the rows land between blocks arranged in the editor. render.php reaches that file with fabrement_listing(). Rules: get-skill-doc {id:"archive-page-contract"} — read it before the first call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsNoview.js contents (enqueued in the footer). Omit to keep; delete with remove.
cssNostyle.css contents (enqueued when present). Omit to keep; delete with remove.
phpNoThe complete render.php contents (loops the main query). Required when creating; omit to keep.
nameYesBundle slug (lowercase, hyphens; the folder name; unique across single AND archive bundles).
editsNoFragment replacements per file of the EXISTING bundle, instead of re-sending it. A file is sent whole OR edited, not both.
hooksNohooks.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.
logicNoHow 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.
titleNoHuman name shown in the pickers (default: the slug).
removeNoFiles to delete: css, js, hooks, listing. An EMPTY value ("") never deletes — it counts as not sent. render.php cannot be removed (delete the bundle instead).
listingNolisting.php — the ROWS ALONE, a second way into this bundle. The archive-list block, placed in the archive record's content, includes this file at its position, so the rows sit between blocks arranged in the editor instead of render.php owning the whole content area. It prints the listing and nothing around it: no page furniture, no fabrement_archive_content() — those are already drawn around it. render.php reaches the same file with fabrement_listing(), so write the rows here once rather than in both. Omit to keep; delete with remove.
summaryYesREQUIRED on every save: what you did THIS save. Kept as the bundle history (last 10) — the next session reads it for context.
contextsNoViews 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.
requiresNoWhat it needs to work: {postTypes:[…], meta:[…]}. A note for whoever copies the bundle to another site; nothing checks it at runtime.
descriptionNoWhat the page SHOWS — how the next session recognises it in a listing.
expectedHashNo`hash` from the get tool. If any file changed since, nothing is saved.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hashNoOf the saved bundle — expectedHash for the next save.
nameYes
pathYes
hasJsNo
logicNo
titleNo
hasCssNo
contextsNo
hasHooksNo
requiresNo
hasListingNo
descriptionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/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 so: it discloses the optimistic-concurrency behavior ('if any file changed since, nothing is saved'), the edits all-or-none semantics, that summary is required on every save while description/logic are required on create and on php/js/hooks changes, and that hooks.php runs on every front-end request but never admin/REST/cron/WP-CLI.

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 and mode, then the file roles, then the contract-doc rule; every sentence carries information. It is dense and the listing.php explanation partly duplicates the schema's own listing description, so it is not maximally tight.

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 15-parameter, nested-schema mutation tool with an output schema, the description covers the file model, the create-vs-edit decision, required metadata, hash conflict handling, and the workflow handoff. Nothing an agent needs 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, but the description adds real meaning: it explains the whole-file-vs-edits choice, the required/conditional status of summary, description and logic, and the rule that render.php cannot be removed while an empty remove value counts as not sent. It stops short of restating the per-mode edit syntax, which the schema already covers.

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 ('Create or change an ARCHIVE bundle') plus what it produces (fills a template's CONTENT area on an archive view) and which files it comprises. It also distinguishes the two entry points into the bundle (render.php vs listing.php) and names the sibling it hands off to (assign-template-archive) and the read tool (get-archive-page).

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 the two modes explicitly ('Send files whole, or change an existing bundle with edits + expectedHash'), states prerequisites ('read archive-page-contract before the first call'), and describes the follow-up step ('Returns the path for a contentSource rule; then assign-template-archive'). Alternatives and ordering are spelled out rather than implied.

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