euroref — European government reference data

verify_answer_receipt

Read-onlyIdempotent

FREE. Verify an answer receipt (kind answer_receipt) with the Ed25519 public key only. Pass the receipt object or its canonical JSON, signature_value when the signature is not inside the receipt, and public_key_pem to verify offline. If public_key_pem is omitted, the tool may GET signature.public_key (/certified/public-key) and read public_key_pem. Never send a private key. A valid signature shows this service issued that exact receipt. It does not turn the receipt into a series certified extract (GET /v1/certified/{country}/{series} at $0.10, not an MCP tool) and it is not legal advice. Same key and canonical-JSON rule as /certified/public-key.

Input Schema

TableJSON Schema

Name	Required	Description
`receipt`	Yes	Answer receipt object (signature may be nested) or the canonical JSON of that object. A canonical JSON string of the signed body (signature omitted) is accepted when signature_value is also passed.
`public_key_pem`	No	SPKI public key PEM from GET /certified/public-key (field public_key_pem). Required for offline verify. A private key PEM is refused.
`public_key_url`	No	Optional GET /certified/public-key URL used only when public_key_pem is omitted. Ignored when the PEM is present.
`signature_value`	No	Base64 Ed25519 signature. Required when the receipt object or JSON string does not already include signature.value. Overrides a nested signature when both are sent.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No
`why`	No
`error`	No	Present on a free refusal or error; no charge
`no_charge`	No
`price_usd`	No
`disclaimer`	No
`how_to_pay`	No
`bind_series`	No
`explanation`	No
`x_next_bind`	No
`http_endpoint`	No
`payment_required`	No	true when the call needs payment; how_to_pay explains x402 or card

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 12, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "description": "Receipt verification result",
+  "properties": {
+    "bind_series": {},
+    "disclaimer": {},
+    "error": {
+      "description": "Present on a free refusal or error; no charge"
+    },
+    "explanation": {},
+    "how_to_pay": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "http_endpoint": {
+      "type": "string"
+    },
+    "no_charge": {
+      "type": "boolean"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "payment_required": {
+      "description": "true when the call needs payment; how_to_pay explains x402 or card",
+      "type": "boolean"
+    },
+    "price_usd": {
+      "type": "number"
+    },
+    "why": {
+      "type": "string"
+    },
+    "x_next_bind": {}
+  },
+  "type": "object"
+}

AddedSep 25, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive. The description adds real context beyond them: it discloses that the tool may perform a network GET of /certified/public-key when the PEM is absent, that it is FREE, and that a private key must never be sent. It does not discuss failure modes or error behavior, so it is useful but not exhaustive.

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 'FREE. Verify...' and dense with no filler, though the closing 'Same key and canonical-JSON rule as /certified/public-key' and the repeated canonical-JSON instruction are mildly redundant. Appropriate length for a cryptographic verification tool.

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?

With an output schema present, return values need not be explained, and the description covers offline vs. online verification, cost, security constraints, and scope limits. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description largely restates what the schema documents (public_key_pem requirement, public_key_url only used when the PEM is absent, signature_value overriding a nested signature) and adds only the canonical-JSON rule and the private-key refusal warning.

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 (verify) plus resource (answer receipt) and the exact cryptographic method (Ed25519 public key only). It also sharply bounds the claim of what a valid result means, so an agent can distinguish this from any sibling 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?

Explicitly says what to pass (receipt object or canonical JSON, signature_value when the signature is not nested, public_key_pem for offline) and what happens when public_key_pem is omitted. It names the alternative path (GET /v1/certified/{country}/{series} at $0.10, explicitly not an MCP tool) and states the exclusion that a valid signature is not a certified extract.

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

All euroref — European government reference data 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?