Loading ToolBench

Reading the current corpus…

claude-usage-panel MCP server · C · ToolBench

claude-usage-panel

GNOME + macOS panel for Claude Code plan usage. Exposes plan-usage data through the Model Context Protocol, allowing MCP clients to query Claude plan usage and manage multiple named accounts.

2025-06-18+STDIO6 tools

64/100

Definition Quality79

Protocol Readiness48

Supportability48

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Claude Usage Panel provides 6 tools for managing Claude Code account usage and credentials. Tools follow verb-noun naming consistently (get_usage, list_accounts, switch_account, save_account, remove_account, refresh_account). Tool descriptions are substantial and context-rich (average ~240 chars), explaining not just WHAT but WHY and WHEN. Input schemas are present for all tools with proper JSON Schema structure. However, several tools lack output schemas in the visible source code, and some parameter descriptions are minimal or absent. The server handles security-sensitive operations (credential storage, account switching) with documented file permissions (0600) and careful token handling. Error handling and recovery guidance are not visible in the provided code excerpt. Tool compositions are sound, account discovery, switching, and credential refresh form a logical chain.

Tools (6)

get_usageread onlyauthsource verified88/100

Current Claude plan usage: session, weekly, and per-model limits - percent used, severity, and reset time for each, from the official Anthropic usage endpoint (same numbers as /usage). A per-model limit (scoped:true, e.g. Fable) caps a share of the weekly all-models pool and draws from it - it is not extra quota. When enough local history exists, each limit also carries a `pace` projection: %/hour burn rate, the projected 100% instant, and whether that lands before the reset. Every limit with a reset also carries `vsClock`: how much of its window has gone and whether usage is running ahead of that clock. `extraUsage` reports prepaid credits charged beyond the plan, when the account has them enabled. Also reports `lastPing` (when a scheduled session ping last opened a 5-hour window) and `sessions`: today's local Claude Code sessions ranked by the tokens they spent, each with the shell command that resumes it. `account` names the saved account these numbers belong to (see list_accounts), null when the current login was never saved.

list_accountsread onlyauthsource verified70/100

The Claude Code logins saved under a name (e.g. PRO, PERSO) with each one's plan usage, which one is active, and whether its stored login is still usable. Usage for a non-active account is read with its own stored token (refreshed when needed); nothing is switched.

refresh_accountwriteauth50/100

Refresh the stored access token for a saved account using its refresh token. The refreshed credentials are written back to storage.

remove_accountdestructiveauth50/100

Forget a saved Claude Code account. The stored credentials are deleted and cannot be recovered.

Issues (5)

HIGHtool ↗

Output schemas missing or incomplete for list_accounts, remove_account, and refresh_account. Only get_usage has a partially visible output schema in the excerpt. Without documented output shapes, LLMs cannot reliably chain tools or extract expected fields.

list_accountsremove_accountrefresh_account

MEDIUMtool-description ↗

Parameter descriptions are minimal or absent for some critical fields. The 'force' parameter in save_account and 'name' in several tools lack detailed guidance on expected format, constraints, or side effects.

save_accountrefresh_account

HIGHrecovery-guide ↗

No visible error handling or recovery guidance in the tool definitions or implementation excerpt. Tools that modify credentials (save_account, refresh_account, remove_account) should guide the LLM on what to do if operations fail (e.g., 'If refresh fails due to expired refresh token, call remove_account and prompt user to re-authenticate').

save_accountremove_accountrefresh_account

Recommendations

Document the complete output schema for all tools, especially list_accounts (what fields does each account object include?), remove_account (what is returned on success?), and refresh_account (what new token info is returned?).
Expand parameter descriptions for save_account's 'force' field to explain side effects: 'If true, overwrites an existing saved account with the same name. If false (default), returns an error if the name already exists.' Similarly, clarify the 'name' parameter format constraint: 'letters, digits, . _ - (max 32 chars)' should be in the description, not just the tool doc.
Add explicit error handling guidance to credential-modifying tools. Example for refresh_account: 'If the refresh token is expired or invalid, the stored credentials cannot be updated. Call remove_account to delete the invalid account and have the user re-authenticate.'
Implement a confirmation step for remove_account: either return a 'confirm_delete' in a multi-round-trip request (MCP 2026 pattern), or add an optional 'confirm' parameter that must be set to true.
Add per-tool permission declarations in descriptions. Example: 'Requires read access to stored credentials and write access to account metadata. Credential secrets are never included in responses.'
Document pagination and limits for list_accounts if the account list can grow large: 'Returns all saved accounts. Each account object includes name, plan, and email. No pagination is offered; for users with many accounts, consider bulk export tools.'

Score history

Overall score trend

First recorded score · v2 rubric

64/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	64	2025-06-18+	v2