Loading ToolBench
The OpenPitch MCP server — open, sourced, confidence-scored intelligence on AI startups.
OpenPitch MCP has 8 well-named, read-only tools with complete input schemas and descriptions. Tool names follow verb_noun conventions (list_, get_, search_, compare_). All parameters are typed and described. However, output schemas are NOT documented, the code shows partial responses but no formal schema definitions. Error handling is present but minimal (status fields only, no recovery guidance). Tool descriptions are solid (100-300 chars) but could include more context about when to call each tool. No dangerous patterns detected; all tools are READ_ONLY. The server uses fastmcp (modern) but is STDIO-only, which caps protocol readiness. Tool annotations (readOnlyHint) are present, which is a modern bonus.
Side-by-side metric comparison across companies.
Full profile for one company: all resolved metrics with provenance.
Filtered event stream (the push layer). Newest-first, capped at `limit` (default 50). Narrow with `since` (YYYY-MM-DD), `type`, `company_id`, or `min_confidence` when `truncated` is true; `total` is the pre-cap count.
One metric with value/range, confidence, estimate_type, as_of, and sources.
Underlying claims + confidence factors behind a metric.
List covered AI companies with headline metrics.
Lexical search over companies, aliases, categories, and metric keys. Capped at `limit` (default 25); `total`/`truncated` report if more matched.
Output schemas not documented. Tool descriptions explain what parameters do, but responses are inferred from code examples only. LLMs cannot plan downstream calls without knowing the structure of returned data (e.g., what fields are in company objects, event objects, comparison results). Documentation should include a formal 'Returns' section showing field names, types, and nested structure.
Generic tool name 'search' lacks specificity. LLMs may confuse it with other search tools across MCP ecosystem. Better names: 'search_companies' or 'search_company_database' clarify the scope. Current name 'search' is the second-shortest in the 549-baseline corpus, borderline too terse.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Material changes, contradictions, and universe entries/exits. Newest-first, capped at `limit` (default 50). If `since` is omitted, defaults to a 30-day window (echoed back as `since`). Narrow with `since`/`min_confidence` when `truncated` is true; `total` is the pre-cap count.
Error handling is minimal, responses return status:'not_found' or status:'invalid_metric' but do not guide recovery. When a metric is invalid, the response includes allowed_metrics list (good), but most errors just return a status and message with no next steps. Consider enriching errors: 'Metric "foo" not found. Did you mean: valuation, arr? Call list_metrics() to see all available metrics.'
Parameter descriptions for 'what_moved' and 'get_events' could be clearer about truncation behavior. Both describe returning 'newest-first, capped at limit' and mention 'truncated' flag, but the description is dense and doesn't explicitly state: 'If truncated=true, narrow results using since or min_confidence to retrieve remaining events.' Agents need explicit recovery guidance.