Skip to main content
Glama

Lunium — Brazilian PIX and stablecoin payments

State and receipt of a crypto sale

lunium_get_crypto_sale
Read-onlyIdempotent

Requires an API key. Returns the current state of a crypto sale and, once settled, the receipt: pix_e2e (Central Bank identifier), receipt_url (a page to show a person), receipt_pdf_url and verify_url (hand it to a counterparty so they can check without trusting you). COMPLETED confirms the PIX, but receipt links can arrive later. If receipt_url or receipt_pdf_url is still null, say the PIX completed and the receipt is being prepared; keep polling THIS order at the normal interval, or use cashout.receipt_ready. Never invent a URL or create a second payment to obtain a receipt.

Use it after lunium_confirm_crypto_sale and after the crypto has been sent to the deposit address. Poll no more than once every 10-15 seconds: polling every second consumes the entire request budget and starts returning quota errors that look like failures.

receipt_pdf_url carries the recipient's full name and tax number. Give the link to your user; do not fetch its contents into the conversation and do not forward it to third parties — verify_url exists for that.

Do not use it to check a payment made outside Lunium — that is lunium_verify_pix_payment. Do not report failure because the state is still pending: outside Polygon the wait is the chain's confirmation requirement, sometimes hours. MANUAL_REVIEW and uncertain processing are not proof of failure or permission to pay again. AWAITING_REFUND_ADDRESS means a client refund address is needed, REFUNDING_CRYPTO means return in progress, and REFUNDED describes the return; show refund_asset, refund_network, refund_amount and refund_tx_hash when available. provider_return_txid alone proves neither PIX payment nor refund to the client. Never reuse deposit_from automatically as a refund destination. sandbox=true is simulation, not a real receipt.

Errors: acao=repetir → poll again. acao=esperar → you are polling too fast; back off, the order is unaffected. A not-found (acao=corrigir) → the id is wrong or belongs to another key; do not retry the same id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cashout_idYesOrder id returned by lunium_quote_crypto_sale. Not the external_id, not the E2E.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover read-only/idempotent/open-world, but the description adds deep behavioral context: API key requirement, late-arriving receipt links, COMPLETED vs pending semantics, state meanings (MANUAL_REVIEW, AWAITING_REFUND_ADDRESS, REFUNDING_CRYPTO, REFUNDED), the provider_return_txid caveat, sandbox simulation, and error-code handling (acao=repetir/esperar/corrigir). No contradiction with the read-only annotations.

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?

The passage is long, but it is front-loaded with the return-value semantics and every paragraph carries distinct operational guidance for a high-stakes payment tool — no filler sentences. Length is driven by necessary state and error coverage rather than padding, though the density borders on over-full.

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?

With no output schema, the description must carry return-value meaning, and it does: it enumerates the receipt fields, explains their meaning and privacy constraints, describes each order state, and covers error responses. Nothing an agent needs to poll and interpret this tool 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 description coverage is 100% and the schema already clarifies cashout_id as the order id from lunium_quote_crypto_sale (not external_id, not E2E). The description reinforces 'THIS order' and 'do not retry the same id' but adds no new format or syntax detail, so the 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?

The description states a specific verb and resource — it returns the current state of a crypto sale and, once settled, the receipt — and names the exact fields returned (pix_e2e, receipt_url, receipt_pdf_url, verify_url). It explicitly distinguishes itself from lunium_verify_pix_payment, so an agent can separate it from siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exactly when to use it (after lunium_confirm_crypto_sale and after the crypto has been sent), gives the polling interval (once per 10-15s), names alternatives (cashout.receipt_ready), and lists when-not conditions (payments outside Lunium, reporting failure while pending). Routing is fully specified.

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