Loading ToolBench
Pre-production checklists for solo founders — 4,394 items, 87% portable to any stack, 26 stack supplements. CLI + MCP server.
prodcheck provides 4 well-defined tools with clear purposes and comprehensive input schemas. Tool names follow verb_noun convention (checklist_for_stack, search_checklist, release_gate, list_checklists). Descriptions are detailed and explain when/why to use each tool. All tools have documented input schemas with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the source code provided, and there is no evidence of error handling guidance or recovery patterns. The tools are read-only (no destructive operations), which reduces some security/error handling complexity.
Return the pre-production checklist that applies to a given project: every stack-agnostic item plus the supplements for the named products, optionally narrowed to one domain (security, scale, performance, integrations). A stack with no supplement file is not an error — you get the stack-agnostic core, which stands on its own. Use this when asked to review or prepare a project for production.
List every checklist in the dataset with its group and item count, plus which stacks have supplement files. Call this first if you are not sure what is available.
Return only the items that should block a release. The fastest useful answer to "is this safe to ship?". Pass `stacks` to add the product-specific blockers too — a leaked service-role key or an unaudited RLS policy stops a launch just as surely as the generic items do.
Search checklist items by text. Use when you want the checks relevant to one topic (for example "CORS", "RLS", "prompt injection", "signed URL") rather than a whole checklist.
Output schemas not documented in source code. LLMs cannot plan downstream tool composition or extract structured data from responses without knowing the response shape.
No error handling guidance visible. Tools provide READ_ONLY risk classification but do not document error cases (e.g., invalid domain, no results found) or recovery hints. LLMs need actionable error messages, not just success paths.
release_gate tool name is generic and does not clearly signal action. Better alternatives: 'get_release_blockers' or 'check_release_readiness' would clarify what the tool returns and when to use it vs checklist_for_stack.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Parameter 'areas' in checklist_for_stack accepts free-form strings with the description 'Narrow to an area within a domain, e.g. core, ai, ai-generated-code' but does not enumerate valid values or validate them. LLMs may pass arbitrary strings. Should provide enum of valid areas per domain, or a discovery tool.
Parameter 'stacks' accepts arbitrary product names ('Any other name is accepted and simply adds nothing'). While this design is intentionally flexible for future products, LLMs cannot self-serve validation. A list_stacks or similar discovery should be called first, but is not mandated in descriptions.