Skip to main content
Glama

claude-usage-guard

CI License: MIT Node.js

An MCP server that exposes Claude Code's real-time rate limit usage so that an orchestrator (Leader agent) can check remaining capacity before launching subtasks — and pause when approaching limits rather than failing mid-workflow.

The problem

Claude Code enforces two rate limit windows: a 5-hour session window and a 7-day weekly window. When running multi-agent workflows, an orchestrator has no native way to know how much quota remains before launching a batch of subtasks. The workflow can stall mid-execution when the limit is hit, leaving work in an incomplete state.

Related MCP server: agent-network

How it works

Two components work together:

1. statusLine capture script (scripts/usage-capture.cjs)
Registered as Claude Code's statusLine command. Receives the internal JSON that Claude Code passes after each response — which includes the parsed anthropic-ratelimit-* headers — and persists the rate limit data to ~/.claude/usage_state.json.

2. MCP server (index.js)
Exposes a single tool check_usage_limits that reads ~/.claude/usage_state.json and returns structured data the orchestrator can reason over.

Note: The rate_limits field is only available for Claude.ai Pro/Max subscribers (not direct API key users), and only after the first API response in a session.

Installation

Requirements: Node.js 18+, Claude Code CLI

npm install -g claude-usage-guard

Register the MCP server at user scope:

claude mcp add --transport stdio --scope user usage-guard -- claude-usage-guard

Then add the statusLine entry to ~/.claude/settings.json:

"statusLine": {
  "type": "command",
  "command": "claude-usage-guard-statusline"
}

If Claude Code can't find the command (e.g. you use nvm and its bin dir isn't on Claude Code's PATH), use the absolute path printed by which claude-usage-guard / which claude-usage-guard-statusline instead.

Option B — git clone + setup script

git clone https://github.com/ecerutti/claude-usage-guard.git
cd claude-usage-guard
bash setup.sh

The setup script:

  • Installs npm dependencies

  • Copies the capture script to ~/.claude/scripts/

  • Registers the MCP server at user scope (claude mcp add --scope user)

Then add the statusLine entry to ~/.claude/settings.json manually (the setup script prints the exact snippet to add). To remove everything later, run bash uninstall.sh.

Verify

claude mcp list
# → usage-guard: ... - ✔ Connected

Tool output

check_usage_limits takes no parameters and returns:

{
  "session_used_pct": 42.5,
  "session_resets_at": "2026-06-25T18:30:00.000Z",
  "session_resets_in_seconds": 5700,
  "weekly_used_pct": 15.3,
  "weekly_resets_at": "2026-07-02T04:00:00.000Z",
  "weekly_resets_in_seconds": 601500,
  "data_freshness": "fresh",
  "captured_at": "2026-06-25T16:45:00.000Z"
}

Field

Description

session_used_pct

% of 5-hour window consumed (0–100)

weekly_used_pct

% of 7-day window consumed (0–100)

*_resets_in_seconds

Seconds until that window resets

data_freshness

"fresh" <60s · "stale" 60–300s · "unavailable" >300s or no data

captured_at

ISO 8601 timestamp of last capture

Each window field can be null independently if not yet available.

Using in an orchestrator prompt

Add this to your Leader agent's CLAUDE.md or system prompt:

Before launching any subtask (Task tool or parallel agents), call check_usage_limits.

Decision rules:
- data_freshness "unavailable" → proceed with caution, no usage data yet
- session_used_pct > 80 → do NOT launch heavy tasks; check session_resets_in_seconds,
  wait that duration (Bash sleep or schedule a wakeup), then re-check before continuing
- Otherwise → proceed normally

Always note remaining capacity in your task plan so you can resume pending work
after a reset if you need to pause mid-workflow.

Before relying on this in a long/unattended session, read LESSONS.md. It covers gotchas the rules above don't: re-checking cadence once you're above 80% (not just before launches), what data_freshness: "unavailable" actually means near the reset boundary, why a hard-limit hit with no pending wakeup leaves the session fully idle, and what this tool does (and doesn't) tell you when a different model/account takes over mid-session.

Design decisions

  • No recommendation field. The tool exposes raw data only. The orchestrator model reasons over it directly — pre-baked thresholds would be wrong for different workloads.

  • Fail-open. If data is unavailable, the tool returns null fields rather than blocking — the orchestrator decides what to do with missing information.

  • statusLine is the only reliable source. Scraping claude.ai is blocked by Cloudflare. The rate_limits field in the statusLine JSON is the only official, non-fragile way to access this data from outside the API layer.

Contributing

Contributions are welcome! See CONTRIBUTING.md for how to set up the project, run the tests (npm test), and open a pull request. For security issues, see SECURITY.md.

License

MIT © Esteban Cerutti

Available Tools

1 tool
check_usage_limitsA

Returns current Claude Code rate limit usage. session_used_pct and weekly_used_pct are 0-100. data_freshness is "fresh" (<60s), "stale" (60-300s), or "unavailable" (>300s or no data).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description fully explains the return fields including data_freshness values, adding clear behavioral context beyond a simple 'returns usage'.

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 that are front-loaded with the main purpose and efficiently describe key details. No wasted words.

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?

Given no output schema and low complexity, the description fully covers all return values and states, making it complete for agent understanding.

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?

There are no parameters, so the baseline is 4. The description adds meaning by explaining the output fields, which is appropriate.

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 tool returns current Claude Code rate limit usage, with a specific verb and resource. No sibling tools exist to cause confusion.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or not use this tool is provided. The purpose is implied but lacks context about alternatives or prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedcheck_usage_limits

TDQS

A4.4/5.0
Disambiguation5/5

With only one tool, there is no risk of confusion or overlap between tools.

Naming Consistency5/5

The single tool uses a clear verb_noun pattern (check_usage_limits), which is consistent internally.

Tool Count5/5

A single tool is appropriate for a focused, single-purpose server like a usage limit checker.

Completeness3/5

The server provides only a check operation, lacking any enforcement or configuration tools that the name 'guard' might imply. For pure monitoring, it is complete, but for active guarding, it is incomplete.

Maintenance

ActivityStale
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ecerutti/claude-usage-guard'

If you have feedback or need assistance with the MCP directory API, please join our Discord server