io.github.JC7333/mandatia

Overview Schema Source Related Servers Discussions Admin

prepare_mandate_pdf

Generate a deterministic PDF of a mandate for the principal to sign with their own signature tool. It embeds the exact mandate JSON and SHA-256 hash on every page.

Instructions

Return the mandate as a PDF for the principal to sign with its own signature tool.

Takes the same arguments as create_mandate (and prepare_mandate_signature). Nothing is written. The PDF shows the mandate and carries, as the attached file amr-mandate.json, the exact bytes prepare_mandate_signature returns for the same arguments and signed_at; the SHA-256 of these bytes is printed on every page. The same arguments and signed_at always give the same PDF.

The registry does not sign this PDF and does not check a signature made on it in this version: the principal signs it with its own tool (for example a PAdES signature), and keeps the signed file. An agent cannot sign in the principal's place. create_mandate accepts signed_at only within AMR_PRINCIPAL_SIGNATURE_MAX_AGE_SECONDS (default 900 s) of its clock: generate, sign and register within that window, or generate a new PDF. The PDF matches a registered mandate only if that mandate was created with the same arguments, the same signed_at and a principal signature.

Args: signed_at: ISO 8601 timestamp with timezone to place in the content. Default: now (UTC). Pass the same value to create_mandate. (all other arguments: see create_mandate)

Returns: JSON string with keys: pdf_base64 (standard base64 of the PDF), filename, pdf_sha256, attachment_name ("amr-mandate.json"), payload_sha256 (the value printed in the PDF), payload, payload_b64url, signed_at. On error: the same error as prepare_mandate_signature, or {"error": "...", "code": "mandate_pdf_too_large"} (content over 256 KiB or more than 200 pages).

Input Schema

Name	Required	Default
`scope`	Yes
`agent_id`	Yes
`currency`	No	EUR
`metadata`	No
`signed_at`	No
`max_amount`	No
`period_days`	No
`principal_id`	Yes
`risk_classes`	No
`amount_actions`	No
`duration_hours`	Yes
`allowed_actions`	No
`forbidden_actions`	No
`parent_mandate_id`	No
`period_max_amount`	No
`delegation_allowed`	No
`legal_basis_article`	Yes
`max_delegation_depth`	No
`legal_basis_regulation`	Yes
`legal_basis_jurisdiction`	No	EU

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does: it discloses the embedded attachment (amr-mandate.json), the per-page SHA-256, deterministic output for identical arguments and signed_at, that the registry neither signs nor verifies signatures on this PDF in this version, and that an agent cannot sign on the principal's behalf. It also documents error behavior, including the mandate_pdf_too_large code and its 256 KiB / 200 page thresholds.

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 purpose sentence, then a structured Args/Returns/error layout, with no filler. It is dense and the time-window discussion spans several sentences that could be tightened, but each carries a distinct constraint an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, 20-parameter, non-mutating generation tool the description covers the workflow, determinism guarantees, cross-tool coupling, and failure modes well. The remaining gap is that it explains only one of twenty parameters, relying on the sibling create_mandate definition for the rest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 20 parameters, so the description must compensate. It gives real meaning only for signed_at (ISO 8601, timezone required, default now UTC, must be reused in create_mandate); the other 19 parameters are delegated wholesale to "see create_mandate," leaving constraint-bearing fields like max_amount, period_days and legal_basis_* undocumented here.

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 ("Return the mandate as a PDF") plus the intended consumer ("for the principal to sign with its own signature tool"), which immediately separates it from create_mandate and prepare_mandate_signature.

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?

Explicitly says it takes the same arguments as create_mandate / prepare_mandate_signature and that "Nothing is written," then gives the operative ordering constraint: generate, sign and register within AMR_PRINCIPAL_SIGNATURE_MAX_AGE_SECONDS (default 900 s) "or generate a new PDF." It also defines what must match for a PDF to correspond to a registered mandate.

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

Deploy Server