Skip to main content
Glama

Fabrement

by com.fabrement.demo
OverviewDiscussionsAdmin

Save content

fabrement-save-content

Create a page/post/custom-type record from deployed blocks, or UPDATE one by contentId. There is no status argument: a new record is always a DRAFT, an update keeps its status, and publishing is set-content-status, after the user agrees. mode is REQUIRED and has no default: create (new record, no contentId) · add (blocks are ADDED after the body already there) · replace (the body becomes exactly blocks) · edit (change part of it through edits). Title applies when given. blocks[] entries are {name: registered Fabrement block, attributes} or {markup: core-block markup for prose}. list-content BEFORE creating; get-content BEFORE changing a record. To change part of a body use mode "edit" with edits (update/text/insert/replace/remove/move by index + name) and expectedHash — never re-send every block for a small change. parent nests a record under another of a hierarchical type; menuOrder orders siblings. Rules: get-skill-doc {id:"content-contract"} — read it before the first call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesRequired — there is no default. create: a NEW record; contentId must be absent. The other three act on an existing contentId. add: `blocks` are ADDED AFTER the body already there — this is how a record ends up holding two copies of itself when replace was meant. replace: the body becomes exactly `blocks`. edit: change part of the body through `edits`, without re-sending every block.
slugNoURL slug. Omitted: derived from the title on create, kept on update. Give it when the address matters. Also when the title is not Latin: a Cyrillic title becomes a percent-encoded URL. Changing it on a published record moves that page.
editsNomode "edit" only. Applied in order to the body get-content returned; all or none.
titleNoTitle for the new record; on update (contentId set) renames it when given.
blocksNoOrdered list of blocks to insert. EMPTY creates an empty record — what the posts-index page needs, since WordPress replaces its content with the loop.
parentNoParent record id — hierarchical types only (list-post-types `hierarchical`: pages, and custom types made hierarchical). The record then lives at /parent-slug/its-slug/. Same type, not in the trash, not the record itself or one of its children. 0 = top level. Create: default 0. Update: absent = kept.
excerptNoShort plain-text summary for cards, archives and search — a body of Fabrement blocks yields NO automatic excerpt, so set it whenever the record will be listed. On update: given = replaced, "" = cleared, absent = kept.
postTypeNoType for the NEW record — any public type from list-post-types; default "page".
contentIdNoExisting record id (list-content) to UPDATE. Omit to create a new one.
menuOrderNoPlace among records with the same parent (WordPress "Order"): lower first, ties by title. Page lists and list-content {orderby:"menuOrder"} follow it. Create: default 0. Update: absent = kept.
expectedHashNomode "edit": `hash` from get-content. If the body changed since, nothing is saved.
featuredImageNoAttachment id (upload-media / list-media) for the featured image — the thumbnail cards and archives show. Must be an image; on update absent = kept.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesPublicly reachable only when status is "publish".
noteYes
slugNoThe slug as stored — sanitised, and suffixed when the address was taken.
blocksYesWhat was actually written, in order.
parentNoParent id AS STORED; 0 = top level.
statusYesStatus AFTER the call, read back from WordPress: "draft" for a new record, unchanged on update.
editUrlYes
excerptNoThe summary as stored AFTER the call — empty means this record still has none.
contentIdYesNew on create, the same one back on update. Feeds set-post-terms and update-site-settings.
menuOrderNo
featuredImageNoThe featured image AFTER the call; id 0 = none is set.

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 behavioral burden and does so: new records are always DRAFT, updates keep their status, `mode` is REQUIRED with no default, `edit` is all-or-none and guarded by expectedHash, and `add` is flagged as the trap that duplicates a body. It even states the skill-doc read requirement before the first call.

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 core create/update purpose, and the dense · separated clauses are efficient for a 12-parameter tool. There is some redundancy — the mode enumeration and semantics are re-explained in the schema — but little is wasted given the tool's complexity.

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?

An output schema exists so return values need not be described. For a mutation tool with no annotations and 12 parameters, the description covers the safety-relevant behavior (draft status, hash guard, add-vs-replace pitfall), prerequisites, and nesting/ordering — 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 meaning beyond it: it explains what each mode does to the body, that `parent` nests under a hierarchical type, that `menuOrder` orders siblings, and that `title` applies when given. The mode semantics are largely restated from the schema, which caps this at 4 rather than 5.

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+resource pair ('Create a page/post/custom-type record from deployed blocks, or UPDATE one by contentId') and distinguishes create from update in the first clause. It also carves out what this tool is NOT (publishing is set-content-status), separating it cleanly from siblings like set-content-status and get-content.

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?

Explicit prerequisites are given ('list-content BEFORE creating; get-content BEFORE changing a record') and the correct mode is prescribed for the partial-change case ('To change part of a body use mode "edit" with `edits` ... never re-send every block for a small change'). It also routes publishing to the right sibling only 'after the user agrees', leaving nothing to inference.

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

All Fabrement 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