A Go SDK for building MCP (Model Context Protocol) servers with support for tools, prompts, resources, and extensions
The MCP SDK Go provides a framework for building servers but the tool definitions evaluated are minimal and problematic. Of the 4 tools examined, only 2 have substantive descriptions. The 'greet' tool appears twice with inconsistent descriptions (one is just 'greet', one is 'Greet someone by name'). The 'signup' tool has an empty input schema (just {"type":"object"}) with no properties defined, violating the requirement that input schemas specify what parameters are accepted. Only 'calculate' has a well-formed schema with typed enum and numeric properties. Descriptions vary from minimal ("greet", "Basic arithmetic") to moderately helpful ("Register with an email address"). No tool descriptions exceed 50 characters, and most fall below the 194-character baseline for production tools. Parameter descriptions are mostly missing, only the 'calculate' tool's parameters have type information; 'greet' and 'signup' lack parameter-level documentation. No output schemas are declared for any tool. The framework itself is sound (tool registration, handler pattern, schema validation infrastructure visible in server/tools.go), but the example tools do not demonstrate production-quality definitions.
Basic arithmetic
greet
Greet someone by name
Register with an email address
Tool 'greet' defined twice with inconsistent descriptions ('greet' vs 'Greet someone by name'), violating single responsibility and clarity principles.
Tool 'signup' has empty input schema ({"type":"object"} with no properties), making it impossible for LLMs to understand what parameters are accepted or required.
No tools declare output schemas (outputSchema field), preventing LLMs from understanding what fields to expect in responses or planning downstream tool calls.
Tool descriptions are minimal (10-50 characters vs. 194-char baseline), providing insufficient context for LLM tool selection. 'greet' and 'Basic arithmetic' lack WHEN and WHY context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | 2025-11-25+ | v1 |
Parameters in 'greet' and 'signup' tools lack descriptions. Only 'calculate' documents its parameters. LLMs cannot infer that 'name' in greet() means a person's name vs. a username.
No error handling guidance in tool descriptions. Agents have no indication of retryable vs. fatal failures, or what to do if 'name' is invalid in greet().