io.github.JC7333/mandatia

Overview Schema Source Related Servers Discussions Admin

get_proof

Generate a complete Proof Pack for a mandate with all logged actions and cryptographic chain integrity for regulatory compliance and audit.

Instructions

Generate a complete Proof Pack for a mandate, including all actions and chain integrity.

The Proof Pack documents the full mandate chain for regulatory compliance (EU AI Act Art.26, eIDAS 2.0). It includes the mandate details, all logged actions, mandate events, and cryptographic chain integrity verification.

Args: mandate_id: UUID of the mandate to generate a proof pack for. Example: "550e8400-e29b-41d4-a716-446655440000" format: Output format. Currently only "json" is supported. Example: "json"

Returns: JSON string (Proof Pack) with keys: - proof_pack_version: str - generated_at: ISO datetime string - mandate: dict with full mandate details, including principal_signature ({signature, signed_at, key_id, public_key, key_proof_signature, payload, algorithm} or null), organ_decision (the decision of the body that authorized the agent, or null), status ("revoked" once revoke_mandate ran, whatever the stored status, which stays in stored_status) and revocation ({revoked_at, reason, principal_signature, chain_hash} or null) - delegation_chain: dict with broken (bool: true when a mandate above this sub-mandate is revoked, expired, not active or missing, so the mandate is not in force whatever its own status), reason (parent_mandate_revoked, parent_mandate_expired, parent_mandate_, parent_mandate_not_found, delegation_chain_too_deep, or null) and refused_by (the mandate that broke the chain, or null); always unbroken for a root mandate - actions: list of action log entries - events: list of mandate events - action_contests: list of the actions contested under this mandate (contest_action), oldest first, each with action_id, action_chain_hash, contested_by, reason, response_days, contested_at, reminder {respond_by, days_left, deadline_passed}, principal_signature, chain_hash and principal_signature_valid (null when unsigned and the contesting principal had no key then); empty when nothing is contested - chain_integrity: dict with actions_chain_valid (bool), principal_signature_valid (bool; null for an unsigned mandate whose principal had no key when it was created), revocation_signature_valid (bool; null when the mandate is not revoked or was revoked without a signature by a principal that had no key; false when a "revoked" event has lost its revocation record), contests_intact (bool: false when an "action_contested" event has lost its contest record or a contest record has lost its event, when a contest's chain_hash does not recompute from its row and the previous contest, when a contest names an action that is not in this mandate's log or whose hash changed, or when a contest signature does not verify), total_actions, total_events - compliance_notes: dict with ai_act_art26 and retention notes On error: {"error": "..."}.

Input Schema

Name	Required	Description	Default
`format`	No		json
`mandate_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 7, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and largely meets it: it discloses the construction of the payload, the meaning of broken delegation chains, null-signature semantics, and how contests_intact turns false. What is missing is any statement about side effects (does generating persist anything?), idempotency, or authorization requirements for reading a mandate's full log.

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

Conciseness3/5

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

The purpose sentence is front-loaded and efficient, but the subsequent 'Returns' block is an extensive field-by-field enumeration that duplicates the output schema the tool already declares. Given has_output_schema=true, a large share of this text does not earn its place, though the nested null-semantics notes are genuinely informative.

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 high-complexity, compliance-critical tool with two simple parameters, the definition supplies more than enough to invoke correctly and to interpret the resulting proof pack. The only material gap is operational context — permissions, whether generation is read-only, and how it relates to the sibling verification/export tools.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate and does: mandate_id is documented as a UUID with a concrete example, and format is constrained ('currently only "json" is supported') with a default implied by the example. No ambiguity remains about either parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opening sentence names a specific verb and artifact: 'Generate a complete Proof Pack for a mandate, including all actions and chain integrity,' which tells an agent exactly what is produced. It does not, however, differentiate itself from the neighboring export/verification tools (verify_mandate, export_insurer_dossier), which also produce mandate-derived artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied through the regulatory framing ('for regulatory compliance (EU AI Act Art.26, eIDAS 2.0)'), which hints at audit/compliance scenarios. There is no explicit 'use this when...' statement, no exclusion of alternatives such as verify_mandate or export_insurer_dossier, and no prerequisite or side-effect guidance.

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

Deploy Server