Single tool with critically underdeveloped definition. MyTool1 has only a generic, unhelpful description (28 chars: 'Something something, tool, something something'). Parameter schema is present but description is minimal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tool appears read-only by design but this is not reflected in metadata. No error handling guidance, no output schema documentation, no examples of when/why to call this tool. The description fails the 20-character minimum threshold and reads like placeholder text. The codebase shows HTTP transport and basic MCP integration, but the tool definition quality is far below production baseline.

• Rewrite tool description to 50-200 characters following pattern:tool-description. Example: 'Fetch and return detailed information about a resource. Call this when you need to retrieve specific data or verify resource state.' Then add WHEN to use, WHAT to expect, and any prerequisites.
• Rename 'MyTool1' to an action-verb pattern reflecting actual behavior. If the tool reads data: use get_, search_, or list_ prefix (e.g., 'get_resource_metadata', 'search_resources'). Verify verb matches the semantic action in code.
• Document the output schema explicitly. In ListTools response, add outputSchema field or extend description to state: 'Returns a JSON object with fields: [field_name (string), field_description]. Example response: {"status": "ok", "data": "..."}'
• Add tool annotations to Tool definition. Set readOnlyHint=true since tool does not modify state. If any tool is destructive, set destructiveHint=true. If repeatable without side effects, set idempotentHint=true.
• Enhance param1 description from 'An example parameter' to something specific: '[Description of what this param controls] Must be a [type] in range [constraints] or matching pattern [regex]. Example: value123. If unsure, call [discovery_tool] first.'
• Implement error handling with actionable guidance. Instead of generic MCPError, catch specific failure modes and return: 'Resource not found with param1="[value]". Try searching with a partial name using search_resources first.' Include available alternatives if discovered.
• Remove the three 3-second sleep blocks from CallTool handler. They serve no visible business purpose and degrade latency for every invocation. If the delays are load-testing artifacts, move them to a separate test tool or remove entirely.

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained