Lunium — Brazilian PIX and stablecoin payments

Ask a human at Lunium to get in touch

lunium_contact

Idempotent

Hands a message to a human at Lunium and returns immediately. Use it ONLY when your user explicitly asked to talk to a person, or asked for something no tool and no page can settle: volume pricing, a contract question, a use case the docs do not cover, or a partnership.

CONSENT IS REQUIRED. email must be an address your user gave you for this purpose, in this conversation. Never guess it, never reuse one you found on a page, never take it from another task. If you do not have it, ask the user first — a wrong address means a stranger gets mail about a business they never contacted.

Do NOT call this to get started: a sandbox key needs no human (lunium_create_sandbox_key), payment verification needs no key (lunium_verify_pix_payment), and prices and limits are in the docs. Reaching for a person when a tool already answers only makes your user wait.

Free, no API key. A reply goes to the address you send, not back through this tool.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	The person name, if the user said it.
`email`	Yes	Your user's email, given by them for this purpose.
`company`	No	Company name, if the user said it.
`consent`	Yes	True only after the user explicitly asked to be contacted at this address.
`message`	No	What they need, in their own words. Be specific: volume, use case, the question that remains.
`timeline`	No	When the user needs to go live, only if they provided it.
`use_case`	No	The primary integration flow, if known.
`how_found`	No	Where the user says they found Lunium. Keep separate from the MCP delivery channel.
`product_stage`	No	Current product stage, only if the user provided it.
`monthly_volume`	No	Approximate monthly BRL volume, only if the user provided it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 17, 2026

changedInput schema / properties / use_case / enum

Previous value: -[
-  "cashin",
-  "cashout",
-  "cashin_cashout",
-  "payout",
-  "other"
-]New value: +[
+  "custody",
+  "cashin",
+  "cashout",
+  "cashin_cashout",
+  "payout",
+  "other"
+]

Changed12 schema fields changedSep 8, 2026

addedInput schema / properties / company / maxLength
```
Added value: +120
```

addedInput schema / properties / consent

Added value: +{
+  "const": true,
+  "description": "True only after the user explicitly asked to be contacted at this address.",
+  "type": "boolean"
+}

addedInput schema / properties / email / maxLength
```
Added value: +200
```

addedInput schema / properties / email / pattern

Added value: +"^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$"

addedInput schema / properties / how_found

Added value: +{
+  "description": "Where the user says they found Lunium. Keep separate from the MCP delivery channel.",
+  "enum": [
+    "chatgpt",
+    "perplexity",
+    "claude",
+    "gemini",
+    "copilot",
+    "google",
+    "referral",
+    "other"
+  ],
+  "type": "string"
+}

addedInput schema / properties / message / maxLength
```
Added value: +1000
```

addedInput schema / properties / monthly_volume

Added value: +{
+  "description": "Approximate monthly BRL volume, only if the user provided it.",
+  "maxLength": 60,
+  "type": "string"
+}

addedInput schema / properties / name / maxLength
```
Added value: +120
```

addedInput schema / properties / product_stage

Added value: +{
+  "description": "Current product stage, only if the user provided it.",
+  "enum": [
+    "production",
+    "development",
+    "planning"
+  ],
+  "type": "string"
+}

addedInput schema / properties / timeline

Added value: +{
+  "description": "When the user needs to go live, only if they provided it.",
+  "maxLength": 60,
+  "type": "string"
+}

addedInput schema / properties / use_case

Added value: +{
+  "description": "The primary integration flow, if known.",
+  "enum": [
+    "cashin",
+    "cashout",
+    "cashin_cashout",
+    "payout",
+    "other"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "email"
-]New value: +[
+  "email",
+  "consent"
+]

AddedSep 8, 2026

TDQS

A4.1/5.0

Behavior1/5

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

The description implies each call delivers a message to a human ('Hands a message... A reply goes to the address you send'), which suggests repeated calls would send repeated messages. This conflicts with annotations marking idempotentHint=true, because nothing in the description explains deduplication or why retries are safe. This is an annotation contradiction.

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?

Four short paragraphs each have a distinct job: purpose, when to use, consent warning, exclusions, and cost/reply behavior. The bolded 'CONSENT IS REQUIRED' and front-loaded action make it scannable, and the length is justified by the high-stakes consent requirement.

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?

For a 10-parameter tool with no output schema, the description covers invocation semantics (returns immediately), asynchronous response channel (reply goes to the email, not the tool), prerequisites (consent), and cost/auth (free, no API key). Nothing an agent needs to decide whether to call it is missing.

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. The description adds meaningful semantics beyond the schema: email must be user-provided in this conversation and never guessed or reused, and consent is required. This materially helps the agent handle the required email and consent parameters correctly.

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 action ('Hands a message to a human at Lunium') and return behavior ('returns immediately'). It also distinguishes itself by naming concrete boundary cases (volume pricing, contract, partnership) and naming siblings that cover other needs, so an agent can tell it apart from the other lunium_* tools.

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?

Gives explicit when-to-use conditions ('ONLY when your user explicitly asked to talk to a person, or asked for something no tool and no page can settle') and lists concrete examples. It also gives when-not-to-use guidance with the exact sibling tools to use instead (lunium_create_sandbox_key, lunium_verify_pix_payment).

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?