Loading ToolBench
Claude Code plugin — lets Claude check its own subscription quota (5-hour session & weekly limits) before and during tasks
Single tool with verbose, instruction-heavy description (500+ chars) that reads like a skill guide rather than a tool definition. Input schema is empty object {} with no parameters documented. Description conflates tool purpose with usage policy (vigilance, ScheduleWakeup, graceful wrap-up), which belongs in a skill or prompt, not the tool definition. Error handling is present but embedded in implementation, not surfaced in schema. No output schema documented despite returning structured JSON. Tool name 'check_quota' is clear and verb-based, but the definition quality is below baseline for production tools.
Read-only: returns the user's current Claude Code quota utilization (5-hour session, 7-day weekly, model-specific weekly windows if active, and extra usage) plus reset times. This is a CHEAP tool you should use VIGILANTLY during multi-step tasks to avoid hitting the wall mid-work. See the check_quota skill for the full vigilance policy: take a baseline reading at the start of any potentially-long task, re-check periodically as utilization grows, and trigger graceful wrap-up + ScheduleWakeup-based sleep when crossing the per-plan thresholds. Errors from this tool are non-critical — silently skip on failure rather than interrupting the user's task.
Input schema is empty object {}, no parameters documented. Tool accepts no inputs, which is valid, but schema should explicitly document this (e.g., 'properties: {}, required: []') rather than leaving it implicit.
Description (500+ chars) embeds usage policy ('VIGILANTLY during multi-step tasks', 'ScheduleWakeup-based sleep', 'graceful wrap-up') that belongs in a skill or system prompt, not the tool definition. Tool descriptions should state WHAT it does and WHEN to use it, not HOW the agent should orchestrate calls. Baseline is 10 - 1024 chars; this is at the verbose end and mixes concerns.
No output schema documented. Tool returns structured JSON with fields (subscription_type, rate_limit_tier, five_hour, seven_day, etc.), but the schema definition does not declare the return type or field structure. LLMs cannot plan downstream operations without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Error handling is implementation-only (try/catch in handler). Errors are returned as text messages ('not authenticated', 'OAuth token has expired', 'failed to read quota') but the tool definition does not document error cases, recovery steps, or error classification (retryable vs. user-fixable). Per pattern:recovery-guide, errors should guide the LLM on next steps.
Tool is read-only and non-destructive, but no tool annotations (readOnlyHint) are present in the schema. Modern MCP servers should declare tool safety properties via annotations to help clients optimize caching and retry logic.