Loading ToolBench
MCP server for managing engineering standards, practices, and processes
The server implements 6 tools with comprehensive descriptions and well-structured schemas. Tool naming follows verb_noun convention (list_standards, get_standard, search_standards, create_standard, update_standard). All tools have detailed descriptions (150-400 chars) explaining WHAT they do and WHEN to use them. Input schemas are fully defined with proper types, enums, and descriptions for all parameters. However, there are notable gaps: (1) output schemas are not documented, LLMs cannot see what fields the response will contain, (2) error handling lacks recovery guidance, no indication of what to do if a tool fails, (3) some parameter descriptions could be more specific about valid ranges and constraints, (4) no pagination documented for list_standards and search_standards despite returning potentially large result sets. The tool definitions are visible and explicit, with proper annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is strong: tools are single-responsibility (list vs get vs search vs create vs update), and naming conventions are consistent. Security-wise, all tools operate on local file-based standards (no credentials), but write tools (create_standard, update_standard) lack confirmation patterns.
Create a new standard with metadata and content. Adds a new standard to the knowledge base. The system automatically generates version 1.0.0, sets timestamps, and creates the file path from metadata. Parameters: - metadata (required): Object with required fields: - type: 'principle' | 'standard' | 'practice' | 'tech-stack' | 'process' - tier: 'frontend' | 'backend' | 'database' | 'infrastructure' | 'security' - process: 'development' | 'testing' | 'delivery' | 'operations' - tags: Array of strings for categorization - author: Author or team name - status: 'active' | 'draft' | 'deprecated' - content (required): Markdown content of the standard - filename (optional): Custom filename (auto-generated if not provided) Example: { metadata: { type: "standard", tier: "backend", process: "development", tags: ["api"], author: "Tech Team", status: "active" }, content: "# API Standards\n..." }
Retrieve a specific standard by path or metadata. Use this tool to read the complete content and metadata of one or more standards. Retrieve by exact file path or by specifying type, tier, and process. Parameters: - path (optional): Exact file path relative to the data directory (e.g., 'standard-backend-development-spring-boot-security-active.md') - type (optional): Standard type to search for - tier (optional): Tier to search for - process (optional): Process to search for - tags (optional): Array of tags to filter by (must match all) - responseFormat (optional): Output format ('json' | 'markdown'), default 'markdown' Note: Must provide either 'path' OR combination of 'type', 'tier', and 'process'. Examples: - Get by path: { path: "standard-backend-development-spring-boot-security-active.md" } - Get by metadata: { type: "standard", tier: "backend", process: "development" }
Retrieve metadata for standards without loading content. Use this tool for efficient browsing and discovery when you only need to see what standards exist and their metadata. More efficient than get_standard when full content is not needed. Parameters: - filterType (optional): Filter by type - filterTier (optional): Filter by tier - filterProcess (optional): Filter by process - filterTags (optional): Filter by tags array - filterStatus (optional): Filter by status - responseFormat (optional): Output format ('json' | 'markdown'), default 'markdown' Examples: - Get all metadata: {} - Get backend metadata: { filterTier: "backend" } - Get active frontend practices: { filterType: "practice", filterTier: "frontend", filterStatus: "active" }
Output schemas not documented. LLMs cannot see what fields list_standards, get_standard, search_standards, get_standards_metadata, create_standard, and update_standard return. This forces LLMs to guess at response structure and risks failed downstream tool calls or missing context.
No pagination guidance for list_standards and search_standards. Although search_standards accepts a limit parameter (1-50), there is no documentation of how to fetch subsequent pages (offset, cursor, or next_marker). list_standards lacks any limit or pagination parameters despite potentially returning hundreds of standards.
Error handling lacks recovery guidance. Tools have no documented error cases or what to do next if a call fails. E.g., if get_standard() fails because the path is wrong, the description provides no hint to call list_standards() first or use search_standards() for discovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 84 | 2026-07-28+ | v2 |
Browse all engineering standards organized by type, tier, and process. Use this tool to discover what standards are available and explore them by category. Returns a hierarchical index of all standards in the knowledge base. Parameters: - filterType (optional): Filter by standard type ('principle' | 'standard' | 'practice' | 'tech-stack' | 'process') - filterTier (optional): Filter by tier ('frontend' | 'backend' | 'database' | 'infrastructure' | 'security') - filterProcess (optional): Filter by process ('development' | 'testing' | 'delivery' | 'operations') - filterStatus (optional): Filter by status ('active' | 'draft' | 'deprecated') - responseFormat (optional): Output format ('json' | 'markdown'), default 'markdown' Examples: - List all standards: {} - List backend standards: { filterTier: "backend" } - List active principles: { filterType: "principle", filterStatus: "active" }
Search standards by keyword with optional filters. Performs full-text search across both content and metadata of all standards. Returns results ranked by relevance with context snippets showing where matches were found. Parameters: - query (required): Search query string (minimum 2 characters) - filterType (optional): Filter results by type - filterTier (optional): Filter results by tier - filterProcess (optional): Filter results by process - filterTags (optional): Filter results by tags - limit (optional): Max results to return (1-50), default 10 - responseFormat (optional): Output format ('json' | 'markdown'), default 'markdown' Examples: - Search all: { query: "authentication" } - Search backend: { query: "security", filterTier: "backend" } - Limited results: { query: "testing", limit: 5 }
Update an existing standard's content or metadata. Modify an existing standard. The system automatically bumps the version number and updates timestamps. If metadata fields affecting the filename are changed, the file will be renamed. Parameters: - path (required): Path to the standard to update - content (optional): New markdown content - metadata (optional): Partial metadata object with fields to update - versionBump (optional): Version increment type ('major' | 'minor' | 'patch'), default 'patch' Note: Must provide either 'content' or 'metadata' (or both). Examples: - Update content: { path: "standard-backend-development-api-active.md", content: "# Updated API Standards\n..." } - Update metadata: { path: "...", metadata: { status: "deprecated" } } - Major update: { path: "...", content: "...", versionBump: "major" }
create_standard and update_standard lack confirmation or dry-run patterns. These are destructive operations (WRITE tools) that modify the standards knowledge base. There is no way to preview changes or request user confirmation before committing, risking accidental data loss.
Parameter constraints incomplete. E.g., query parameter in search_standards states 'minimum 2 characters' but no maximum is documented. The description says 'minimum 2 characters' but does not clarify if longer queries are accepted or if there is a practical limit.
get_standard requires 'either path OR combination of type/tier/process' but this constraint is only mentioned in prose notes, not validated in the schema itself. LLMs may pass both path and type, causing ambiguous behavior or silent misuse.