Four tools with complete input schemas and descriptions, but descriptions are verbose (200-400+ chars) and lack LLM-optimized brevity. All tools are READ_ONLY with proper parameter constraints (enums, min/max, maxLength). Tool names follow verb_noun pattern (list_, search_, recommend_, design_). However, descriptions are written in Korean with English metadata, creating potential LLM parsing friction. Parameters are well-constrained but descriptions could be more concise. No output schema documentation visible. Error handling not evident in source.

• Condense tool descriptions to 50-200 chars in English. Current descriptions (200-400+ chars, Korean-heavy) waste tokens and reduce LLM clarity. Example: 'Search 96,056 public datasets by name, region, format, and license. Metadata-only; no live API calls.' (80 chars).
• Document output schemas for all tools. Specify: list_public_data_sources returns {sources: [{id, name, authority_level, review_state, enabled, record_count}], total_count, offset}. This enables LLMs to chain calls and extract IDs.
• Add error handling examples in tool descriptions. E.g., 'If no results found, try broader query or remove filters. If query exceeds 200 chars, truncate and retry.'
• For recommend_data_combination and design_public_data_product, add enum examples or validation rules in descriptions. E.g., 'goal: describe your service (e.g., "traffic congestion analysis", "air quality monitoring"). Max 2000 chars.'
• Add total_count and next_offset to search_public_datasets response to enable pagination. Document: 'Returns up to 100 results per call. Use offset to fetch next page. total_count shows total available.'

Inferred effective spec: 2026-07-28+.

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