Loading ToolBench
MCP server for managing structured bilingual novel projects with chapters, scenes, story-bible entities, and AI-powered writing assistance
Strong schema definitions with proper validation and clear descriptions. All 7 tools have explicit input schemas with type constraints, enums, and descriptions. Tool names follow verb_noun pattern (novel_create_*, novel_list_*, novel_get_*, novel_save_*, novel_finalize_*). Descriptions are detailed and action-oriented (avg ~150 chars). Key strength: strict ID validation (regex patterns, min/max lengths) and atomic operation semantics. Weakness: output schemas not documented in source; error handling guidance minimal; no pagination support for list operations; parameter descriptions could be more prescriptive about format/constraints.
Atomically append one chapter containing one fully planned scene to an exact project. Pinned story-bible IDs must belong to that project and their mention indexes are updated in the same transaction.
Atomically create a complete Inkstone project shell: project, first chapter, first scene, style, and optional story-bible entities. IDs are always generated by the server; no path or caller-selected internal ID is accepted.
Mark a project as complete and optionally publish it to an external destination. Requires the current project updatedAt value to prevent concurrent modifications.
Build a bounded, deterministic writing context for one exact project/scene ID, including prior scenes, pinned story-bible entities, style, a receipt, and a prompt-ready text block.
Return exact chapter and scene IDs in deterministic manuscript order, with planning metadata and word counts but without scene prose. Use it to resume a long-running MCP authoring workflow safely.
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Returns exact project IDs and summary counts') but JSON Schema output structure is not visible. LLMs cannot plan downstream tool calls without knowing response field names and types.
novel_list_projects accepts empty input schema (no parameters) but lacks pagination support. No limit, offset, or cursor parameters visible. Large workspaces could return unbounded results, exhausting context window.
Error handling returns structured JSON with 'error' and optional 'code'/'details' fields, but no recovery guidance. Errors like 'Project not found' do not suggest next steps (e.g., 'Call novel_list_projects to see available projects').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2025-06-18+ | v2 |
List projects in the configured Inkstone data workspace. Returns exact project IDs and summary counts; it never accepts a path.
Save a new immutable revision for one exact project/scene ID. By default it does not replace the scene; applying requires explicit opt-in plus the current scene updatedAt value.
Destructive operations (novel_save_revision with applyToScene=true, novel_finalize_project) require expectedSceneUpdatedAt/expectedProjectUpdatedAt for optimistic locking, but no dry-run or explicit confirmation step. Agents cannot preview changes before committing.
Parameter descriptions for novel_get_context's 'entityIds' state 'Exact story-bible entity IDs' but do not explain what a story-bible entity is or how to discover valid IDs. LLMs cannot infer whether to call a separate tool or use IDs from prior responses.