Skip to main content
Glama
Sign In
Trust Gate MCP

Trust Gate MCP

by CWNApps
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

verify_receipt

Verify a signed TrustGate receipt offline to confirm it is unchanged and its signatures, including post-quantum checks, are valid; optionally pin the expected signer key.

Instructions

Verify a TrustGate receipt from the certificate alone (offline). ok=true means unchanged since signing, signed, kid consistent with the embedded key, and (require_pq default on) at least one post-quantum leg verified; unsigned receipts fail. It does not prove who signed: pass expected_kid to pin the signer's Ed25519 key; a pin counts only when that key's own signature verifies (see signer_pinned). The post-quantum keys in a receipt are not covered by the kid.

Input Schema

NameRequiredDescriptionDefault
receiptYes
require_pqNo
expected_kidNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / expected_kid
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Expected Kid"
+}
  2. First observedv0.2.1

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations available, the description carries the full burden and does so well: it explains what `ok=true` means, that unsigned receipts fail, that a passing verification does not prove signer identity, and that post-quantum keys are not covered by the `kid`. These are exactly the behavioral caveats an agent needs before relying on the result.

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?

The description is dense but front-loaded: verification scope arrives first, followed by the exact meaning of `ok`, then the signer-pinning caveat, then the post-quantum `kid` caveat. Every sentence adds decision-relevant information without 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?

For a verification tool with no annotations and an output schema, this description supplies the key verification semantics, failure conditions, trust limitations, and parameter behavior needed to call and interpret it correctly. The presence of an output schema reduces the need to explain return fields in detail.

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

Parameters4/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. It explains `require_pq` as defaulting on and requiring at least one post-quantum leg, and it explains that `expected_kid` pins the signer's Ed25519 key only when that key's own signature verifies. The `receipt` object itself is only characterized as a certificate, leaving its nested structure to the schema and output schema.

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?

The description states a specific verb and resource: verify a TrustGate receipt from the certificate alone, offline. It makes the scope and meaning of `ok=true` clear, though it does not explicitly contrast this tool with sibling tools such as `get_receipt_evidence` or `mint_action_receipt`.

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?

It gives clear usage context: perform verification offline from the certificate alone, and use `expected_kid` when the caller needs to pin the signer. It does not explicitly state when to choose this tool over sibling evidence-retrieval or receipt-minting tools, but the operational context is clear.

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

Deploy Server

Other Tools