A Go implementation of the Model Context Protocol (MCP) server framework enabling tool registration, prompt templates, and resource serving via stdio or HTTP transports
This MCP server has significant definition quality gaps. Tool definitions are present and mostly follow basic JSON Schema patterns, but lack critical elements for production use. Names are action-oriented but descriptions are generic and lack context. Parameter descriptions are minimal (averaging 30-50 chars vs. the 72-char baseline). Most critically, the server registers 8 tools but only 2 are truly distinct (hello and get_weather appear 5 times with slight schema variations, time appears 2 times, calculate and other tools are inferred from client examples). Output schemas are undocumented. Error handling is absent, tools either return success or panic. Parameter validation is missing. No guidance on when to call which tool variant. Security considerations for weather API calls are absent.
Performs basic mathematical operations
Get the weather forecast for temperature, wind speed and relative humidity
Say hello to a person
Say hello to a person
Says hello to the provided name
Say hello to a person
Returns the current time
Returns the current time in the specified format
Duplicate tool registrations with incompatible schemas: 'hello' appears 5 times with different parameter structures (submitter only vs. submitter+content vs. name). LLMs cannot disambiguate which variant to call.
Tool descriptions are generic and lack actionable context. 'Say hello to a person' (24 chars) does not explain when to use hello vs. other tools, what it returns, or what the parameters control. Baseline is 194 chars.
Parameter descriptions are minimal (average 30-50 chars vs. 72-char baseline). E.g., 'format' parameter for time tool has description 'Optional time format (default: RFC3339)' but does not explain valid format strings, RFC3339 syntax, or alternatives.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
No output schema documentation. Tools return ToolResponse with Content array, but LLMs do not know what fields to expect in the response. Baseline: 100% of A+ tools document return types.
Error handling is missing. All tools use panic(err) or return raw errors with no recovery guidance. LLMs cannot determine if errors are retryable or what to do next.
No parameter validation. The 'operation' enum in calculate is defined in schema but there is no validation in the handler. get_weather accepts any latitude/longitude without range checks.
Tool names 'time' and 'calculate' are generic. 'get_time' would be clearer. 'calculate' lacks the operation it performs, 'perform_math_operation' or 'calculate_arithmetic' would be more specific.
get_weather tool calls external API without timeout, retry logic, or rate limiting. An unresponsive weather API will block the agent indefinitely.
Tool definitions are inferred from example code (client/main.go) rather than explicitly visible in the server registration. Cannot verify actual schema, description, or handler implementation.