Flexreport Finance

update_user_template

Idempotent

Change your saved PDF template — any field, or none to recompile it as stored.

Complements `draft_user_template` (preview), `save_user_template` (create) and
`delete_user_template` (remove). Every argument is optional; a field you omit
keeps its stored value, and the result is compiled into a blueprint again:
  - a VISUAL change: draft the new page with `draft_user_template`, show the
    previews, then pass the chosen `draft_id` + `variant_id` here (both or
    neither);
  - a change without previews: pass `template`, `template_type` and/or
    `anchor` directly (HTML only — markdown is rejected with a 422);
  - NO arguments: recompiles the stored template with the current compiler —
    how a saved design picks up an improved compile without resubmitting it.

Async: returns {"task_id", "status": "PENDING", "changed": [the fields that
were updated], "next_step"} — poll `get_task_status` for {"status": "SAVED",
"patterns", "tones", "warnings"}. A 404 means nothing is saved yet (use
`save_user_template` first); a 422 lists validation errors in `detail.errors`.

Requires auth (your MCP client attaches the OAuth bearer automatically).

Input Schema

TableJSON Schema

Name	Required	Description
`anchor`	No	New add_on section, e.g. "technical". Omit to keep the stored one.
`draft_id`	No	Visual change: the draft_id from draft_user_template's finished task. Pass with variant_id.
`template`	No	New HTML template without previews (markdown is a 422). Omit to keep the stored one.
`variant_id`	No	Visual change: the variant_id the user chose from the previews. Pass with draft_id.
`template_type`	No	New type, "add_on" or "bespoke". Omit to keep the stored one.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Task state at dispatch, normally "PENDING".
`changed`	No	update_user_template only: the fields that were updated.
`task_id`	Yes	Celery task id; poll it with get_task_status for the result.
`next_step`	No	What the finished task returns.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation profile is known. The description adds real value beyond that — async task_id/PENDING flow, get_task_status polling, 404 = nothing saved, 422 = detail.errors — but partially overlaps the idempotent/stored-value semantics the hints already imply. Strong supplementary context, though the async and error details are the main non-annotation contributions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core verb/resource, then uses a clean bulleted structure for the three usage modes, and closes with async/error/auth notes. Every sentence carries routing or behavioral information; no filler.

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, yet the description still explains the async return shape and the polling path, plus the 404/422 failure meanings and the automatic OAuth requirement. For a 5-param, all-optional mutation tool this is complete.

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 schema already documents each parameter including the markdown-422 note and the draft_id/variant_id pairing. The description's added value is framing the parameters into coherent workflows ('both or neither', 'any field or none to recompile'), which contextualizes how the optional fields combine rather than repeating definitions.

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 ('Change your saved PDF template') and resource, and immediately distinguishes itself from `draft_user_template`, `save_user_template`, and `delete_user_template` by naming each. An agent can route among the four siblings without opening any 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?

Provides an explicit decision tree: visual change (draft then pass draft_id+variant_id), change without previews (pass template/template_type/anchor), and no-arguments recompile. Each branch states the condition that selects it, 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 Flexreport Finance 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?