Skip to main content
Glama

get_agent_spend_limit

Read-onlyIdempotent

Read the spend limits

Returns the account owner's two limits and where the rolling 24-hour window stands: maxPerPaymentUsdc with the min, max, and default bounds it can be set within, maxPerDayUsdc, what has been spent and is left of the 24 hours, and maxPaymentNowUsdc, the most one payment may cost right now. The limit defaults to $1,000 and ranges from $1 to $50,000. It applies to every payment agentX402Pay makes, Laso routes and external url endpoints alike.

Check an amount against maxPaymentNowUsdc before attempting a payment rather than waiting to be refused. Compare the fee-inclusive total, since fees are added on top of the amount you request. Read-only to an agent: only the account owner can change the limit, from the dashboard. If a payment would exceed it, do not split it into smaller payments. Stop and tell your human.

Free.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
maxNoThe highest value the owner can set.
minNoThe lowest value the owner can set.
defaultNoThe limit that applies when the owner has never set one.
maxPerDayUsdcNoThe most everything the agent moves out may total across any rolling 24 hours: payments, wallet sends, and withdrawals together.
nextReleaseAtNoWhen the oldest outflow in the window stops counting, in ms since epoch. Null when nothing is counting.
nextReleaseUsdcNoHow much allowance comes back at `nextReleaseAt`. Null when nothing is counting.
spentLast24hUsdcNoWhat has counted toward the 24-hour limit in the trailing 24 hours.
maxPaymentNowUsdcNoThe most one payment may cost right now: the smaller of `maxPerPaymentUsdc` and `remainingTodayUsdc`. Check an amount against this, not against `maxPerPaymentUsdc` alone.
maxPerPaymentUsdcNoThe most a single payment may total, fees included.
remainingTodayUsdcNoWhat is left of the 24-hour limit right now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedOutput schema / properties / maxPaymentNowUsdc
      Added value: +{
      +  "description": "The most one payment may cost right now: the smaller of `maxPerPaymentUsdc` and `remainingTodayUsdc`. Check an amount against this, not against `maxPerPaymentUsdc` alone.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / maxPerDayUsdc
      Added value: +{
      +  "description": "The most everything the agent moves out may total across any rolling 24 hours: payments, wallet sends, and withdrawals together.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / nextReleaseAt
      Added value: +{
      +  "description": "When the oldest outflow in the window stops counting, in ms since epoch. Null when nothing is counting.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / nextReleaseUsdc
      Added value: +{
      +  "description": "How much allowance comes back at `nextReleaseAt`. Null when nothing is counting.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / remainingTodayUsdc
      Added value: +{
      +  "description": "What is left of the 24-hour limit right now.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • addedOutput schema / properties / spentLast24hUsdc
      Added value: +{
      +  "description": "What has counted toward the 24-hour limit in the trailing 24 hours.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
  2. Changed2 schema fields changed
    • removedInput schema / properties / auth_token
      Removed value: -{
      -  "description": "Laso credential. Only if the MCP connection has no Authorization header.",
      -  "type": "string"
      -}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "default": {
      +      "description": "The limit that applies when the owner has never set one.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "max": {
      +      "description": "The highest value the owner can set.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "maxPerPaymentUsdc": {
      +      "description": "The most a single payment may total, fees included.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "min": {
      +      "description": "The lowest value the owner can set.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "default": {
      -      "description": "The limit that applies when the owner has never set one.",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "max": {
      -      "description": "The highest value the owner can set.",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "maxPerPaymentUsdc": {
      -      "description": "The most a single payment may total, fees included.",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "min": {
      -      "description": "The lowest value the owner can set.",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive context beyond them: the limit defaults to $1,000 and ranges $1–$50,000, only the account owner can change it (via dashboard, not this tool), and the call is free. This goes well beyond the structured safety hints.

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 the return fields and the actionable rule, and every sentence carries unique information. It is longer than strictly necessary and leans on prose where a compact list would read faster, keeping it just short of a 5.

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?

Even though an output schema exists, the description supplies the decision logic an agent needs (compare fee-inclusive totals, don't split payments, escalate to human) plus limit bounds and ownership rules. Nothing required to call and act on this tool 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?

The tool takes zero parameters, so the baseline is 4. The description compensates by thoroughly documenting the returned values and their semantics (bounds, remaining 24h budget, current per-payment ceiling), which is the relevant 'input' an agent needs to reason about.

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+resource ('Read the spend limits') and immediately enumerates the exact fields returned (maxPerPaymentUsdc, maxPerDayUsdc, maxPaymentNowUsdc), so an agent knows precisely what this tool yields and how it differs from balance/payment-status siblings.

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 instructs to check an amount against maxPaymentNowUsdc BEFORE attempting a payment, to compare the fee-inclusive total, and what to do on exceed (stop and tell the human, do not split payments). It also names the affected operations (agentX402Pay / url endpoints), routing the agent correctly.

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.

Resources