Skip to main content
Glama
Sign In
@qed-proof/mcp

@qed-proof/mcp

by Nuraveda
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get a signed receipt

get_receipt
Read-onlyIdempotent

Retrieve a full signed receipt using its receipt_id, including claim, verdict, signature, and proof, with a shareable public link.

Instructions

Returns the full signed receipt for a receipt_id: the claim, what the verifier read at the destination (facts and fingerprints, never content), the verdict, the Ed25519 signature, and the log inclusion and anchor proof. Receipts are public, and the response includes a shareable link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "receipt_id": "<receipt_id>"
    },
    "name": "get_receipt"
  }
}

Input Schema

NameRequiredDescriptionDefault
receipt_idYesThe receipt_id from get_verdict or submit_claim.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds valuable behavioral context by stating what is included and what is explicitly excluded ('never content'), that receipts are public, and that a shareable link is returned – details not captured in annotations.

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 focused sentences with no fluff; the primary return content is listed first, followed by the public-access and link feature. Every phrase contributes meaningful information.

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 single-parameter read-only tool with no output schema, the description thoroughly enumerates the expected return payload and the sharing behavior. No essential detail needed for correct invocation 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% and the parameter receipt_id is clearly explained in the schema as coming from get_verdict or submit_claim. The description does not add additional parameter semantics beyond what the schema provides, so a baseline of 3 is appropriate.

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?

Description states 'Returns the full signed receipt for a receipt_id' with a specific resource and verb, enumerating the exact contents (claim, facts/fingerprints, verdict, signature, proof). It clearly differentiates from sibling verify_receipt by describing a complete receipt with log inclusion/anchor proof rather than just verification semantics.

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?

The description gives context (receipt_id comes from get_verdict or submit_claim) and notes receipts are public, implying when it can be called. However, it does not explicitly contrast with verify_receipt or state conditions when another tool should be used instead, leaving selection partially to inference.

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