Skip to main content
Glama

Get receipt of a paid call

get_receipt
Read-only

Re-fetch the stored result of a settled paid call (e.g. jp_trip_impact_check) by its receipt_id, for when the response was lost after payment. Free. Unknown or unsettled receipt ids return RECEIPT_NOT_FOUND. Results are kept for 30 days after settlement.

Input Schema

NameRequiredDescriptionDefault
receipt_idYesThe receipt_id returned with a paid result ("rcpt_" + 64 hex characters).

Output Schema

NameRequiredDescriptionDefault
toolYesName of the paid tool that produced the result.
termsYesURL of the terms of service.
resultYesThe stored result, exactly as returned by the paid call.
paymentYes
provenanceYesFreshness receipts for every upstream source used.
receipt_idYesReceipt id of the settled paid call ("rcpt_" + 64 hex). Use with get_receipt.
settled_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "payment": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "network": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "transaction": {
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        }
      +      },
      +      "required": [
      +        "network",
      +        "transaction"
      +      ],
      +      "type": "object"
      +    },
      +    "provenance": {
      +      "description": "Freshness receipts for every upstream source used.",
      +      "items": {
      +        "additionalProperties": {},
      +        "description": "Freshness receipt for one upstream source.",
      +        "properties": {
      +          "content_sha256": {
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "fetch_status": {
      +            "description": "found / empty / stale / unavailable / unsupported (see catalog fetch_status_values).",
      +            "enum": [
      +              "found",
      +              "empty",
      +              "stale",
      +              "unavailable",
      +              "unsupported"
      +            ],
      +            "type": "string"
      +          },
      +          "parser_version": {
      +            "type": "string"
      +          },
      +          "processed_by": {
      +            "type": "string"
      +          },
      +          "retrieved_at": {
      +            "description": "When this service retrieved the upstream data (null if unknown).",
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          },
      +          "source": {
      +            "additionalProperties": {},
      +            "description": "Publisher and URL of the upstream document or dataset.",
      +            "properties": {
      +              "publisher": {
      +                "type": "string"
      +              },
      +              "url": {
      +                "type": "string"
      +              }
      +            },
      +            "required": [
      +              "publisher",
      +              "url"
      +            ],
      +            "type": "object"
      +          },
      +          "upstream_updated_at": {
      +            "description": "Update time stated by the upstream, or null when it states none.",
      +            "type": [
      +              "string",
      +              "null"
      +            ]
      +          }
      +        },
      +        "required": [
      +          "source",
      +          "upstream_updated_at",
      +          "retrieved_at",
      +          "content_sha256",
      +          "parser_version",
      +          "fetch_status",
      +          "processed_by"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "receipt_id": {
      +      "description": "Receipt id of the settled paid call (\"rcpt_\" + 64 hex). Use with get_receipt.",
      +      "type": "string"
      +    },
      +    "result": {
      +      "description": "The stored result, exactly as returned by the paid call."
      +    },
      +    "settled_at": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "terms": {
      +      "description": "URL of the terms of service.",
      +      "type": "string"
      +    },
      +    "tool": {
      +      "description": "Name of the paid tool that produced the result.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "receipt_id",
      +    "tool",
      +    "settled_at",
      +    "payment",
      +    "result",
      +    "provenance",
      +    "terms"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint annotation by disclosing cost behavior ("Free"), the failure mode and exact error code (RECEIPT_NOT_FOUND) for unknown or unsettled ids, and the 30-day retention window. These are exactly the traits an agent needs to decide whether to retry or give up.

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?

Front-loaded with the core action, then three short clauses covering cost, error behavior, and retention. Every sentence carries distinct information and none repeats the title or schema.

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?

Single-required-parameter tool with an output schema, and the description covers the remaining gaps: when to use it, cost, failure semantics, and data lifetime. Nothing an agent needs to invoke it correctly 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 coverage is 100%, and the schema already documents the receipt_id format ("rcpt_" + 64 hex characters). The description only restates that lookup is by receipt_id, adding no syntax or format detail beyond the schema, so 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 ("Re-fetch the stored result of a settled paid call") and names an example sibling product (jp_trip_impact_check), making clear this retrieves a prior result rather than executing a new call. An agent can distinguish this from the sibling tools without opening the schema.

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 an explicit triggering condition: use when the response was lost after payment. It also notes the call is free, implicitly steering the agent away from re-invoking the paid sibling. It stops short of explicitly naming the alternative or stating when not to use it, so it's clear context rather than a complete routing rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources