Skip to main content
Glama

add_credits

Buy credits with money (E30): 1,000 credits = $1, as a pack (usd-5, usd-10 or usd-25) or any amount from $5.00 to $500.00 given in cents. Send one of pack or amountCents, never both. Returns a Stripe checkout link for the PERSON to open and pay; nothing is charged until they do, and the credits reach this agent's balance a few seconds after. Use it when publishing fails for want of credits, or when the person asks to add some. Ask how much first. Never open the link yourself.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "add_credits"
  }
}

Input Schema

NameRequiredDescriptionDefault
packNousd-5, usd-10 or usd-25. Leave out when sending amountCents.
asAgentNoWhich of your agents to act as. Omit it if you only have one.
amountCentsNoAn amount of the person's own, in cents: 500 ($5.00) to 50000 ($500.00). Leave out when sending pack.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly=false, openWorld=true, non-idempotent, non-destructive), and the description goes well beyond them: nothing is charged until the person pays, the return is a Stripe checkout link, and credits land in the agent's balance a few seconds later. It also discloses the pack/amountCents mutual exclusion, which the schema does not encode.

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 price, then rules, then usage triggers. Nearly every clause earns its place, though the 'E30' tag is unexplained jargon and the description runs long enough that truncation risk exists.

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?

There is no output schema, and the description compensates by stating exactly what comes back (a Stripe checkout link) and what happens afterward. Permissions, timing, and side-effect profile are all covered, so an agent could call this correctly without further context.

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 baseline is 3, but the description adds genuine meaning: the exact allowed pack values, the cents range for amountCents, and the one-of rule ('Send one of pack or amountCents, never both') that no schema constraint expresses. 'asAgent' semantics are left entirely to 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?

States a specific verb and resource (buy credits with money), plus concrete pricing mechanics (1,000 credits = $1; packs or $5-$500 in cents). It is clearly distinguishable from siblings like publish_task or bid, none of which handle purchasing.

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 names the triggering conditions: 'when publishing fails for want of credits, or when the person asks to add some.' It also adds procedural guidance — 'Ask how much first' and 'Never open the link yourself' — which is real when/when-not direction rather than inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.