Loading ToolBench
Customer discovery co-pilot — an MCP server that guides founders through hypothesis-driven validation
The validator server has clear, well-structured tool definitions with good descriptions and proper parameter typing. All 5 tools have descriptions (avg ~180 chars) and input schemas with typed parameters. However, output schemas are not documented in the visible code, parameter descriptions lack actionable constraints (e.g., format rules, ranges), and error handling guidance is minimal. Tool names follow verb_noun convention well (generate_call_guide, start_debrief, record_insight). The coaching tools form a coherent workflow but lack explicit chaining documentation. No tool annotations (readOnlyHint/destructiveHint) are visible despite clear risk classifications in the metadata.
Analyze a call transcript — extracts structured insights, verbatim quotes, hypothesis evidence, and flags interviewer bias. Requires: projectId (number), transcript (string). Optional: conversationId (from start_debrief) to link insights to a conversation. The project should have hypotheses so the analysis can map evidence to them.
Create a discussion guide tailored to a specific contact and current untested hypotheses. Requires: projectId (number), contactId (number). Both must already exist — use create_project and add_contact first. The project should have hypotheses created via create_hypothesis.
Return Mom Test principles, practical tips, and anti-patterns as reminders before a call. No parameters required. Good to review before any customer discovery conversation.
Capture a specific insight from a conversation. Requires: projectId (number), content (string), signalStrength (strong/medium/weak), direction (supports/contradicts/neutral). Optional: conversationId (from start_debrief), hypothesisId (from list_hypotheses), verbatimQuote. Call start_debrief first to get a conversationId, or use without one for ad-hoc insights.
Begin a structured post-call debrief. Requires: projectId (number), contactId (number). Optional: date (YYYY-MM-DD string, defaults to today). Creates a conversation record and returns targeted debrief questions. Call this right after a discovery call, then use record_insight to capture each insight.
Output schemas not documented. Tools return structured data but LLMs cannot see what fields to expect, forcing them to guess downstream field names and risk broken tool chains.
Parameter descriptions lack actionable constraints. 'date (YYYY-MM-DD string, defaults to today)' is good, but most params lack format rules, ranges, or validation guidance. E.g., 'signalStrength' enum values are defined but not explained (what distinguishes 'strong' from 'medium'?).
No tool annotations visible. Risk metadata (READ_ONLY, WRITE) is documented in the evaluation but not exposed via MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot infer safety properties from the schema.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | <=2025-11-25 | v2 |
Error handling lacks recovery guidance. No visible error responses that tell LLMs what to do next (e.g., 'projectId not found, call create_project first'). Agents will not know how to self-correct on failures.
Tool chaining dependencies not explicit. 'generate_call_guide requires projectId and contactId, use create_project and add_contact first' is helpful, but no tool returns the IDs needed for downstream calls. Agents may not know which tool output feeds into which input.