Production-grade token-bucket concurrency rate limiter that enforces RPM and TPM sliding limits with dynamic millisecond backoff calculations for LLM token permits
Single tool with critical definition gaps. Tool name 'acquire_token_permit' lacks action verb clarity (should be 'get_token_permit' or 'request_token_permit'). Description is 73 chars, acceptable length but lacks WHEN/WHY context for LLM selection. Input schema visible but incomplete: 'requested_tokens' has type and description, but no min/max bounds (baseline: numeric params need range constraints). Output schema NOT documented, LLM cannot plan downstream calls or extract structured fields. No error handling guidance (what happens on rate limit? What should agent do?). Tool is READ_ONLY but no idempotentHint annotation present. No parameter validation rules stated (e.g., 'must be 1-60000'). Fails 6 of 7 critical checks in Definition Quality rubric.
Acquires LLM token permits via sliding token bucket algorithm.
Output schema not documented. LLM cannot infer response structure (verdict, allocated_tokens, wait_backoff_ms, concurrency_pressure fields are invisible in tool definition).
Input parameter 'requested_tokens' lacks min/max bounds. Baseline requires numeric params to specify range (e.g., 1 - 60000). Unbounded values invite LLM to pass absurd values.
No error handling guidance. Tool can return RATE_LIMIT_BACKOFF_REQUIRED verdict, but description does not explain what LLM should do (retry? wait? ask user?). Violates recovery-guide pattern.
Tool name 'acquire_token_permit' is vague. Does not start with clear action verb. 'get_token_permit' or 'request_token_permit' would be clearer and match LLM verb-noun parsing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
Description lacks WHEN/WHY context. Does not explain when to call this vs alternatives, what prerequisites exist, or what the return values mean. Baseline: 194 chars avg, this is 73 chars with minimal context.