This server has significant definition quality gaps despite attempting comprehensive tool coverage. Of 7 tools, only 3 have descriptions that reach the 20-character minimum (crawl_list, get_detailed_attributes, server_info). The 4 Korean-language tools (call_public_data_standard_api, call_procurement_statistics_api, call_product_list_api, call_shopping_mall_api) have descriptions but they are primarily API operation names without actionable context for LLM tool selection. Input schemas are present and well-structured with type definitions and parameter descriptions, but the shallow tool descriptions and lack of output schema documentation are critical gaps. Tool naming follows verb_noun convention (crawl_, get_, call_) which is good, but there is no evidence of error handling guidance, field-level output schemas, or composition guidance for multi-step procurement workflows.

• Rename call_public_data_standard_api, call_procurement_statistics_api, call_product_list_api, call_shopping_mall_api to action-driven names: search_bid_notices, search_contracts, search_products, search_mall_products (or list_* if read-only discovery is the intent). This makes the tools self-documenting.
• Add English-language descriptions (50-150 chars) for all four Korean API tools. Example for call_public_data_standard_api: 'Search Korean government procurement data (bid notices, winners, contracts) by date, institution, or product category. Use this before detailed_product_search for aggregated market trends.'
• Document the output schema for every tool. Include field names, types, and what IDs/references are returned. Example: crawl_list returns {products: [{id, name, category, price, ...}], total_count, page, page_size}.
• Add nested schema for api_item parameter in get_detailed_attributes. Specify which fields from crawl_list output are expected (e.g., product_id, category).
• For pagination tools, add 'Results are limited to {default} items per page. Maximum page_size is {max}. Total available results returned in total_count field. Use page_no to iterate.' to the description.
• Add error recovery guidance to tool descriptions: 'If API returns 429 (rate limit), wait 60 seconds before retrying. If 404 (not found), check the category name using server_info.' This matches pattern:recovery-guide.
• Consider adding tool annotations (_hint fields) to distinguish read-only discovery tools (crawl_list, get_detailed_attributes) from stateful API calls (call_* tools that may update server state). Use readOnlyHint=true for safe tools.

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

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