Skip to main content
Glama

Lunium — Brazilian PIX and stablecoin payments

by com.luniumpay
OverviewDiscussionsAdmin

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.

ALSO use it when lunium_create_sandbox_key or lunium_start_sandbox_demo ran without the tester's e-mail (their result says so in next_step): once the person gives you their e-mail and agrees, send it here with consent=true so LuniumPay e-mails them the integration guide once.

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
NameRequiredDescriptionDefault
nameNoThe person name, if the user said it.
emailYesYour user's email, given by them for this purpose.
companyNoCompany name, if the user said it.
consentYesTrue only after the user explicitly asked to be contacted at this address.
messageNoWhat they need, in their own words. Be specific: volume, use case, the question that remains.
timelineNoWhen the user needs to go live, only if they provided it.
use_caseNoThe primary integration flow, if known.
how_foundNoWhere the user says they found Lunium. Keep separate from the MCP delivery channel.
product_stageNoCurrent product stage, only if the user provided it.
monthly_volumeNoApproximate monthly BRL volume, only if the user provided it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / use_case / enum
      Previous value: -[
-  "cashin",
-  "cashout",
-  "cashin_cashout",
-  "payout",
-  "other"
-]New value: +[
+  "custody",
+  "cashin",
+  "cashout",
+  "cashin_cashout",
+  "payout",
+  "other"
+]
  2. Changed12 schema fields changed
    • 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"
+]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that the call is non-blocking ('returns immediately'), that delivery is one-way (reply goes to the address, not back through the tool), that consent is mandatory, and that a wrong address mails a stranger — a real consequence the idempotentHint/destructiveHint flags do not convey. It also states no API key and no cost.

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?

Front-loaded with purpose and the hard gate, and the prohibited-use paragraph earns its length by preventing a concrete failure mode. The three ALL-CAPS blocks are somewhat heavy, but each carries distinct constraint content rather than repetition.

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 outbound-contact tool with no output schema, the description covers everything an agent needs: the trigger conditions, the consent prerequisite, the delivery semantics, and the fallback flow. The absence of a return value is addressed by 'returns immediately' plus the note on where the reply goes.

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 genuine semantics for the two critical fields: the provenance rule for `email` (only an address the user gave in this conversation, never guessed or scraped) and the exact condition for `consent=true`. The remaining eight optional fields are left to the schema, which is reasonable.

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 verb and resource ('hands a message to a human at Lunium and returns immediately'), and its purpose is unmistakably distinct from every sibling, which are all sandbox/PIX/quote tools. An agent can classify it without opening the schema.

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?

Explicitly gates usage ('ONLY when your user explicitly asked to talk to a person'), enumerates qualifying cases, names the fallback flow (sandbox key/demo run without tester e-mail), and lists what NOT to use it for with the concrete alternatives (lunium_create_sandbox_key, lunium_verify_pix_payment, the docs). Nothing is left to inference.

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