Skip to main content
Glama

save_user_template

Idempotent

Save the user's PDF format — one template per account, applied automatically to every PDF the backend renders for them from now on.

STEP 2 OF 2 after `draft_user_template`. Two ways to call it:

SIGNED-OFF (the normal path): pass `draft_id` and the `variant_id` the user chose
from the previews. The EXACT treatment they looked at is stored — no second
adaptation pass that could produce something they never saw. `template`,
`template_type` and `anchor` are taken from the draft and may be omitted. A 404
means the draft expired (24h) or the variant does not exist: draft again.

DIRECT (no previews): pass `template` + `template_type` (+ `anchor` for an
add_on) — only when the user explicitly wants to skip the previews. An add_on
saved this way still gets an unreviewed harmonise pass, so prefer the signed-off
path for anything visual. HTML only: markdown is rejected with a 422.

ONE TEMPLATE PER USER — this is an UPSERT: saving replaces whatever was saved
before, with no history. Call `get_user_template` first and confirm with the user
before overwriting an existing format. To change a saved format afterwards, use
`update_user_template` (any field, or none to recompile it as stored).

WHAT CHANGES AFTERWARDS: the backend renders every PDF it builds for this user —
`get_latest_report` renders of fresh plans, `generate_report_for_stock` rebuilds
(standard and custom) and scheduled reports — through the saved format. The template is a blueprint (stylesheet, page chrome, one
pattern per content kind) applied to the document's own content: nothing is
filled in by hand, and no other call changes. When you compose a PDF yourself
from Flexreport data, `get_user_template` returns the markup to lay it out in.

Asynchronous: returns {"task_id", "status": "PENDING", "next_step"}. Poll
`get_task_status(task_id)`; the finished result is {"status": "SAVED",
"template_type", "anchor", "bytes", "patterns": [content kinds the design styles],
"tones": {positive | negative | neutral | accent: css class}, "warnings"}. Tell
the user which content kinds their design styles. A warning "keeping the
previously compiled blueprint" means the new compile was rejected and the
previous blueprint stays in force; the markup itself is still saved. Validation
failures are a 422 with `detail.errors` listing each problem.

Requires auth (your MCP client attaches the OAuth bearer automatically).
Rate-limited 100/min.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
anchorNoDirect path, add_on only (required there): the section it applies to, e.g. "technical".
draft_idNoSigned-off path: the draft_id from draft_user_template's finished task. Pass with variant_id.
templateNoDirect path only: the HTML template (markdown is a 422). Omit on the signed-off path — the draft supplies it.
variant_idNoSigned-off path: the variant_id the user chose from the previews. Pass with draft_id.
template_typeNoDirect path only (required there): "add_on" or "bespoke".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYesTask state at dispatch, normally "PENDING".
changedNoupdate_user_template only: the fields that were updated.
task_idYesCelery task id; poll it with get_task_status for the result.
next_stepNoWhat the finished task returns.

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?

Annotations only establish readOnly=false/idempotent=true/destructive=false; the description goes well beyond that, disclosing the UPSERT-with-no-history overwrite risk, the async return contract, the 404-on-expiry and 422 rejection modes, the 'keeping the previously compiled blueprint' warning semantics, downstream rendering effects, auth, and a rate limit. (Minor tension worth noting: an overwrite with no history is close to the line for `destructiveHint: false`, but the author surfaces the risk explicitly rather than hiding it.)

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?

Well front-loaded (purpose, then the two call paths) and sectioned into digestible blocks, with no filler sentences. It is long, and the 'WHAT CHANGES AFTERWARDS' paragraph could be tightened, but the length is driven by genuinely useful behavioral detail rather than padding.

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 five-parameter upsert with async execution and an existing output schema, the description covers call paths, error modes, the poll-then-read result contract, and downstream effects. An agent has everything needed to call it correctly without opening other tools.

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: which parameters belong to which call path, that `template`/`template_type`/`anchor` are taken from the draft on the signed-off path, that `anchor` is required only for `add_on`, and that markdown input is a 422. It stops short of full parameter-level detail only because the schema already carries it.

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 first sentence names the exact verb+resource (save the user's PDF format) and the cardinality rule (one template per account, applied automatically to every PDF the backend renders). It is immediately distinguishable from `draft_user_template`, `update_user_template`, `get_user_template`, and `delete_user_template`, all of which appear as siblings.

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?

It gives explicit routing: SIGNED-OFF (normal) vs DIRECT (only when skipping previews), names the required parameters for each path, and states the exclusions. It also says to call `get_user_template` first and confirm before overwriting, and to use `update_user_template` to change an existing format afterwards — when-to-use, when-not, and alternatives are all covered.

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