MCP helper library for creating type-safe MCP servers with Zod schema validation
This MCP server exposes 3 tools (with 1 duplicate) with significant definition quality gaps. Naming is inconsistent and generic (getStringLength appears twice, readUrl lacks verb prefix). While schemas are formally present via Zod definitions and converted to JSON Schema, descriptions are minimal, most under 50 characters and lacking actionable context for LLM tool selection. The server is a lightweight helper/framework rather than a fully-featured tool provider; it demonstrates how to scaffold MCP servers but the example tools themselves fail production readiness checks. No parameter validation guidance, no error recovery hints, no output schema documentation, and critical naming issues (duplicate tool, non-action verb in readUrl).
Get length of input string
Get the length of a string
URLを読み込み本文を抽出した結果を Markdown にします。
Duplicate tool definition: getStringLength appears twice (examples/getStringLength.ts listed twice in tools list). This causes ambiguity and potential routing failures.
readUrl does not start with a verb that reflects the action. The pattern requires verb_noun naming (get_, create_, update_, delete_, search_). 'readUrl' is closer to 'read_url' but the camelCase and lack of object clarity hurt LLM parsing. Should be 'get_webpage_markdown' or 'read_url_as_markdown'.
Descriptions are too short and lack actionable context. 'Get length of input string' (29 chars) and 'Get the length of a string' (25 chars) do not explain when to call this vs alternatives, what it returns, or prerequisites. Baseline for A+ tools is 50-200 chars with WHEN/WHAT/RETURN detail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
readUrl description is in Japanese ('URLを読み込み本文を抽出した結果を Markdown にします') and lacks English context. LLM clients may not handle non-English tool descriptions reliably. Baseline tools should be documented in English with locale-neutral examples.
No output schema documentation visible in tool definitions. While the code internally uses Zod outputSchema (e.g., z.number() for getStringLength, z.string() for readUrl), these are not exposed to the LLM in the tool registry. The ListToolsRequestSchema response includes only inputSchema, not outputSchema.
No error recovery guidance. If readUrl receives a malformed URL or network failure, the error message is a bare exception string with no guidance on what to do next. Should return 'URL invalid: [reason]. Try a well-formed HTTP/HTTPS URL.' or similar.
Parameter descriptions are minimal. 'The input string' (16 chars) and 'The URL to read' (14 chars) lack format guidance. Should specify: 'The input string (any UTF-8 text, no length limit)' and 'The URL to read (must be a valid HTTP/HTTPS URI; timeout 30s)'.