MCP server for Korean Standard Dictionary (ko-stdict) providing dictionary search and lookup capabilities
Four tools with complete schemas and descriptions. Naming follows verb_noun convention (search_, get_, refresh_). Descriptions are adequate (50-100 chars) but lack actionable context for LLM selection. Parameter schemas are well-typed with enums and constraints. Output structure is JSON but not formally documented. Error handling exists (isError flag) but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Missing dependency hints and per-parameter descriptions for some fields.
Return local dictionary cache and import status.
Look up a normalized dictionary entry by target_code.
Download the official dump again and rebuild the local SQLite database.
Search standard Korean dictionary entries by headword.
Missing tool annotations (readOnlyHint/destructiveHint). search_entries, get_entry, and dictionary_status should declare readOnlyHint=true; refresh_dictionary should declare destructiveHint=true. This helps LLMs reason about side effects and retry safety.
refresh_dictionary description lacks state-change clarity. Should explicitly state 'This tool modifies the local SQLite database and may take several minutes. It is not idempotent if called concurrently.' Current description omits side-effect severity and duration.
Output schemas not formally documented. Tools return JSON via structuredContent but no schema is declared for response fields (e.g., search_entries returns array of entries with fields like 'word', 'pos', 'definition'). LLMs cannot plan downstream operations without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Error handling lacks recovery guidance. get_entry returns isError=true with message 'Entry {target_code} not found.' but does not suggest next steps (e.g., 'Try search_entries() with a partial word'). Per pattern:recovery-guide, errors should guide the LLM toward resolution.
fields parameter description is generic. Should explain which fields are most useful for common tasks (e.g., 'Include definitions for full entry text, or omit for faster search results'). Current description 'Fields to include in each item' does not guide LLM selection.