12 tools with complete JSON schemas and descriptions, but quality is uneven. All tools are READ_ONLY and follow verb_noun naming (mica_status, peg_deviation, etc.). Descriptions are present but brief (avg ~50 chars, well below the 194-char baseline). Parameters lack depth: most accept a single string with minimal constraint documentation. No enums, ranges, or format specifications. Output schemas are completely undocumented, LLMs cannot predict response structure. Error handling and recovery guidance absent. No tool annotations (readOnlyHint present in risk field but not in schema). Composition is reasonable (single responsibility per tool), but parameter descriptions need expansion to match production baselines.

• Document output schemas for all 12 tools. Example: 'Returns {status: string, compliant: boolean, details: object, last_updated: ISO8601}'. This enables LLMs to chain tools and extract the right fields.
• Expand parameter descriptions to 50-200 chars. Include format hints, valid ranges, and examples. E.g., 'token_symbol: The ticker symbol (3-5 uppercase letters, e.g., USDT, USDC, RLUSD)' instead of 'The token symbol to check'.
• Add enums and constraints to parameters. E.g., action: enum [custody, trading, settlement]; jurisdiction: enum [EU, US, UK, APAC]; top_n: integer, minimum 1, maximum 100.
• Add tool annotations to schemas. Include readOnlyHint: true for all tools (they are all READ_ONLY). This signals to LLMs that these tools are safe to call without confirmation.
• Add error handling guidance. Document what errors each tool can return (e.g., 'token_symbol not found', 'invalid jurisdiction code') and suggest recovery steps (e.g., 'Call list_supported_tokens() to see available symbols').

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

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