Skip to main content
Glama
Sign In

Runcrate

by io.github.aeonmindai
OverviewDiscussionsAdmin

Top up the balance

top_up
Destructive

Add credit to the workspace balance by charging its saved default card (the only card it can use; cards are added in the dashboard, never here). This spends real money. It needs the billing permission on this sign-in, which a workspace owner or manager turns on in the dashboard's API keys page; without it the answer is BILLING_PERMISSION_REQUIRED. Each sign-in has daily and monthly top-up caps (UTC); past one the answer is TOPUP_CAP_REACHED with what is left. Answers status: succeeded (balance_usd is the new balance), processing (top_up with the same idempotency_key again reads its status), requires_action (nothing is charged yet: give your user confirm_url, which a workspace owner or manager opens signed in to confirm the payment before expires_at; the same idempotency_key then reads the result) or declined (reason and message say why; tell your user).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount_usd": "<amount_usd>"
    },
    "name": "top_up"
  }
}

Input Schema

NameRequiredDescriptionDefault
workspaceNoWorkspace ID (optional: defaults to the authenticated workspace)
amount_usdYesAmount to add, in USD: 20 to 10000, in cents at most
environmentNoEnvironment name (optional: defaults to the environment this session acts in)
idempotency_keyNoOptional: the same key answers the same top-up with its current status instead of charging again. Derived from this call when left out, so a retried call never charges twice. Pass the idempotency_key of an earlier answer to read that top-up's status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: real money is spent, a billing permission on the sign-in is required (with the BILLING_PERMISSION_REQUIRED code), per-sign-in daily/monthly UTC caps apply (TOPUP_CAP_REACHED), and it maps all four terminal statuses including the requires_action confirm_url hand-off to an owner/manager. The one friction point is the claim that a derived idempotency key means a retried call never charges twice, which sits awkwardly against idempotentHint=false.

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-loads the two facts that matter most (real money, default card only) before permission and cap details. The final sentence is a long run-on with nested parentheses around statuses, which is dense but each clause carries operational information an agent needs.

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 destructive, open-world payment mutation with no output schema, the description covers the cost, prerequisite permission, rate caps, error codes and the full status lifecycle including the human confirmation step, which is exactly what an agent needs to drive it 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 coverage is 100%, so amount bounds, defaults for workspace/environment and idempotency_key semantics are already documented in the schema; the description mostly restates the idempotency polling behavior. It adds no meaning for the optional workspace or environment parameters that the schema does not already supply.

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 concrete verb and resource (add credit to the workspace balance) and pins down the funding source: the saved default card, which is the only card it can use. That immediately separates it from sibling billing_balance, get_auto_recharge and set_auto_recharge.

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

Usage Guidelines4/5

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

Gives explicit when-not guidance ('cards are added in the dashboard, never here') and describes how to re-enter the tool with the same idempotency_key to read status rather than charge again. It never names a sibling as an alternative (e.g. set_auto_recharge for automating funding), so routing between billing tools is left partly to inference.

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

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