MyDataHub

Get a compliance receipt

get_compliance_receipt

Read-onlyIdempotent

Returns an order's signed compliance receipt: an ES256 JWS with its decoded claims and a PDF link, covering records delivered, suppression removals, subscriber classes, TPS screening, Article 14 status, the licence and the file hash. Use it to prove to the user, a colleague or another agent that a list is licensed and screened; anyone can verify it with POST /v1/compliance/receipts/verify. Free; it needs orders:read. Lawful basis is UK GDPR Article 6(1)(f) legitimate interests; email audiences include corporate subscribers only by default (PECR), so sole traders and ordinary partnerships are left out unless the toggle is changed.

Input Schema

Name	Required	Description	Default
`order_id`	Yes	The order the receipt covers.

Output Schema

Name	Required	Description
`id`	Yes	Format: a compliance receipt id: rcpt_ followed by a 26 character ULID in upper case Crockford base32, such as rcpt_01JB4NA2Q5W8ZAK8Q2V7XN3M9R.
`alg`	Yes
`jws`	Yes	The receipt as a compact JWS signed with ES256.
`kid`	Yes	The signing key id in jwks_url.
`claims`	Yes
`pdf_url`	Yes	The PDF twin at mydatahub.emailmovers.com/receipts/{id}.
`jwks_url`	Yes
`order_id`	Yes	Format: an order id: ord_ followed by a 26 character ULID in upper case Crockford base32, such as ord_01JB4N9S3W2X6Y7Z8A1B2C3D4E.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedOutput schema / $defs / ReceiptClaims / properties / test

Added value: +{
+  "const": true,
+  "description": "The receipt of a test mode order (a test key, or a demo organisation): its records are invented and it grants no licence. Absent on a live order's receipt.",
+  "type": "boolean"
+}

First observedNov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world; the description adds things they cannot: cost (free), required scope (orders:read), verified output format, an out-of-band verification endpoint, and the lawful-basis/PECR default that affects what the receipt shows. It also warns that sole traders and ordinary partnerships are excluded by default unless the toggle changes — a real behavioral caveat.

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?

One paragraph, front-loaded with what is returned, then usage, then access/cost, then legal caveats — a sensible order for an agent scanning it. It is dense (roughly 90 words in a single block), and the lawful-basis sentence is background rather than call-relevant, but nothing is truly wasted.

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?

Output schema exists and the description still summarizes the payload; auth scope, cost, verification path and audience-side effects are all covered. For a one-parameter read tool, an agent has everything needed to call it and interpret the result.

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 coverage is 100% for the single order_id, so the format, pattern and example are already documented. The description only restates that the receipt covers an order; it adds no syntax or edge-case guidance (e.g., wrong-owner orders, receipts not yet generated). Baseline 3 applies.

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 — returns an order's signed compliance receipt — and enumerates what it contains (ES256 JWS, decoded claims, PDF link) plus the claim coverage (delivered records, suppression removals, TPS screening, Article 14, licence, file hash). No sibling in the catalog does receipt retrieval, so this is unambiguous.

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

Usage Guidelines4/5

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

Gives a clear when-to-use: proving to a user, colleague or other agent that a list is licensed and screened. It also points to the external verification path (POST /v1/compliance/receipts/verify) for anyone checking it. It does not name an in-catalog alternative or exclusion, which keeps it short of a 5.

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

All MyDataHub 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?