Loading ToolBench
MCP server that helps create other MCP servers -- the original meta-MCP, now modernized
This server shows strong schema quality with Zod definitions for all three tools and generally clear descriptions. Tool naming follows verb-first convention (meta_write, meta_validate, meta_list). However, there are notable gaps in parameter descriptions and error handling guidance. The descriptions are moderately detailed (100-250 chars range), meeting baseline expectations, but lack the LLM-optimized format that would push this to 80+. Output schemas are not explicitly documented in the tool definitions. The meta-builder use case is niche but well-scoped. Security consideration for write operations is present via risk marking but not comprehensive.
List available MCP server project templates. Returns structured information about each built-in template, including name, description, and the files it generates. No arguments required. Returns: An array of template objects, each with: - name: template identifier (e.g., "minimal-stdio") - description: human-readable template description - files: array of {path, content} objects that make up the template
Validate an existing MCP server project structure. Checks for required files and configuration that indicate a valid MCP server project: - package.json with @modelcontextprotocol/sdk dependency - tsconfig.json for TypeScript compilation - src/ directory for source files - build script in package.json Args: - outputDir (string): Directory path of the MCP server project to validate Returns: An object with a 'valid' boolean and 'issues' array. If valid=true, issues is empty. If valid=false, issues contains strings describing what is missing or misconfigured.
Create a new MCP server project by writing files to disk. Generates the directory structure and all specified files for a new MCP server. Directories are created recursively as needed. Args: - outputDir (string): Absolute or relative path for the new server project - files (array): File entries, each with a relative path and content string Returns: List of created files on success, or a structured error with guidance. Example: outputDir: "/tmp/my-mcp-server" files: [ { path: "package.json", content: "{...}" }, { path: "src/index.ts", content: "..." } ] IMPORTANT: After generating an MCP server, consider using code-mode or code-execution workflows to USE it efficiently. Naive tool-calling floods context with schemas. See: https://blog.cloudflare.com/code-mode/
meta_write_mcp_server lacks explicit error recovery guidance. Returns 'structured error with guidance' but the tool definition does not document what those errors are, their causes, or how the LLM should respond (retry, ask user, fail). This violates the recovery-guide pattern.
Output schemas are not documented in any tool definition. The rubric requires documentation of return types so LLMs can plan downstream operations. meta_write_mcp_server returns 'List of created files' but the structure (field names, types) is not specified. meta_validate_mcp_server returns 'object with valid boolean and issues array', partially clear but missing field type details. meta_list_templates returns 'array of template objects' but template object schema is not formally defined.
FileEntrySchema in the tool input schema uses required: ['path', 'content'] but the Zod definition does not show 'required' explicitly in the schema output, this appears correct in the code but is not clearly communicated to the LLM via the schema. The nested object structure is present but could be clearer.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 74 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 37 | - | v1 |
meta_write_mcp_server is marked with Risk: WRITE, indicating it performs destructive file operations. However, there is no confirmation/dry-run step or idempotency hint in the tool definition. If the tool overwrites existing files or deletes directories, the agent has no checkpoint to prevent accidents. Tool annotations should include destructiveHint: true.
No tool annotation hints visible in the function definitions in main.ts. The FEATURES declaration states toolAnnotations=true, but the actual tool.registerTool() calls do not include annotations object with readOnlyHint, destructiveHint, idempotentHint. meta_write_mcp_server should have destructiveHint:true; meta_validate_mcp_server and meta_list_templates should have readOnlyHint:true.
Parameter descriptions in the Zod schemas are present but minimal. For example, 'files' parameter description is 'Array of file entries to write. Each entry needs a relative path and content string.', this lacks context on file naming conventions, path restrictions, maximum file size, or what happens if a path already exists. Descriptions should be 50-200 chars of LLM-optimized guidance.