This server demonstrates basic MCP functionality but has significant gaps in definition quality. Tool definitions are present with schemas and descriptions, but the quality is inconsistent. Descriptions are sparse and generic (averaging 30-50 chars, well below the 194-char baseline). Most tools lack comprehensive parameter documentation. The server uses mark3labs/mcp-go v0.38.0 and exposes 7 tools via HTTP. Critical issues: 'notify' tool has NO description at all, several tools lack descriptions entirely or are trivial, parameter documentation is incomplete, and no tool annotations (readOnlyHint/destructiveHint) are present despite clear risk distinctions. The schema definitions are present but descriptions do not guide LLM behavior effectively. No evidence of output schema documentation or error recovery guidance in responses.

• Expand all tool descriptions to 100 - 200 chars, following the pattern: WHAT does it do? WHEN should an LLM call it? WHAT does it return? For 'add': 'Performs addition of two numbers. Use when the agent needs to compute a sum. Returns { result: number }.'
• Add tool annotations to each tool registration. In mark3labs/mcp-go, expose readOnlyHint=true for tools marked READ_ONLY, and destructiveHint=true for 'notify'. Mark idempotent tools (echo, add) with idempotentHint=true.
• Document output schema for every tool. Add a 'Returns' section to descriptions or a separate outputSchema field if the framework supports it. Example: 'add' returns { result: number, explanation?: string }.
• Add parameter constraints to descriptions. For 'add': 'First number (integer or float; result precision is IEEE 754 double).' For 'longRunningOperation': 'Duration in seconds (1 - 3600); steps count (1 - 100).'
• Rename 'getTinyImage' to 'get_tiny_image' (consistency) and clarify the description: 'Returns a small embedded image (base64-encoded PNG). Use for testing image embedding in responses. Returns { image_base64: string, mime_type: string }.'
• Add a description and purpose to 'notify' immediately. Clarify: What event or entity is being notified? Example: 'notify: Sends a notification to the configured webhook or user channel. Use after completing a long operation. Returns { status: string, notification_id?: string }.'
• Define expected error responses and recovery steps. Example: 'If duration exceeds 3600 seconds, returns error_invalid_parameter with message: "duration must be 1 - 3600 seconds." Retry with a lower duration.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry