This MCP SDK has significant definition quality issues. While 14 tools are declared, most lack proper input schemas, comprehensive descriptions, and output documentation. Tool naming follows some verb conventions (list, call, read, get), but descriptions are sparse or generic. Parameters are mentioned in only 3 tools with partial schema details. No output schemas are documented. Error handling and recovery guidance are absent. The server implements deprecated MCP patterns (Sampling, Roots, Logging) without clear migration path, and several tools lack evidence of proper registration in the source code provided.
Missing input schemas: 11 of 14 tools have no visible input schema definition. Only tools/call and logging/setLevel show partial schema structures. Per HARD SCORING RULES, tools without schemas must score 0 on schema dimension.
Generic/insufficient descriptions: All 14 tools have descriptions under 100 characters, most under 60. Descriptions like 'List available tools' and 'Read a specific resource' lack context on WHEN to use the tool, dependencies, and expected output structure. LLMs cannot reliably select tools based on these minimal descriptions.
Add complete JSON Schema definitions (type, description, required, enum) for all tool inputs. Example for tools/call: {"type":"object", "properties": {"name": {"type":"string", "description":"Name of the tool (e.g., 'send_email', 'create_task'). Used to dispatch to the registered handler."}, "arguments": {"type":"object", "description":"Parameters for the tool. Structure depends on the specific tool being called."}, "_meta": {"type":"object", "description":"Metadata including progressToken for streaming updates and traceId for logging."}}, "required": ["name", "arguments"]}
Expand all tool descriptions to 100-200 characters following pattern:tool-description. Example: 'Calls a previously-discovered tool by name with supplied arguments. Returns the tool's output or an error. Use this after tools/list to invoke a specific action.' Each description should include WHAT, WHEN, and expected output.
Document output schema for each tool. Example for tools/list: {"type":"object", "properties": {"tools": {"type":"array", "items": {"type":"object", "properties": {"name": {"type":"string"}, "description": {"type":"string"}, "inputSchema": {"type":"object"}}}}}}
Add parameter descriptions for logging/setLevel specifying valid log levels (debug|info|warn|error|critical), constraints, and behavior. Example: 'level (string, required): The logging level to set. Valid values: debug (verbose), info (normal), warn (warnings only), error (errors only), critical (failures only). Affects subsequent server and client log output.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Sampling (deprecated) - integrate directly with the LLM provider API
No output schema documentation: Zero tools document their output structure or return types. Agents cannot understand what fields to expect or plan downstream calls. This violates baseline expectation that 100% of A+ tools have documented return types.
Missing parameter descriptions: Of the 3 tools with visible parameters (tools/call has 'name', 'arguments', '_meta'; logging/setLevel has 'level'), only tools/call shows any param descriptions. logging/setLevel's 'level' parameter lacks guidance on valid values (debug, info, warn, error, etc.), ranges, or constraints.
No error handling or recovery guidance: No tool describes what errors it can return, when they occur, or how agents should recover. Pattern:recovery-guide requires error responses to tell LLMs what to do next; these tools provide none.
Ambiguous naming in resource tools: 'resources/read' does not clarify whether it reads resource metadata, content, or both. Similarly, 'resources/templates/list' vs 'resources/list' lacks clarity on the distinction. Per naming baseline, overlapping names force LLM disambiguation effort and increase errors.
Deprecated patterns present: Server implements sampling/createMessage, roots/list, and logging/setLevel, all deprecated or removed in spec 2026-07-28. No migration path or documentation on why these are retained. Current spec favors direct LLM integration and per-request log level control.
sampling/createMessageroots/listlogging/setLevel
Implement error handling per pattern:recovery-guide. For each tool, document predictable errors and recovery: e.g., tools/call returns 'Tool not found: check tools/list for available names' instead of bare error code.
Clarify resource tool semantics: rename or expand descriptions to distinguish resources/read (read resource content) from resources/templates/list (discover available resource templates), and from resources/list (enumerate all resources).
Migrate away from deprecated patterns: (1) Remove sampling/createMessage or document integration with native LLM sampling; (2) Remove roots/list or explain use case; (3) Migrate logging/setLevel to per-request _meta logLevel control per spec 2026-07-28.
Add parameter constraints to tools/call's 'arguments' parameter: 'Must be a valid JSON object matching the target tool's inputSchema. Omit required params only if the tool has defaults.'
Document idempotency for read-only tools (ping, tools/list, resources/list, etc.). Example: 'ping: Idempotent. Multiple calls with same input produce same result and have no side effects.'
For state-modifying tools (logging/setLevel, resources/subscribe, resources/unsubscribe), explicitly state what state changes, whether the change is persisted, and how to verify success.