Agent Receipt Verify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_x402_endpointA | Check a paid x402 endpoint BEFORE paying it. Sends exactly one request, never pays, and reports which levels of the published conformance ladder it reaches: does it ask for payment the way x402 says, does it declare the offer-receipt extension, and does the signature on its offer actually verify. Levels that need a real settlement are reported as not measured, never as failed. |
| link_receipt_to_settlementA | Check AFTER paying that a version 2 offer-receipt belongs to exactly one real on-chain settlement. Takes the signed receipt payload plus the authorization salt the seller returned outside it, and resolves the salted commitment against live chain state. Answers linked, not linked, or could-not-check, and never guesses between them. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools occupy strictly non-overlapping phases: one runs before payment (read-only conformance probing, never pays), the other runs after payment (links a signed receipt to an on-chain settlement). Descriptions explicitly state the temporal ordering and the distinct inputs/outputs, so misselection is essentially impossible.
Both names are snake_case and action-first (check_…, link_…), giving a readable, predictable pattern. The prefixes and noun styles differ ('x402_endpoint' vs 'receipt_to_settlement'), but this reflects genuinely different operations rather than sloppy convention.
Two tools is on the thin side, but the domain — verifying x402 offer-receipts before and after payment — is narrow and the pair maps cleanly onto its two lifecycle checkpoints. Nothing in the surface feels redundant or padded.
The before-pay and after-pay verification paths are both covered, with explicit tri-state answers (linked / not linked / could-not-check) avoiding dead ends. Minor gaps remain: no way to inspect or list previously verified receipts, and no batch or summary operation for multiple endpoints.