小説投稿サイト、カクヨムを読むためのMCPサーバー (MCP server for reading content from Kakuyomu, a Japanese fiction posting site)
kakuyomu-mcp exhibits significant definition quality gaps across multiple dimensions. All 5 tools have proper verb-starting names (get_, search_) and schema definitions with typed parameters. However, tool descriptions are brief but present (ranging 20-60 chars), and parameter descriptions are minimal or missing. The schema quality is variable: most tools have type-annotated parameters with basic descriptions, but lack depth in explaining semantics, constraints, and error conditions. Output is returned as plain text strings rather than structured JSON, limiting LLM composability. No tool annotations (readOnlyHint, idempotentHint, destructiveHint) are present. Error handling is minimal, catch-all exception handlers return generic error messages without actionable recovery guidance. The server targets a Japanese content aggregation domain (kakuyomu.jp) with domain-specific parameters (serial_status, genre_name, review_point_range), but constraint documentation is sparse. Parameter validation is implicit; no explicit enum enforcement or range validation is visible in the code.
特定のエピソードの本文を取得
カクヨムのランキングページから作品ランキングを取得
カクヨムのトップページから最新作品一覧を取得
特定の作品のエピソード一覧を取得
カクヨムで作品を検索
All tools return plain text strings instead of structured JSON objects. This violates the response-shaper pattern and forces LLMs to parse unstructured output, increasing error rates and token waste. Example: get_top_page returns a formatted text block instead of {"works": [{"id": "...", "title": "...", "author": "..."}]}.
search_works has 11 parameters, many of which are under-documented. Parameters like 'serial_status', 'genre_name', 'total_review_point_range', 'total_character_count_range' lack descriptions explaining valid values, enums, or format constraints. The code shows 'optional_params = {"ex_q": ex_q, ...}' but the schema definitions are incomplete.
No pagination metadata is returned. Tools like get_top_page and search_works accept 'limit' but do not return total_count, next_cursor, or page information. LLMs cannot determine if results are truncated or request the next batch.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Error handling is generic and non-actionable. All tools use try-catch with 'return f"エラーが発生しました: {str(e)}"', which provides no guidance on recovery, retryability, or root cause. Example from get_top_page: logger.error logs the exception, but the user-facing message is opaque.
No tool annotations present. None of the 5 tools declare readOnlyHint, destructiveHint, or idempotentHint. All tools are read-only (accessing kakuyomu.jp), so marking them with readOnlyHint would clarify to agents that they are safe to call speculatively.
Parameter descriptions are minimal. Examples: 'work_id' is described as 'Work ID' (only 7 chars); 'ex_q' is 'Exclusion query (optional)' (25 chars, but no example format); 'genre_name' has no description visible in code.
No output schema documentation. Code defines works_to_string(), episodes_to_string(), rankings_to_string() as free-text formatters, but there is no formal schema declaration for what fields are returned, their types, or availability. LLMs cannot plan downstream tool calls without knowing output shape.