Fabrement

Assign template pages

fabrement-assign-template-pages

Give records this template, or take it away. mode is required. add / remove touch only the ids you pass; replace makes pageIds the exact set and releases every other record that had it — use it when you know the whole set, and list-template-pages first. Works on a record of any public type, not just the ones that take a template by default. For a whole-type frame use set-default-template instead. Rules: get-skill-doc {id:"template-contract"} — read it before the first call.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	Required — there is no default. replace: the set becomes exactly pageIds, and every other record picking this template is released — send it only when you know the whole set. add: these records take the template, everything else is left alone. remove: these records release it, everything else is left alone.
`pageIds`	Yes	The ids this call is about. With mode replace this is the FULL set and anything missing from it loses the template; with add or remove it is only the records to change.
`templateId`	Yes	Template id from list-templates.

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	The mode this call ran in.
`note`	No	Present with tookFrom: what each record left, and how to put it back when that is possible.
`cleared`	Yes	Records released from THIS template. One that changed hands to another template is in `tookFrom`, not here. It counts records INCLUDING any in the trash, which `pageCount` never counts — so clearing a binned pick moves this and leaves `pageCount` where it was.
`assigned`	Yes	Records this call WROTE the template to. One that already carried it is not counted again.
`tookFrom`	No	Records that were carrying a DIFFERENT template and now carry this one. Absent when none did.
`pageCount`	Yes	How many records carry this template AFTER the call — the whole set, not just what this call wrote, so it is normally the larger of the two.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.4/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 disclose the key behavioral trait: replace is destructive — it 'releases every other record that had it'. It also notes the tool works on any public type, not just template-default ones. It stops short of stating permission requirements or rate limits, but the destructive semantics are clearly surfaced.

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 action and the required-mode constraint, then the destructive replace warning, then scope and alternatives. Dense but every clause carries information; the trailing Rules line is a useful prerequisite rather than filler. Slightly heavy for its size but well-structured.

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 complex, high-stakes mutation tool with no annotations, the description covers purpose, destructive behavior of replace, scope, prerequisites, and the relevant siblings. An output schema exists, so return values need no explanation. An agent has everything needed to call it correctly.

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 coverage is 100%, so the schema already documents all three parameters, including the mode enum and the pageIds interpretation. The description reinforces the mode semantics but adds little beyond what the structured fields already say, 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 (assign/give/take away a template) acting on records, and immediately routes the agent to siblings by naming list-template-pages and set-default-template. An agent can distinguish this from set-default-template and list-template-pages without opening the schema.

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 explicit when-to-use for replace ('use it when you know the whole set'), distinguishes add/remove vs replace, and names the alternative for the whole-type case ('use set-default-template instead'). It also states prerequisites: list-template-pages first and read the template-contract skill doc before the first call.

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?