This is a minimal proof-of-concept server with two arithmetic tools. Both tools have extremely short descriptions (7 and 7 characters respectively), lack comprehensive parameter documentation, have no output schema definitions, no error handling guidance, and no real-world applicability. The schema objects are present with proper type declarations for inputs, but descriptions fall well below the 34-character baseline floor for production tools. This server demonstrates basic tool structure but fails nearly every quality gate for agent-ready tools.

• Expand tool descriptions to 50 - 150 characters. Example for 'add': 'Add two numbers together. Returns their sum. Use this for simple arithmetic operations; for complex calculations, consider using a calculator tool.' This gives context for selection and documents the output type.
• Document output schema explicitly. Add a 'result' field specification: 'Returns: {result: number, expression: string}' to show the LLM what to expect and how to chain to dependent tools.
• Add parameter validation details in descriptions. Example: 'a (number): First operand. Range: -1e308 to +1e308. Required.' This prevents hallucinated invalid values.
• Implement MCP server scaffold with explicit transport declaration. Use Streamable HTTP (current) or HTTP+SSE. Include tool registration via MCP's tools/list and invocation via tools/call handlers.
• Add error handling that returns structured errors with recovery guidance. E.g., 'Invalid input: a must be a number, got "hello". Pass numeric values only.' instead of stack traces.
• Consider real-world tool composition. If this is a calculator service, add multiply, divide, sqrt, and batch_calculate to enable multi-step agent planning. Single-operation tools have limited value.
• Add idempotent operation hints if applicable. Since add/subtract are pure functions with no side effects, annotate them with 'idempotentHint: true' in the tool definition to signal that agents can safely retry.