Loading ToolBench
MCP server for billing and access control integration with Loomal, charges API calls based on usage metrics
This MCP server has only one tool (charge_call) with severely limited definition quality. The tool lacks proper MCP integration patterns, has minimal descriptions, and no evidence of being registered as an MCP tool with proper schemas. The code shows a plain Python class method, not an MCP tool registration. The description is present but extremely brief (12 words). Input parameters have type hints in Python but no schema documentation visible in MCP format. No output schema is documented. The tool performs a write operation (charging) but has no error handling, validation, idempotency guarantees, or recovery guidance. The implementation is a simple calculation with no actual integration to a billing system, making it unclear what this tool actually does in practice.
Charges for an MCP method call based on call count and cost per call
Tool is not registered as an MCP tool with explicit schema definition. Source code shows a bare Python method, not MCP tool metadata with inputSchema, description, and output types.
No input schema visible in MCP format. While the Python method has type hints (mcp_method: str, call_count: int, cost_per_call: float), there is no JSON Schema with descriptions for each parameter, constraints (min/max for integers), or enums.
No output schema documented. The method returns a dict with 'charged_amount_usd' and 'access_authorized', but the response structure, field types, and semantics are not formally defined for MCP consumers.
Tool description is 12 words ('Charges for an MCP method call based on call count and cost per call'), below the 34-char p10 baseline and missing critical context. No guidance on when to call this tool, what 'access_authorized' means, or what happens when the limit (10.0) is exceeded.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 25 | 2026-07-28+ | v2 |
Parameter descriptions are completely absent. 'mcp_method', 'call_count', and 'cost_per_call' have no descriptions explaining their purpose, valid ranges, or expected format. LLMs cannot infer that cost_per_call is in USD or that there is a hard limit of $10.00.
No numeric constraints defined. call_count and cost_per_call lack min/max bounds, precision requirements, or negative-value checks. An agent could pass call_count=-1000 or cost_per_call=999999.99 without validation.
Tool is a destructive write operation (charges/debits money) but has no error handling, confirmation mechanism, or recovery guidance. Hard-coded limit check (total < 10.0) with no actionable error message if exceeded.
No recovery or error guidance. If the charge fails or the limit is exceeded, the response gives no context for the agent to act. 'access_authorized: false' does not indicate why authorization failed or what to do next.
Tool name 'charge_call' is vague. It does not clearly indicate that this is a billing/cost tracking operation or that it enforces a hard $10.00 limit. A clearer name like 'charge_mcp_call' or 'debit_call_cost' would better signal intent.
No idempotency guarantee. Calling charge_call twice with identical parameters will charge twice. For a billing tool, this is a critical issue, agents may retry on perceived failures, causing double charges.
No audit trail or logging. A tool that performs financial transactions must log who called it, when, with what parameters, and what the result was. Current implementation has no logging or traceability.
Logic flaw: the hard-coded limit (total < 10.0) is never explained in the description and has no configuration mechanism. Why $10.00? Is this per call, per session, or per account? This must be documented or parameterized.
Unclear semantics of 'access_authorized'. If false, does the charge still apply? Was the call made? Did it fail? The boolean response is ambiguous and lacks context.