Loading ToolBench
MCP Maker is a boilerplate/template generator with 8 tools. Strengths: all tools have descriptions and explicit Zod schemas with parameter types. Weaknesses: descriptions are thin (mostly 50-100 chars, below the 194-char production baseline); parameter descriptions are sparse (many missing); output schemas are undocumented; error handling is minimal; no tool annotations (readOnlyHint/destructiveHint); return types are not specified; composition issues (all tools write files independently without cross-tool chaining). The server targets MCP development itself rather than external APIs, which constrains applicability but doesn't excuse the definition gaps.
Generates template code for a new MCP prompt
Generates template code for a new MCP resource
Generates template code for a new MCP tool with customizable parameters
Generate an MCP server template with context from the documentation
Creates a new MCP server project with all the necessary boilerplate files
Get a specific section of MCP documentation by key and section title
Saves MCP documentation text directly and stores it for future reference
All 8 tools lack documented output schemas. Tool descriptions in server.ts show only {content: [{type: 'text', text: ...}]} but the actual structured response (success flag, filePath, results array for search, etc.) is undocumented. LLMs cannot extract or chain results.
Tool descriptions are uniformly thin (42 - 73 chars, median ~55 chars, vs. 194-char production baseline). None explain when to use one tool vs. another (e.g., generate_mcp_boilerplate vs. generate_doc_enriched_template), failure modes, or success criteria. LLM selection guidance is minimal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Search through stored MCP documentation for relevant information
Parameter descriptions within Zod schemas are sparse or generic. E.g., 'Array of tool parameters' in create_tool_template does not explain the nested object structure (name, type enum, required, description fields). LLMs cannot infer valid parameter shapes from these descriptions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 8 tools perform file I/O (WRITE risk) but only 2 are labeled READ_ONLY (search_mcp_docs, get_mcp_doc_section). LLMs cannot distinguish safe from destructive tools without explicit hints.
Error handling is minimal. Tools return {success, message} but offer no recovery guidance. E.g., if create_tool_template fails because tool_name already exists, the message 'A tool with the name "X" already exists' does not suggest next steps (rename, overwrite, etc.).
No parameter validation constraints beyond type. E.g., project_name and output_dir lack length limits, pattern validation, or character restrictions. LLMs can pass invalid paths or names; tools validate and reject, but errors don't guide correction.
Tool composition is one-directional. All tools write templates/docs independently. No tool accepts the output of another as input (e.g., no tool that reads a generated template and publishes it). Generated files are only useful outside the MCP server, limiting agent workflows.
Doc storage is ephemeral (in-memory). save_mcp_docs and search_mcp_docs do not clarify persistence: are docs lost on server restart? No API for exporting stored docs. Agents cannot reliable persist knowledge across sessions.