Precleared Contact Check

Verify receipt

verify_receipt

Read-onlyIdempotent

Fetch a Precleared receipt by its id (cc_rcpt_...) to show what was checked, when, and the verdict, with the hashes, Ed25519 signature and public key needed to verify it. Use it when a person or an audit asks for proof of a check.

Input Schema

Name	Required	Description	Default
`id`	Yes	Receipt id, such as cc_rcpt_0123456789ABCDEF.

Output Schema

Name	Required	Description
`id`	Yes	Receipt id.
`verdict`	No	Verdict given.
`algorithm`	No	Signature algorithm.
`signature`	No	Ed25519 signature, base64.
`confidence`	No	Confidence given.
`created_at`	No	When the check was made.
`public_key`	No	Public key, base64 SPKI DER.
`key_version`	No	Signing key version.
`request_hash`	No	SHA-256 of the request.
`response_hash`	No	SHA-256 of the response.
`rules_applied`	No	Rule keys used.
`rules_version`	No	Rule set version.
`sender_country`	No	Sender country.
`recipient_domain`	No	Recipient domain.
`recipient_email_masked`	No	Masked recipient address.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 13, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "algorithm": {
+      "description": "Signature algorithm.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "confidence": {
+      "description": "Confidence given.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "created_at": {
+      "description": "When the check was made.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "id": {
+      "description": "Receipt id.",
+      "type": "string"
+    },
+    "key_version": {
+      "description": "Signing key version.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "public_key": {
+      "description": "Public key, base64 SPKI DER.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "recipient_domain": {
+      "description": "Recipient domain.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "recipient_email_masked": {
+      "description": "Masked recipient address.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "request_hash": {
+      "description": "SHA-256 of the request.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "response_hash": {
+      "description": "SHA-256 of the response.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "rules_applied": {
+      "anyOf": [
+        {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Rule keys used."
+    },
+    "rules_version": {
+      "description": "Rule set version.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "sender_country": {
+      "description": "Sender country.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "signature": {
+      "description": "Ed25519 signature, base64.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "verdict": {
+      "description": "Verdict given.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "id"
+  ],
+  "type": "object"
+}

First observedOct 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing the verification payload (hashes, Ed25519 signature, public key) that tells the agent this is a proof-producing read, not just a record lookup.

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?

Two sentences, both load-bearing: the first states the operation and its return contents, the second states the triggering condition. Purpose is front-loaded with zero 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?

Annotations carry the safety profile and an output schema exists, so return values need not be explained, yet the description still tells the agent enough about the receipt's contents to call the tool correctly. Nothing material is missing for a single-parameter read tool.

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?

Only one parameter with 100% schema description coverage, so the schema already documents it fully. The description restates the id format (cc_rcpt_...) without adding syntax or constraints beyond what the schema provides, which lands at the baseline for high-coverage schemas.

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?

Specific verb ('Fetch') plus resource ('Precleared receipt by its id') and an explicit inventory of what the receipt contains: what was checked, when, the verdict, hashes, signature and public key. It does not explicitly distinguish itself from the sibling contact_check, but the two operate on unrelated resources so no real ambiguity exists.

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?

'Use it when a person or an audit asks for proof of a check' gives a concrete triggering condition, which is more than most definitions offer. It stops short of naming when-not-to-use or an alternative tool, so it is clear context without exclusions.

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

All Precleared Contact Check 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.