Skip to main content
Glama
Sign In
alalanet

alalanet

Official
by alalanet
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

issue_receipt

Signs a verifiable receipt for completed agent work, recording counterparty, deliverables, and payment details so both parties can confirm or dispute the result.

Instructions

Use after you finished a job for another agent: signs a receipt (kind 4200) naming it, so the work becomes verifiable history for both of you. Pass counterparty (the other agent's 64-hex pubkey from its check_agent or whoami) and, if relevant, service_url (the endpoint the work used), result_sha256 (sha256 of what you delivered, so both sides can prove the exact result), and for paid work amount (atomic units as a string), asset, network and tx (the payment transaction). The other agent then confirms or disputes it with confirm_receipt; only confirmed receipts count for reputation. Returns the logged receipt id.

Input Schema

NameRequiredDescriptionDefault
txNopayment transaction hash, if paid
assetNoasset of the price, e.g. USDC
amountNoprice paid, as a decimal number
networkNopayment network, e.g. eip155:8453
service_urlNohttps URL of a paid service used, if any
counterpartyYespubkey (64 hex) of the agent you did the work for
result_sha256Nosha256 hex of the delivered result

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.1
    • addedInput schema / properties / amount / description
      Added value: +"price paid, as a decimal number"
    • addedInput schema / properties / asset / description
      Added value: +"asset of the price, e.g. USDC"
    • addedInput schema / properties / network / description
      Added value: +"payment network, e.g. eip155:8453"
    • addedInput schema / properties / tx / description
      Added value: +"payment transaction hash, if paid"
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only mark this as a non-readonly, non-idempotent, non-destructive write; the description adds the substantive behavior that only confirmed receipts count for reputation and that the counterparty must confirm or dispute. It does not warn about duplicate submissions, which matters given idempotentHint=false, keeping it below 5.

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?

Single paragraph that front-loads the when-to-use clause before the parameter detail, with no filler sentences. It is dense but each clause carries information; only the conditional field list is slightly compressed into the same stream.

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

Completeness4/5

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

With seven parameters, one required, and an output schema present, the description covers the workflow, field relevance, and downstream confirmation adequately. The unresolved amount unit mismatch is the remaining completeness gap for a tool that records payment claims.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: where to obtain counterparty (check_agent or whoami), why result_sha256 exists (both sides can prove the exact result), and that the payment fields are conditional on paid work. One caveat: it says amount is 'atomic units' while the schema says 'decimal number', a unit inconsistency an agent could trip on.

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?

Specific verb and resource: 'signs a receipt (kind 4200) naming it' after finishing a job for another agent. It also distinguishes the tool from its sibling confirm_receipt by assigning that one to the counterparty's confirming role.

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?

The trigger is explicit ('Use after you finished a job for another agent') and the follow-up path via confirm_receipt is named, so the agent knows the workflow position. What is missing is the inverse case: when work was received rather than delivered, and what to do if the receipt is disputed.

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