Skip to main content
Glama
Sign In
Nerdit

Nerdit

Official
by nerdit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_ai_budget

Set an app's monthly AI gateway token limit to cap prompt and completion tokens across all aliases. Use it to enforce usage budgets on apps you own.

Instructions

Set an app's monthly AI gateway token limit.

    A submitter may only set a value at or below the limit in force (the
    app's own, else the machine default) on apps it owns: raising or
    removing a limit is for an admin or the console, 403
    ``ai_budget.raise_forbidden``. Not a spending guarantee: a
    ``provider = "api"`` binding or a key in a variable never crosses the
    gateway. Refusals: 404 ``service.not_found``, 403 ``forbidden`` (not
    your app).

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": {
      "service": "<service>",
      "tokens_month": "<tokens_month>"
    },
    "name": "set_ai_budget"
  }
}

Input Schema

NameRequiredDescriptionDefault
serviceYesThe app to limit.
tokens_monthYesPrompt + completion tokens per UTC month, every alias of the app summed.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.3

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are supplied, so the description carries the full burden and does so well: it discloses the permission model, the 403 ai_budget.raise_forbidden refusal for raising, 404 service.not_found and 403 forbidden for non-owned apps, and the crucial caveat that the limit is not a spending guarantee because provider="api" bindings or keys in variables bypass the gateway. The only omission is the shape of a successful response, which is minor against this depth of disclosure.

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?

The action and its constraint are front-loaded, and every clause (ownership, raise-forbidden, non-guarantee caveat, error codes) carries information an agent needs to avoid a failed or misunderstood call. The nested parenthetical about the limit in force is slightly convoluted and the formatting is awkwardly indented, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the definition covers authorization, refusal cases and semantic caveats that an agent would otherwise have to discover by trial. It does not say what a successful call returns or whether a lowered limit takes effect immediately against already-consumed tokens, which leaves a modest gap for a state-changing tool.

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; the description earns above that by adding meaning to `service` — it must be an app the caller owns — and by explaining the 'limit in force' resolution chain (the app's own limit, else the machine default) that determines whether the requested value is allowed. Idempotency semantics are left entirely to the schema's own description.

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 opening sentence names a specific verb, resource and unit-scope: 'Set an app's monthly AI gateway token limit.' That is enough for an agent to distinguish it from sibling reads such as list_ai_budgets or get_ai_usage without opening any schema.

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?

It states clearly who may call it and with what value: a submitter may only set a value at or below the limit in force on apps it owns, and raising or removing a limit belongs to an admin or the console. That is real when-to-use/when-not guidance, though it stops short of naming a specific sibling tool to consult first (e.g. for reading the current limit).

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

Deploy Server

Other Tools