Loading ToolBench
MCP server that serves a portable, brand-neutral engineering standards library (architecture, security, API, gRPC, compression, validation, options, messaging, UI/UX, MCP policy) so any AI agent can search and apply the rules over MCP instead of reading files.
standards-mcp has clear naming (verb_noun pattern) and comprehensive descriptions that guide LLM selection. All 4 tools are well-described with context on when to use them. However, input schemas are incomplete: search_standards and get_checklist use Zod validation but lack explicit JSON Schema type declarations in the registered inputSchema objects. list_standards has an empty schema ({}). Output schemas are entirely undocumented, LLMs cannot predict response structure. Error handling is minimal (no recovery guidance, no categorization). Parameters lack detailed constraints (e.g., search query minLength=2 is present but no format guidance). No tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Composition is sound, tools chain logically (list → search → get → checklist).
Return the compliance checklist(s). Pass a standard id/name for one, or omit for every checklist across the library — use it as a Definition-of-Done gate before shipping.
Return a full engineering standard by id (e.g. '02'), slug ('02-architecture'), or name ('architecture'). Use after search to read the complete rules and checklist.
List every engineering standard in the library (id, title, and its section headings). Start here to see what rules exist before searching or fetching.
Search the standards library with natural language and return the most relevant rule sections (which standard, which heading, and a snippet). Use this before answering any question about architecture, security, API, gRPC, compression, validation, options, messaging, UI/UX, or MCP policy — apply the rules found here rather than from memory.
list_standards has empty inputSchema ({}). LLMs cannot validate or understand parameter constraints.
Output schemas are completely undocumented. LLMs cannot predict response structure (fields, types, nesting). All tools return text content only, no structured object schema.
search_standards and get_checklist use Zod for validation but inputSchema objects do not include explicit JSON Schema type/properties. Zod schemas are not serialized to JSON Schema in the tool registration.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). All 4 tools are read-only and idempotent, these hints would help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. When search_standards finds no matches or get_standard fails, responses suggest next steps but do not categorize errors as retryable/user-fixable/fatal.