Three tools are present with basic descriptions and visible schemas via FastMCP decorators. However, descriptions are generic and fall short of LLM-optimization standards (rubric baseline: 194 chars average, p90=392). Parameter descriptions are largely absent or minimal. Schemas are inferred from function signatures rather than explicitly documented. No parameter constraints (enums, ranges, patterns) are declared. Error handling is not visible in the source. Output structure is minimally documented ('returns dict with "currencies" or "data" key'). Tool names follow verb_noun pattern correctly, but parameter guidance is weak, agents will struggle to know valid currency codes, date formats, or whether symbols should be ISO codes. The composition is reasonable (three distinct, independent tools), but the definitions lack the rigor expected for A-grade tools.

• Expand each tool description to 100 - 250 characters. Follow the pattern: 'Fetch [what] [from where]. Use this when [context]. Returns [output structure]. Prerequisites: [if any].' Example: 'Fetch the latest exchange rates for a base currency vs one or more target currencies. Use this for current conversions. Returns {base, date, rates: {code: rate}}. Prerequisites: valid ISO 4217 codes.'
• Add explicit parameter descriptions in the FastMCP decorator. Example: '@server.tool(..., description="...") async def tool(base: str = "EUR", symbols: list[str] | None = None) -> dict:' should have inline docstring or explicit parameter docs. Include format, constraints, and examples. For 'date': 'ISO 8601 date string (YYYY-MM-DD), e.g. 2024-01-15'. For 'symbols': 'List of ISO 4217 currency codes, e.g. ["USD", "GBP"]'.
• Document output schema in each tool's docstring or via a Pydantic model. Example: 'Returns {"currencies": [{"code": str, "name": str}]}' or 'Returns {"data": {"base": str, "date": str, "rates": {code: float}}}'.
• Add validation and error recovery guidance. If invalid currency codes are passed, catch the error and return: 'Invalid currency code: "XYZ". Call get_available_currencies() to see valid codes.' This enables LLM self-correction.
• Declare parameter constraints explicitly. Use enums where appropriate (e.g. base could offer common defaults: EUR, USD, GBP) or regex patterns for dates. If free-form, state the format in the description.
• Add pagination support or document why it's not needed. If the server can return all currencies in a single call, state 'Returns all supported currencies in one response' to signal no pagination is required.