MCP server for looking up Kaikatsu Club store information and checking real-time vacancy status
Two tools with complete schemas and descriptions, but descriptions are overly long (Japanese text, 200+ chars) and lack LLM-optimized structure. Parameter descriptions are present but minimal. No output schema documentation. Error handling exists for check_vacancy but lacks recovery guidance. lookup_store lacks error handling entirely. Tool names are action-oriented (lookup_, check_) but descriptions read like API docs rather than agent guidance.
店舗コード(store_code)を指定してリアルタイムの空席情報を取得する.store_codeはlookup_storeで先に取得する.
快活CLUBの店舗をキーワード(店名/都道府県/市区町村/住所/店舗コード)で部分一致AND検索する。「北海道 旭川」のように複数語で絞り込み可能。結果には対応サービス・シート・遊び情報も含む。※1&2カラオケはヒトカラとも言われる. 返り値に含まれるstore_codeで店舗検索を行える.
Descriptions are 200+ characters and lack LLM-optimized structure. Both tools have verbose Japanese descriptions that bury key intent. Should be 50-150 chars with clear WHAT/WHEN/HOW structure.
No output schema documentation. lookup_store returns Store[] with nested playables object; check_vacancy returns Vacancy with seat_type array. LLMs cannot plan downstream calls without knowing response structure.
lookup_store has no error handling. If keywords array is empty or all results exceed LOOKUP_LIMIT, no guidance provided. check_vacancy catches errors but messages lack recovery hints (e.g., 'Invalid store_code. Call lookup_store first to find valid codes.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Parameter descriptions are minimal. 'keywords' describes the array structure but not what constitutes a valid keyword or how AND search works. 'store_code' example '20176' is hardcoded, should explain format or reference lookup_store output.
lookup_store truncates results silently (LOOKUP_LIMIT=10) but returns total count. No pagination parameters (limit, offset) offered. If 500 stores match, agent gets 10 with no way to fetch more without re-querying with narrower keywords.