Skip to main content
Glama

seal

by ai.aqta
OverviewDiscussionsAdmin

Verify a receipt

verify_receipt
Read-only

Check that a record still says what was signed: the permitted or refused decision, unchanged, under Seal's published issuer keys or a key you supply. Handles both formats: ATTESTATION-v1 (a model-call decision) and ACTION-v1 (an agent tool action). No Aqta service in the check.

Input Schema

NameRequiredDescriptionDefault
profileNoUsually omit this. The record's own signed version tag selects the format, and ATTESTATION-v1 is the default. Pass 'ACTION-v1' only to force an agent-action record to be checked as one.
receiptYesThe record, as a JSON object or a JSON string.
public_keyNoBase64url Ed25519 key to check against. Omit it to check against Seal's published issuer keys; a record carrying any other key then fails. A key you supply is used as given, and issuer_key in the result says whether it is a Seal issuer key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / public_key / description
      Previous value: -"Base64url Ed25519 key to trust. Omit to use the key embedded in the record, which proves internal consistency only, never provenance."New value: +"Base64url Ed25519 key to check against. Omit it to check against Seal's published issuer keys; a record carrying any other key then fails. A key you supply is used as given, and issuer_key in the result says whether it is a Seal issuer key."
  2. Changed1 schema field changed
    • changedInput schema / properties / profile / description
      Previous value: -"Which format to verify as: ATTESTATION-v1 or ACTION-v1. Omit and the record's own signed version tag selects it."New value: +"Usually omit this. The record's own signed version tag selects the format, and ATTESTATION-v1 is the default. Pass 'ACTION-v1' only to force an agent-action record to be checked as one."
  3. Changed3 schema fields changed
    • addedInput schema / properties / profile
      Added value: +{
+  "description": "Which format to verify as: ATTESTATION-v1 or ACTION-v1. Omit and the record's own signed version tag selects it.",
+  "type": "string"
+}
    • changedInput schema / properties / public_key / description
      Previous value: -"Base64url Ed25519 key to trust. Omit to use the key embedded in the receipt, which proves internal consistency only, never provenance."New value: +"Base64url Ed25519 key to trust. Omit to use the key embedded in the record, which proves internal consistency only, never provenance."
    • changedInput schema / properties / receipt / description
      Previous value: -"The receipt, as a JSON object or a JSON string."New value: +"The record, as a JSON object or a JSON string."
  4. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description reinforces the latter with 'No Aqta service in the check' – i.e. a purely local verification. It adds real behavioral detail: a record with any non-Seal key fails by default, and issuer_key in the result reports whether the key was a Seal issuer key. This goes beyond the annotations without contradicting them.

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?

Three compact sentences, front-loaded with the core purpose and ending with the useful 'no service call' fact. No filler. The final sentence is a clipped fragment, but it earns its place by ruling out a network dependency.

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

Completeness3/5

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

With no output schema, the description carries more of the burden for describing the outcome, and it only partially does so (it mentions issuer_key in the result but not what a pass/fail result looks like). Annotations cover the safety profile and the local-execution point is made, so the essential context is present, but an agent cannot fully picture the return value.

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 schema already explains profile, receipt, and public_key (including the default-key fallback behavior), and the description largely restates that ('under Seal's published issuer keys or a key you supply'). Per the rubric, a fully documented schema sets the baseline at 3.

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?

States a concrete verb and resource ('Check that a record still says what was signed') and immediately scopes what is being verified: the permitted/refused decision, unchanged, against issuer keys. It also names the two record formats it handles, which helps distinguish it from format-explainer siblings. It does not, however, explicitly contrast itself with decode_receipt or verify_evidence_pack.

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 implied rather than stated: the reader infers 'use this to confirm a receipt is authentic.' The description clarifies an option (supply your own key) but never says when to prefer this tool over decode_receipt or verify_evidence_pack, and offers no exclusions or prerequisites. Adequate but with clear routing gaps.

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

All seal toolsInspect
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