Single tool 'multiply' with minimal, generic description and completely undocumented schema. Tool definition is auto-generated from OpenAPI spec via FastMCP.from_openapi(), making it inferred rather than explicitly registered. Input schema visible but lacks proper parameter-level descriptions. No output schema documented. No error handling guidance. No composition guidance for chaining with other tools. Server is fundamentally a wrapper around a trivial FastAPI endpoint with zero production-grade tooling patterns applied.

• Explicit tool registration: Do not rely on OpenAPI auto-generation. Define tools directly in MCP schema with fastmcp decorators or explicit registration. This gives full control over naming, descriptions, and output schemas.
• Enhance tool description to 50-200 characters explaining what, when, and why: 'Multiply two numbers to calculate a product. Use when you need to compute area, scale values, or perform arithmetic calculations. Returns result as a floating-point number.'
• Add parameter constraints in descriptions: 'First number to multiply (any real number, including negative; floats and integers accepted)' and likewise for 'b'.
• Document output schema explicitly: Define in tool registration that multiply returns {a: number, b: number, result: number} with descriptions for each field.
• Add error handling: Validate inputs early in main.py and return structured error responses: {"error": "Invalid input", "details": "Parameter 'a' must be a number; got <type>"}. Provide recovery guidance in error messages.
• If this server will host multiple tools, design a composition strategy (e.g., 'multiply supports chaining with divide, sqrt, etc. for formula evaluation workflows'). If multiply is a trivial demo, consider a more realistic example tool for a production server.