Loading ToolBench
句碑APIのMCPサーバー (Kuhi API MCP Server - A server providing access to the Kuhi (Japanese haiku monuments) API)
Four read-only tools with decent parameter schemas and descriptions, but significant gaps prevent a higher score. Tool names follow verb_noun convention well (get_, find_, explore_, learn_). Descriptions are present but some are verbose (tourism tool descriptions exceed 500 chars, approaching token-waste territory). All tools have documented input schemas with types and descriptions. However, output schemas are NOT documented in any tool, this violates the pattern:tool-chain requirement that downstream tools need to know what fields to expect. The tourism tool has excellent contextual descriptions explaining user intent (e.g., 'Call explore_monuments_for_tourism first to search, then learn_about_monument for details'), but the server lacks error handling guidance and recovery patterns. No tool declares risk categorization or idempotency hints (missing toolAnnotations per spec). Parameter validation appears server-side but is not articulated in descriptions.
観光向けの句碑探索を支援します。 このToolは以下のユーザーの意図に対応します： - 特定の俳人の句碑を観光したい - 季節に合った句碑を訪れたい - 地域を絞って効率的に巡りたい 返却データ: - 句碑の基本情報（名称、場所、句、解説） - アクセス情報（緯度経度、住所） - 周辺の関連情報
類似の句碑を検索
句碑データベースに登録されている句碑の情報をGeoJSON形式で表示
特定の句碑について深く理解するための詳細情報を提供します。 このToolは以下のユーザーの意図に対応します： - 句碑の背景や歴史を知りたい - 俳人の作品について学びたい - 句碑の設置経緯や意義を理解したい 返却データ: - 句碑の全詳細情報 - 関連する俳人の情報 - 碑文の解説と背景 - 設置場所の詳細情報
Output schemas not documented for any tool. LLMs cannot plan downstream calls without knowing what fields each tool returns (GeoJSON structure, search results format, monument details schema, etc.). This breaks the tool-chain pattern and forces agents to guess at response structures.
Tool descriptions lack error recovery guidance. 'If monument_id not found...' or 'If search returns no results, try broader parameters' would help agents self-correct instead of dead-ending.
explore_monuments_for_tourism description (550+ chars) and learn_about_monument description (~400 chars) are verbose and risk token waste. Descriptions should be 10-1024 chars but optimally 50-200 chars for LLM efficiency. Current versions include redundant intent bullets.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 53 | - | v1 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. While all tools are read-only (low risk), explicit annotations per current MCP spec would clarify intent and enable agent reasoning about retry safety and side effects.
Parameter 'monument_id' (learn_about_monument) lacks guidance on how agents discover valid IDs. Description says 'If ID is unknown, use explore_monuments_for_tourism', good! But should also clarify whether the ID is a numeric index or a canonical identifier, to prevent LLM confusion.