Skip to main content
Glama

Lunium — Brazilian PIX and stablecoin payments

by com.luniumpay

Get your own sandbox API key (no signup)

lunium_create_sandbox_key

Provisions a Lunium TEST api key for you, in one call, with no account, no human approval and no money involved. Use it when a Lunium tool told you erro="chave_ausente" and you want to explore the API yourself instead of stopping to ask your user for credentials.

The key it returns starts with lun_test_ and drives the ENTIRE flow — quote, accept, charge, status, receipt — against the same base URL and the same MCP endpoint as production. Nothing settles: no crypto moves, no PIX is paid, no real person is charged. Code written against it works in production unchanged, because the sandbox emits the same states and the same error contract.

IMPORTANT, tell your user plainly: this is a TEST key. Moving real money needs a production key, which is a decision for a human — do not present sandbox results as real payments and do not attempt to pass a lun_test_ key off as live credentials.

Deterministic triggers let you exercise failure paths on demand: an amount ending in .01 delays, .02 fails, .03 expires the quote, .04 refuses on limits, .05 runs slowly.

Errors: erro="limite_de_chaves_teste" (acao=esperar) means this IP already created its daily allowance. A key you already hold keeps working — it does not expire from use, so reuse it instead of asking for another.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional label so a human can recognise this key later in the dashboard, e.g. the name of your agent or project.

TDQS

A4.5/5.0
Behavior5/5

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

The description discloses substantial behavior beyond the annotations: the key starts with lun_test_, drives the entire flow, emits production-equivalent states and error contracts, moves no real money, never expires from use, and has deterministic amount-based failure triggers. It also clearly warns against presenting test results as real payments, going well beyond the sparse annotation hints.

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 description is longer than average but every paragraph earns its place: purpose, production-equivalence, safety warning, deterministic failure triggers, and quota/error handling. It is front-loaded with the core purpose, though some redundancy exists between 'no money involved' and 'Nothing settles...'.

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?

Given there is no output schema, the description compensates by explaining what the key looks like and that it drives the full flow. It also covers errors, quotas, and reuse guidance. It never states the exact JSON field name of the returned key, but the key prefix and behavior are sufficient for an agent to use the tool correctly.

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%, with the single optional 'name' parameter already documented as a human-recognizable label. The description adds no additional parameter semantics, which is acceptable because the schema fully covers the only input.

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 opens with 'Provisions a Lunium TEST api key for you, in one call,' clearly naming the verb and the resource. It also distinguishes this tool from the payment-related siblings by framing it as a self-service credential provisioner, so an agent can immediately tell it apart.

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?

The description gives an explicit trigger condition: use it when a Lunium tool reported erro="chave_ausente" and the agent wants to explore the API itself. It also directs the agent to reuse an existing sandbox key instead of requesting a new one, covering when-not-to-use behavior.

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

All Lunium — Brazilian PIX and stablecoin payments toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: create vs verify PIX, quote vs confirm crypto sales, check limits, list options, and sandbox provisioning. The only potentially close pair (get_crypto_sale and verify_pix_payment) are explicitly disambiguated in descriptions, one for internal orders, the other for external verification.

Naming Consistency5/5

All tools follow a consistent `lunium_verb_noun` pattern in snake_case. Verbs are descriptive (check, create, get, list, quote, confirm, verify) and nouns clarify the resource. No mixed conventions or vague verbs.

Tool Count5/5

9 tools is well within the ideal 3-15 range. Each tool covers a distinct step in the payment flow (limits, quoting, confirming, status, verification, sandbox) without redundancy. The count feels justified for the server's scope.

Completeness4/5

The flow for both PIX charges and crypto sales is well covered: create, check limits, get status, quote, confirm, and retrieve receipts. The only notable gap is the absence of a list operation for past charges/sales, and no explicit cancel for a PIX charge, but the descriptions indicate these are handled via statuses and terminal states rather than dedicated tools. Overall, the surface is complete for the stated purpose.

Resources