OpenDart MCP provides 8 tools for querying Korean financial data via the DART API. The implementation demonstrates solid structural organization with clear tool registration in fastmcp, but falls short of production-grade quality in several critical dimensions: (1) All parameter descriptions are present and reasonable, meeting the baseline of 100% param coverage. (2) Tool descriptions are substantive (avg 150 chars), exceeding the baseline minimum. (3) However, input schemas are either implicit in function signatures or lack explicit JSON Schema documentation, the source does not show formal schema objects with type/description pairs beyond function annotations. (4) Several tools lack error handling guidance beyond implicit 'returns dict' patterns, violating pattern:recovery-guide. (5) Descriptions use Korean language extensively, which is culturally appropriate but does not follow LLM-optimized English baseline (50-200 chars, action-oriented). (6) The 'get_financial_statement' tool description explicitly instructs the LLM on output formatting ('숫자 단위를 1억 2천만원과 알아보기 쉽게 정리해주세요'), which is a tool-facing instruction, not a tool definition, this pollutes the schema with operational hints that belong in system prompts.

• Add formal JSON Schema documentation to each tool. Explicitly define input 'properties', 'required' fields, 'type', and 'enum' constraints. Example: 'reprt_code' in 'get_financial_statement' should be declared as enum: ['11011', '11012', '11013', '11014'] instead of a free-form string.
• Document return schemas for all tools. Add a 'Returns' section in docstrings specifying the structure of the response dict/list. Example: 'get_debt_information_summary_details returns dict with keys: "회사채 미상환 잔액", "기업어음증권 미상환 잔액", ... and their types (str, int, float, etc.)'.
• Provide English-language descriptions (or bilingual) for tool definitions and parameters. LLMs trained primarily on English corpora handle English descriptions more reliably. Example: 'get_today' → 'Retrieve today\'s date in YYYYMMDD format.'
• Remove operational instructions from tool descriptions. Move formatting directives (e.g., 'format numbers as 1억 2천만원, always explain in detail') to the system prompt or output schema documentation, not the tool definition.
• Add numeric bounds to parameter 'k' in 'find_company_by_name'. Example: 'k (int): Number of results to return. Must be between 1 and 100. Default: 10.'
• Document error conditions and recovery paths. For each tool, explain: (1) what success looks like (example response), (2) what failure modes exist (no company found, API unavailable, invalid corp_code), (3) what the LLM should do in each case (retry, call search tool, ask user).
• Add pagination to list-returning tools. Introduce 'page' and 'limit' parameters (or cursor-based pagination) and return total_count and next_cursor in responses. Example: 'get_company_financial_statement_list' should cap results at 50 and offer pagination.

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

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry