Static source inference · medium confidence · detected: stateful session
Deprecated protocol patterns detected
Summary
This server has severe definition quality issues affecting the majority of its 43 tools. The 4 well-defined tools (opinet_get_average_prices, opinet_get_lowest_price_stations, opinet_search_stations_around, opinet_get_station_detail, and dtryx_get_remaining_seats, lottecinema_get_remaining_seats) have proper Zod schemas with descriptions and enums, but represent only ~12% of the total. Descriptions across the server are present but mostly trivial (5-20 characters, mostly in Korean, lacking LLM-optimization guidance). Most tools lack parameter documentation entirely (empty {} inputs). The server registers 43 tools but only a handful meet production-grade definition standards. This is a classic case of breadth without depth, many integrations but poor metadata quality.
28 of 43 tools (65%) have completely empty input schemas with {}, zero parameter documentation, types, or constraints. Per hard scoring rule, schema score for these tools MUST be 0.
Add parameter schemas to all 28 tools with empty {} inputs. Minimum required: describe what parameters each tool accepts (location, store_id, product_name, etc.), their types (string, number, enum), and constraints (valid values, ranges).
Expand all 28 trivial descriptions from 5-25 characters to 50-150 characters. Follow LLM-optimized description template: 'WHAT [the tool does], WHEN [use it vs related tools], CONSTRAINTS [what it returns, limits]'. Example: 'Search for Daiso products by name. Returns product details, pricing, and store availability. Max 50 results per query. Use daiso_find_stores first if you need nearby store locations.'
Add tool annotations to all 43 tools. Mark READ_ONLY tools with readOnlyHint: true. Mark feedback_submit_developer_request with destructiveHint: true. For retryable tools like searches, add idempotentHint: true.
Document output schemas for all tools. At minimum, return structured objects with typed fields (e.g., products: [{id, name, price, availability}], stores: [{id, name, location, hours}]). Specify return limits and pagination (e.g., 'Returns max 20 results; use offset/limit for pagination').
For location-based tools (find_nearby_stores, find_nearby_theaters), standardize parameters: accept latitude/longitude OR location_keyword OR store_id, with radius_meters (default 3000, range 100-5000). Document parameter relationships: 'Provide either (latitude, longitude), location_keyword, or store_id. radius_meters applies to location-based searches only.'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained
Descriptions for 28 tools are trivial (5-25 characters, mostly Korean labels like '다이소 제품 검색'). These do not provide LLMs with sufficient context for tool selection and reasoning. Per hard scoring rule, descriptions under 20 characters score 0-20.
No tool annotations present (no readOnlyHint, destructiveHint, or idempotentHint). Most tools are READ_ONLY but this is not expressed in the tool definition, missing the pattern:tool-annotation capability expected in modern MCP servers.
Parameter descriptions completely missing for 28 tools (empty {} input objects). When tools accept parameters, they must be documented with type, format, and constraints. This forces LLMs to guess how to invoke these tools.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract data without knowing what fields are returned. No pattern:response-shaper compliance.
Tools like daiso_find_inventory_by_name and cu_find_nearby_stores appear to accept location/coordinate parameters but this is not documented in their schemas. Parameter relationships and dependencies are undocumented.
feedback_submit_developer_request is marked WRITE risk but has no error handling guidance, no schema validation, and no confirmation mechanism. Destructive operations should support dry-run or confirmation pattern:confirmation-request.
feedback_submit_developer_request
Add error handling guidance to all tools. For inventory/availability tools, document timeout behavior and what to do if a store API is unreachable. Example: 'If store inventory is unavailable, returns partial results with available stores. Retry with a reduced radius if timeout occurs.'
Separate all-in-one tools into single-responsibility tools. If daiso_find_inventory_by_name requires a store_id, split into: (1) daiso_search_products (by name, returns product_id), (2) daiso_check_inventory (product_id + store_id). This enables proper tool composition.
Add pagination support to search/list tools. Accept limit (1-50, default 20) and offset (or cursor) parameters. Return total_count or next_cursor so agents can retrieve large result sets efficiently.
For theater/cinema tools (cgv_get_timetable, lottecinema_get_remaining_seats, etc.), require movie_id, theater_id, and date parameters explicitly. Document valid date formats (YYYYMMDD vs YYYY-MM-DD) to prevent agent confusion.
Review feedback_submit_developer_request for destructive implications. Add a dry_run parameter or require explicit confirmation via a separate confirm_submission tool. Return a request_id so users can track submissions.
Translate or provide English summaries of Korean descriptions. Tool descriptions should be in the language the agent's LLM understands (typically English). Keep Korean context only if necessary for domain clarity.