Mundane

topup_wallet

Create a Stripe Checkout link that adds funds to the principal's wallet. Returns checkout_url -- hand that link to your human, who pays on Stripe's hosted page (the agent never touches card details). The wallet credits automatically once payment completes; confirm with get_spend_status. amount_minor is in the smallest currency unit (500 = $5.00) and currency must match the principal's wallet currency.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`currency`	No	ISO-4217 currency code. USD is the only currency supported today.	USD
`cancel_url`	No	Where Stripe sends the payer if they abandon checkout.	https://mundane.market/?topup=cancelled
`success_url`	No	Where Stripe sends the payer after a successful payment.	https://mundane.market/?topup=success
`amount_minor`	Yes	How much to add, in integer minor units (cents for USD) -- 5000 means $50.00. Never a float.
`idempotency_key`	No	Optional key of your own choosing so a retry reuses the existing checkout instead of opening a second one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	No
`topup_id`	No
`checkout_url`	No
`checkout_session_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 22, 2026

addedInput schema / properties / amount_minor / description

Added value: +"How much to add, in integer minor units (cents for USD) -- 5000 means $50.00. Never a float."

addedInput schema / properties / cancel_url / description

Added value: +"Where Stripe sends the payer if they abandon checkout."

addedInput schema / properties / currency / description

Added value: +"ISO-4217 currency code. USD is the only currency supported today."

addedInput schema / properties / idempotency_key / description

Added value: +"Optional key of your own choosing so a retry reuses the existing checkout instead of opening a second one."

addedInput schema / properties / success_url / description

Added value: +"Where Stripe sends the payer after a successful payment."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "checkout_session_id": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Checkout Session Id"
+    },
+    "checkout_url": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Checkout Url"
+    },
+    "status": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Status"
+    },
+    "topup_id": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Topup Id"
+    }
+  },
+  "title": "TopupOut",
+  "type": "object"
+}

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds valuable behavioral context: the agent never handles card details, the wallet credits automatically after payment, and the checkout link is handed to a human. It also clarifies the idempotency behavior implicitly by mentioning retries reuse the existing checkout. This goes beyond the annotations without contradicting them.

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?

The description is compact and front-loaded: the core action and return value are in the first sentence, followed by the human-in-the-loop flow, then parameter clarifications. Every sentence earns its place, and there is no redundant restating of the title or schema.

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?

Given the tool's complexity (5 params, 1 required, output schema present), the description covers the essential workflow: what it returns, who pays, how the wallet credits, and how to confirm. The output schema exists, so return values need not be detailed. The only minor gap is not explaining what happens on payment failure, but the cancel_url parameter and the overall flow make this sufficient.

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 description coverage is 100%, so the schema already documents all parameters. The description adds extra meaning by explaining the amount_minor unit with a concrete example (500 = $5.00) and emphasizing 'never a float', which is critical for correct invocation. It also reinforces that currency must match the principal's wallet currency, which is not in the schema. This adds value beyond the schema.

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 ('Create a Stripe Checkout link'), a clear resource (the principal's wallet), and the exact outcome (adds funds). It also distinguishes itself from siblings like get_spend_status by explaining the wallet credits automatically and how to confirm. This is a clear, specific purpose that an agent can act on.

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 explicitly tells the agent when to use this tool: to create a checkout link for a human to pay, and explicitly says the agent never touches card details. It also names the sibling get_spend_status as the way to confirm the credit, providing a clear workflow. This is strong usage guidance.

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

All Mundane 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.