Loading ToolBench
The Stripe co-pilot for indie SaaS founders. Ask your AI about MRR, churn, failed payments, and at-risk customers via MCP.
All 9 tools have basic naming (verb_noun pattern) and minimal parameter descriptions, but lack comprehensive documentation. Tool descriptions are present but generic (10-50 chars). Input schemas are visible but sparse: most parameters have only type and description, no enums or constraints. Output schemas are not documented in the source. Error handling is absent from tool definitions. The server uses fastmcp framework with Zod validation, but tool definitions themselves lack the depth required for production LLM agents.
Tool descriptions are too brief (10-50 chars). LLMs cannot determine when to select a tool vs. similar alternatives without context on WHAT it does, WHEN to use it, and WHAT it returns.
Output schemas are not documented. Tools return structured JSON (summary, context, items) per server.ts instructions, but the response structure is not formally declared in tool definitions. LLMs cannot plan downstream calls without knowing what fields to expect.
Period parameter lacks enum constraints. Tools accept 'period' as free-form string (e.g. 'last_30_days', ISO date range). No enum or pattern validation visible. LLMs will hallucinate invalid period formats.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
No error handling guidance in tool definitions. If a customer lookup fails or Stripe API is unavailable, the LLM has no recovery path. Error responses should guide the agent: 'Customer not found. Try search_customers() with partial name.'
Customer parameter accepts both ID and email but lacks disambiguation. Description says 'Customer ID or email' but does not specify format constraints (e.g. 'email must contain @, ID must start with cus_'). LLMs will guess wrong.