A Go implementation of the Model Context Protocol (MCP) server with support for tools, resources, prompts, and advanced MCP features
Single tool 'generate-wealthy-plan' has serious structural and documentation gaps. While the codebase shows good type infrastructure (ToolInputSchema, ToolOutputSchema with proper marshaling), the tool definition itself lacks sufficient description detail, has minimal parameter documentation, and provides no output schema validation. The input schema structure is present but parameter descriptions are generic placeholders ('Salary', 'Salary frequency Weekly, Semi-monthly, Monthly' rather than actionable LLM guidance). No evidence of error handling patterns, recovery guidance, or composition guidance for multi-step workflows. Tool name uses hyphenation (discouraged; verb_noun pattern preferred). No validation constraints (enums for frequency) visible in the schema. The Go type definitions show capability to declare OutputSchema, but no output schema is documented for the actual tool.
Generate a wealthy plan using the user salary
Tool description is minimal and lacks WHEN/WHY context. Currently: 'Generate a wealthy plan using the user salary'. Should explain: when to call this (e.g., 'Call when the user asks for financial planning advice'), what prerequisites exist, what the output contains, and how it feeds downstream tools.
Parameter 'frequency' has description 'Salary frequency Weekly, Semi-monthly, Monthly', this lists examples rather than declaring an enum constraint. LLMs will hallucinate invalid values (e.g., 'daily', 'quarterly'). Change to enum constraint with exactly three valid values, and update description to: 'The frequency of salary payment. One of: weekly, semi-monthly, monthly.'
No output schema documented in CallToolResult for this tool. The type infrastructure supports OutputSchema (visible in types/tool.go with ToolOutputSchema struct), but the actual tool registration does not define what structure the agent will receive. Without this, LLMs cannot plan downstream actions or validate the response.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Parameter 'salary' description is generic: 'Salary'. Does this accept numeric values, currency strings, ranges? Expected range? Currency (USD assumed?)? Format (e.g., '50000' vs '50000.00')? An LLM cannot determine whether to pass '100000' or 'one hundred thousand dollars'.
Tool name 'generate-wealthy-plan' uses hyphens instead of snake_case underscore convention (e.g., 'generate_wealthy_plan'). Inconsistent with MCP naming baseline (verb_noun pattern). More critically, 'wealthy' is vague, does this create a budget, investment plan, savings schedule, or tax strategy? Rename to clarify the specific financial output.
No error handling guidance visible. What happens if salary is negative, non-numeric, or exceeds system limits? What if frequency is invalid? Tool should return actionable error messages (e.g., 'Invalid frequency: got "daily", must be one of: weekly, semi-monthly, monthly') so the LLM can self-correct without human intervention.
No ToolAnnotations (readOnlyHint, destructiveHint, idempotentHint) declared in the tool definition. The Go type system supports this (visible in types/tool.go), but the actual tool registration does not populate it. Even a simple 'readOnlyHint: true' would help the LLM understand this is a safe read-only query.