This server has critically insufficient tool definition quality. While it registers 19 tools via explicit functions in src/tools/skills/index.ts, the actual input schemas, parameter descriptions, and return types are not visible in the provided source code. Tool registration appears to follow a pattern (registerLegalResearch, registerCaseResearch, etc.) but without access to the individual tool files (legal-research.ts, case-research.ts, etc.), we cannot verify schemas exist. The average across 19 tools with invisible definitions drops the overall score significantly. Tool names are reasonable (legal_research, case_research, tariff_lookup) and follow verb_noun patterns, but without seeing the schema files, descriptions, and parameter constraints, we must score conservatively. The descriptions provided in the briefing (e.g., '법령 및 판례 검색을 통한 법률 조사' for legal_research) are in Korean and do not meet the 10-1024 character English documentation baseline, they are also inferred from the briefing, not verified in source code. No evidence of output schemas, error handling patterns, or parameter validation is visible.

• URGENT: Provide the actual tool definition files (src/tools/skills/legal-research.ts, case-research.ts, etc.) so schemas and parameter descriptions can be verified. Current evaluation is capped at 50 per tool due to missing source visibility.
• For each tool, implement explicit input schemas in JSON Schema format with: (1) type declarations for every parameter, (2) descriptions (50-200 chars) for each parameter, (3) enums for constrained values, (4) examples of valid input. See Arcade pattern:tool-description.
• Document output schema for each tool. Specify the fields, types, and meanings agents will receive. Include fields needed for tool chaining (e.g., if a follow-up tool needs a case_id, ensure this tool returns it).
• Add error handling guidance to each tool's implementation: categorize errors (retryable, user-fixable, fatal) and return actionable messages like 'Law not found: try search_laws() with fewer keywords' instead of bare error codes.
• Implement tool annotations (readOnlyHint) in the schema registration for all tools marked READ_ONLY. This aligns with MCP spec 2026-07-28 and prevents agents from mistakenly planning retry loops on read operations.
• Rename generic tools for clarity: 'public_data' → 'search_public_data' or 'query_public_data'; 'gov24_ai' → 'search_government_services' or similar action-oriented name.
• Translate tool descriptions to English (currently in Korean). LLMs optimized for English will make better routing decisions with English descriptions.
• Add parameter constraints and examples directly in descriptions. E.g., 'query (required, 2-100 chars, e.g., '근로기준법'): The law name or keyword to search for'.

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

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