Skip to main content
Glama

Check plan, credit balance, and spend

ratchet_get_usage
Read-onlyIdempotent

Check current plan usage, remaining included effects, prepaid credit balance, and today's external spend against budget limits to avoid overage.

Instructions

Returns the current plan, remaining included effects for the month, prepaid credit balance, and today's declared external spend against each budget ceiling. Use it to warn a user before a long run exhausts an allowance or a budget.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read behavior is covered. The description adds useful nuance: it reports 'remaining included effects for the month' and 'today's declared external spend,' implying temporal scoping and a possible difference between declared and actual spend. It does not contradict annotations.

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?

Two sentences with no filler. The first sentence front-loads the return contents, and the second immediately gives a practical use case. Every word contributes value.

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 parameterless read-only tool with rich annotations, the description is complete: it names all major return components and explains why an agent would call it. No output schema exists, but the listed data elements are sufficient for selection and invocation.

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 has 0 parameters and the schema description coverage is 100%, so parameter semantics are trivially satisfied. The baseline for a zero-parameter tool is 4, and the description adds relevant context about what the returned information is used for.

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 clearly states the verb ('Returns') and the resource ('current plan, remaining included effects, prepaid credit balance, today's declared external spend'). It distinguishes this read-only usage/credit tool from the sibling circuit/effect/group tools through its specific focus on plan, credit, and spend data.

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?

The description includes explicit when-to-use guidance: 'Use it to warn a user before a long run exhausts an allowance or a budget.' It does not name alternative tools or state when not to use it, but the context is clear and actionable.

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