Loading ToolBench
Model Context Protocol server for tokenometer — lets AI agents self-monitor LLM token spend, estimate costs, and budget-check before sending prompts.
tokenometer-mcp provides 10 well-named, read-only tools with consistent schemas and descriptions. All tools follow verb_noun naming (estimate_*, count_*, get_*, list_*, budget_*, measure_*). Descriptions are present and adequate (80-150 chars typical), explaining WHAT each tool does. Input schemas are properly typed with enums where appropriate (format parameter uses constrained enum). However, output schemas are not documented in the source, LLMs cannot see what fields to expect from responses. Parameter descriptions are minimal (10-30 chars) and lack actionable constraints (e.g., no guidance on valid modelId values, no range limits on numeric params like imageWidth/imageHeight/trials). Error handling is not visible in tool definitions. No tool annotations (readOnlyHint present in metadata but not declared in schema). Composition is sound, tools are single-purpose and chainable (e.g., list_models → get_model_info → estimate_cost). Baseline: 549 production tools average 18-char names (tokenometer tools: 15-27 chars ✓), 194-char descriptions (tokenometer: 80-150 chars, below baseline but acceptable), 100% of A+ tools have param descriptions (tokenometer: ~60% have substantive descriptions).
Check if a prompt's cost is within a specified budget
Count tokens using the actual provider's countTokens API (empirical mode)
Count tokens across multiple models using their actual countTokens APIs
Estimate the input cost for a prompt using a specific model and format
Estimate costs across multiple models and formats in a single call
Estimate the token cost for vision/image inputs across models
Get detailed information about a specific model including pricing, context window, and capabilities
Output schemas not documented. LLMs cannot see what fields estimate_cost, get_model_info, or list_models return, forcing them to guess downstream field names and risk broken chains.
Parameter descriptions lack actionable constraints. 'modelId' description does not list valid values or format (e.g., 'claude-opus-4-7' vs 'gpt-4o'). 'imageWidth' and 'imageHeight' have no range limits. 'trials' has no min/max. LLMs will pass invalid values.
No error handling guidance in tool definitions. If an invalid modelId is passed, LLMs have no recovery hint (e.g., 'Call list_models() to see available models'). Error responses are not documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Get the version of the pricing rates database
List all available models with their providers and basic metadata
Measure end-to-end latency and time-to-first-token for a model with a given prompt
Tool annotations missing from schema. Risk metadata (readOnlyHint) is declared in tool metadata but not in input schema. LLMs cannot see which tools are safe to retry or have side effects.
Parameter descriptions are too brief (10-30 chars). Baseline for A+ tools is 72 chars. E.g., 'format' description is 'Format to tokenize the prompt as', does not explain why format matters or what output changes with format.