Two tools present with explicit definitions in mcp_simple_tool/server.py. Both have basic descriptions and input schemas, but fall short of production quality. mcp_fetch has a minimal 49-char description lacking context about use cases, constraints, or error guidance. mood has a lengthy 236-char description that is descriptive but verbose. Neither tool has documented output schemas, error handling guidance, or parameter constraints beyond basic type declarations. Schemas are present and valid JSON Schema, but lack depth, no format specifications, min/max bounds, or patterns. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite MCP spec support. Error handling in the implementation is defensive (timeouts, HTTP errors caught) but responses are plain text error strings without recovery guidance. Parameter descriptions exist but are minimal, 'URL to fetch' and 'Ask this MCP server about its mood...' lack detail on accepted formats, constraints, or examples.

• Add output schema documentation to both tools. For mcp_fetch: document that it returns a TextContent object with fields {type: 'text', text: string}. For mood: document that it returns a constant cheerful message. Include this in the tool description or via a separate 'outputSchema' field if the MCP SDK supports it.
• Expand mcp_fetch description to 100-150 chars: 'Fetches and returns the HTML/text content of a website. Follows redirects, respects timeouts (10s), and handles HTTP errors. Returns plain text or HTML. Use this to read web pages, documentation, or public content.' This covers WHAT, WHEN, and WHAT IT RETURNS.
• Add format='uri' constraint to mcp_fetch 'url' parameter and a maxLength: 2048 bound. Add description detail: 'Must be a valid HTTP or HTTPS URL. Internal IPs and localhost are rejected.'
• Add readOnlyHint: true to both tools in their schema definition. This signals to agents that these tools are safe to call multiple times without side effects.
• Rename 'mood' tool to 'query_server_mood' or 'get_server_mood' to follow verb-first convention and clarify the action (query/get a state).
• Shorten 'mood' description and move examples into an enum-style format hint. New description (50-100 chars): 'Returns the server\'s cheerful mood. Always responds with an encouraging message and heart emoji (❤️). Question parameter can be any variation like \'How are you?\' or \'What\'s your mood?\'.' Then document that the response is deterministic.
• Implement structured error responses in the tool handler. Instead of 'Error: Missing required argument', return {error: 'missing_argument', parameter: 'url', message: 'Required parameter \'url\' not provided. Pass a valid HTTP/HTTPS URL.', recovery: 'Ensure the URL parameter is included and is a valid web address.'}. This lets the LLM understand errors categorically and self-correct.