Loading ToolBench
Syncs billing events data to Google Sheets, calculating total MRR and tracking sync status
This server has critical structural and documentation deficiencies that prevent it from being a production-ready MCP tool. The single tool 'sync_billing_data' lacks proper MCP server registration, has incomplete parameter descriptions, missing output schema documentation, and no error handling strategy. The server appears to be a standalone Python class, not an MCP server implementation. No evidence of MCP protocol compliance (no stdio/HTTP transport, no tool registration mechanism, no schema validation framework). The tool definition exists only as a method signature without explicit MCP tooling metadata.
Syncs billing events to a target spreadsheet and returns the count of synced rows, total MRR in USD, and sync status
Not a valid MCP server, no transport layer detected (not stdio, not HTTP, not SSE). Source code shows only a Python class with no MCP server framework integration.
Input schema severely incomplete. 'billing_events' parameter description is vague ('List of billing event objects, each containing at minimum an amount field'). Does not specify: expected structure of billing event objects, whether 'amount' is the only required field, allowed numeric ranges, currency assumptions, array length constraints, or how to handle invalid/missing amounts.
Output schema not documented. The tool description states it 'returns the count of synced rows, total MRR in USD, and sync status' but there is no formal output schema specification. An LLM cannot plan downstream operations without knowing the return type, field names, and value ranges. Current return shows 'sync_status' as a dynamic string, what are valid values? Can it be null?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
Parameter 'target_sheet_id' lacks validation constraints. Description says 'Google Sheet ID' but does not specify format (what does a valid Sheet ID look like?), length bounds, or pattern. This forces the LLM to guess, is 'sheet_mrr_dashboard_2026' valid? Is '1A2B3C' valid? Format must be formally specified.
No error handling strategy. The implementation sums amounts with .get('amount', 0) but does not validate that 'amount' is numeric. What happens if an event has amount='abc'? No error classification (retryable, user-fixable, fatal). No recovery guidance. LLM cannot handle failure states.
No security model defined. Tool accepts 'target_sheet_id' directly as a parameter, this appears to write to Google Sheets. No authentication/authorization validation shown. No mention of required permissions (e.g., 'write:google-sheets'). No audit logging. Credentials for Google Sheets API not visible, if they exist, they must not be in code or parameters.
Tool name 'sync_billing_data' conflates two concerns: syncing (writing to a sheet) and returning metrics (counts, totals). Consider splitting into 'sync_billing_events_to_sheet' (write operation) and optionally a separate 'get_billing_summary' (read/compute operation). Current name masks the destructive nature of the write.
Idempotency not addressed. If the same billing events are synced twice, does it duplicate rows? Overwrite? This is a WRITE operation (destructive) with no confirmation or dry-run option. Agents may retry on transient failures, causing duplicate syncs.