소설 편집 리뷰 MCP Server - 외부 AI를 호출하여 에피소드 편집 리뷰를 수행합니다. review_episode(단건 리뷰), batch_review(일괄 리뷰), check_status(상태 확인)를 제공합니다.
The server defines 4 tools with Korean-language descriptions and basic parameter schemas. However, critical gaps severely limit LLM usability: (1) All descriptions are in Korean, making them inaccessible to English-speaking LLMs and agents; (2) Parameter descriptions are minimal or missing entirely, LLMs cannot infer intent from bare parameter names; (3) Output schemas are completely undocumented, agents cannot plan downstream operations or extract structured data; (4) No error handling guidance, agents have no recovery path on failure; (5) Tool names lack clarity, 'review_episode' vs 'batch_review' distinction is unclear, and 'compile_brief' is vague about what 'brief' means. These issues violate foundational patterns: tool-description, constrained-input, response-shaper, and recovery-guide. The server appears production-grade internally (file paths, environment config, timeout handling), but the tool interface itself is severely under-specified for agentic use.
일괄 리뷰 (정기 점검 P7용) - 여러 에피소드를 순차적으로 리뷰합니다.
외부 AI 서비스 상태 확인 - NIM Proxy, Ollama, Proxy 서비스의 가용성을 검사합니다.
소설 집필용 압축 브리프 생성 - 여러 소설 프로젝트 파일(~300KB+)을 읽어서 해당 에피소드 집필에 필요한 핵심 정보만 추출한 단일 마크다운 문서(~4-6KB)를 생성합니다.
단건 에피소드 리뷰 - 지정된 에피소드 파일에 대해 외부 AI 서비스(Gemini, GPT, NIM, Ollama, Proxy)를 호출하여 맞춤법/문법/대사 맥락 검토를 수행합니다.
All tool and parameter descriptions are in Korean, completely inaccessible to English-language LLM agents. This is a hard blocker for multi-language agent environments.
No output schemas documented for any tool. Agents cannot know what fields to expect (e.g., what does review_episode return?). This breaks downstream tool chaining and forces agents to hallucinate expected structure.
Parameter 'novel_dir' appears in 3 of 4 tools but has minimal description ('소설 프로젝트 디렉토리 경로'). No guidance on default behavior when omitted, path format expectations, or NOVEL_ROOT precedence. Ambiguous defaults invite invalid agent calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 29 | <=2025-11-25 | v2 |
No error handling guidance or recovery patterns. If review_episode fails (service timeout, invalid episode number, file not found), the description provides no hint about what to do next. Agents have no path forward on failure.
'review_episode' and 'batch_review' have overlapping intent. The naming does not clarify when to use one vs the other. Are they fallback patterns, or mutually exclusive workflows? The distinction should be explicit in names or descriptions.
'compile_brief' is vague. Does it generate a summary? An outline? A prompt context? The name does not convey the actual transformation (multi-megabyte novel files → 4-6KB markdown extract). Description text is in Korean and provides no English clarity.
Parameter 'episode_number' (integer) has no validation constraints. No min/max, no guidance on valid range. Agents can pass negative or absurdly large values, causing silent failures or server-side errors with no recovery hint.
'check_status' returns no documented structure. Is it a boolean? An object with per-service health? Free-form text? Agents cannot plan downstream actions without knowing the response schema.