Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Narracore Format Format this rough scene into screenplay blocks: INT. LAB - NIGHT. A scientist waits."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | Español | Français | 日本語 | 한국어 | 繁體中文
Free, local, unlimited screenplay formatting for AI agents. An open-source MCP server (and DSH plugin) that turns raw or loosely formatted screenplay text into professionally structured screenplay blocks and typeset plain text — Chinese, English, or mixed — including Japanese broadcast-drama format and Chinese colon-style dialogue scripts. The layout engine picks the right track automatically: a 33-char × 38-line CJK grid or a 61 × 55 Latin grid, the same fixed typewriter character grid as narracore.cn.
Free forever — runs on your machine, no account, no key, no quota, no network calls
Deterministic — pure rule-based engine, no LLM inside; same input always yields the same output, byte for byte
Agent-native — machine-readable diagnostics, evidence-anchored scene scoring, typed-blocks chaining contract across tools
Part of the Narracore toolkit — the long-form co-writing workbench. Looking for print-ready PDF export or the full story-continuity tooling? See the ecosystem below.
Rough text in — typeset screenplay out. Both directions below are real engine output.
Input — loosely formatted text, one element per line:
第 1 场 内 老式放映厅 - 夜
放映机的光柱切开黑暗，尘埃在光里悬浮。
常家青坐在最后一排，手里攥着一张褪色的电影票。
常家青
（低声）
如果胶片还在，就能证明那晚的一切。
检票员从阴影里走出来，把手电筒照在票面上。
检票员
这张票，二十年前就该作废了。
常家青站起身。光柱突然熄灭。
切至黑暗Output — plain_text from format_screenplay (scene heading, action, character,
parenthetical, dialogue, right-aligned transition — all on the fixed grid):
第 1 场 内 老式放映厅 - 夜
放映机的光柱切开黑暗，尘埃在光里悬浮。
常家青坐在最后一排，手里攥着一张褪色的电影票。
常家青
（低声）
如果胶片还在，就能证明那晚的一切。
检票员从阴影里走出来，把手电筒照在票面上。
检票员
这张票，二十年前就该作废了。
常家青站起身。光柱突然熄灭。
切至黑暗Input:
INT. PROJECTION BOOTH - NIGHT
The projector beam cuts through the dark.
CHANG
(quietly)
If the reel still exists,
it proves that night was real.
CUT TO BLACK.Output:
INT. PROJECTION BOOTH - NIGHT
The projector beam cuts through the dark.
CHANG
(quietly)
If the reel still exists,
it proves that night was real.
CUT TO BLACK.The same call also returns typed blocks (scene / action / character / parenthetical /
dialogue / transition / shot / note), page stats, and machine-readable diagnostics — feed
those blocks back to any other tool in this package for analysis or conversion.
Related MCP server: dsh-novel-writer
dsh plugin add narracore-formatThat's it. Your agent gets five tools under the mcp__narracore__* namespace.
The package is a standard stdio MCP server, so any MCP client can run it directly:
// Claude Code: claude mcp add narracore-format -- npx -y narracore-format@latest
// Cursor / generic MCP config:
{
"mcpServers": {
"narracore-format": { "command": "npx", "args": ["-y", "narracore-format@latest"] }
}
}Requires Node ≥ 22.
Tool | What it does |
| Parse screenplay text (or typed blocks) into 8 semantic block types, typeset plain text, page stats, and diagnostics. |
| Deterministic statistics: scene list with structured headings (number / location / time of day / INT-EXT), per-scene word count, dialogue ratio, action density, character share table. |
| Scene-level "shootability" diagnosis: the agent cites evidence per scene, the tool validates it verbatim and computes exact 0–100 scores (severity-weighted coverage, BigInt arithmetic — never fakes a score). |
| Convert between Narracore typed blocks and Fountain, the plain-text screenplay interchange format. |
| Ecosystem overview — what else Narracore offers. |
Chaining contract: to run another tool on the same screenplay, pass back the blocks
you received (input_format="blocks"), not the formatted plain text — blocks parse
deterministically; text re-parses.
narracore.cn — the full long-form co-writing workbench this toolkit comes from: screenplay and story writing with the same typesetting, plus story-window continuity tooling that goes beyond a local formatter.
narracore.app — the hosted MCP service built on the same pipeline, adding a print-ready PDF export with embedded fonts (cover page, running headers, signed download links). You can buy N uses of the formatting service there if you want the PDF pipeline without installing anything.
The layout engine in src/format/ is the same single source of truth used by narracore.cn.
It is ported verbatim from the Narracore codebase (provenance hashes in
src/format/README.md), and snapshot tests pin it byte-for-byte —
green snapshot tests are the machine proof that this package lays out text identically to
the narracore.cn web app. The analysis layer (src/analysis/) is a TS port of the Narracore
analyzer, locked by golden tests generated from the original implementation.
npm install
npm test # 162 tests: snapshots, golden samples, tool layer, stdio e2e, billing-free guard
npm run build # esbuild single-file bundle → dist/index.js
npm start # run the stdio serverGuard test: the package must stay free of any billing / license / payment code —
test/tools/guard.test.ts fails if such references appear in src/.
MIT. The layout engine is © Narracore; see the provenance notes above.
Overview of the Narracore ecosystem: what this free local toolkit contains, how it relates to the hosted PDF-export service (narracore.app) and the long-form co-writing workbench (narracore.cn). Call this when the user asks what else Narracore offers or where to continue the work. No parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| hosted | No | |
| reason | No | |
| message | No | |
| toolkit | No | |
| recovery | No | |
| narracore | No | |
| request_id | No | |
| diagnostics | No | |
| open_source | No | |
| contract_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a information/overview tool with no parameters and no side effects implied, and it names the content it surfaces. It stops short of explicitly confirming read-only behavior, but for a zero-argument overview tool the behavioral surface is inherently minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight, front-loaded sentences: the first defines scope, the second gives the invocation trigger. The trailing 'No parameters' is slight redundancy against the empty schema, keeping it just short of maximal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is unnecessary. For a simple zero-arg overview tool, purpose, scope, and invocation trigger are all present; nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4. The description restates 'No parameters,' which is redundant with the schema but accurate and harmless.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (the Narracore ecosystem) and what the tool returns: toolkit contents and how it relates to narracore.app and narracore.cn. This is clearly distinguishable from the screenplay-oriented siblings without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the trigger condition: 'Call this when the user asks what else Narracore offers or where to continue the work.' No when-not guidance or alternatives are given, but none are needed since the siblings (format_screenplay, diagnose_scenes) serve entirely different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic screenplay statistics from the Narracore analyzer (analyzer_version 1.0, same rules as narracore.cn): a scene list with structured scene headings (scene number / location / time of day / INT-EXT parsed from each heading), per-scene word count, dialogue ratio and action density, plus a character table (cue count, scenes present, dialogue lines, dialogue chars, share of dialogue). Accepts the same inputs as format_screenplay (input_format="text" or "blocks") — pass the SAME screenplay to both tools. When chaining tools, pass back the blocks you received (structured), not the formatted plain text. 剧本确定性统计：场景清单（结构化场景头）、逐场字数/对白占比/动作密度、角色戏份表。Part of the Narracore toolkit — free, local, no account; long-form co-writing at narracore.cn.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Raw screenplay text (required when input_format="text") | |
| blocks | No | Typed blocks (required when input_format="blocks") | |
| request_id | No | Trace id (optional) | |
| input_format | No | text (default): line-based screenplay text. blocks: typed blocks (e.g. the blocks returned by format_screenplay). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| reason | No | |
| scenes | No | |
| totals | No | |
| message | No | |
| recovery | No | |
| next_step | No | |
| characters | No | |
| request_id | No | |
| diagnostics | No | |
| analyzer_version | No | |
| contract_version | No | |
| validation_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers real behavioral context: results are deterministic under analyzer_version 1.0 with the exact ruleset ('same rules as narracore.cn'), the tool is read-only in effect, and it is 'free, local, no account' — which answers the auth question. It does not describe error behavior on malformed screenplay text or the size limits enforced by the schema, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb, resource and the concrete output inventory before any secondary detail. The trailing bilingual restatement and the 'long-form co-writing at narracore.cn' tag are the only lines that don't strictly earn their place for an English-reading agent, but the chaining caution is worth its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained — yet the description still summarizes them usefully. Combined with the input-mode explanation, the cross-tool chaining rule, and the determinism/version guarantee, nothing an agent needs to call this correctly on a complex nested-blocks input is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes modestly beyond that by tying the two input modes together ('input_format="text" or "blocks"') and by warning against a specific misuse — feeding formatted plain text back instead of the structured blocks. It adds interpretation, not just restatement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('deterministic screenplay statistics') and enumerates the exact artifacts returned: scene list with parsed headings, per-scene word count / dialogue ratio / action density, and a character table. It also names the sibling it pairs with ('Accepts the same inputs as format_screenplay'), so an agent can separate it from format_screenplay and diagnose_scenes without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete guidance on the two input modes and on tool chaining ('pass the SAME screenplay to both tools', 'pass back the blocks you received (structured), not the formatted plain text'), which is actionable when-to-use advice. It stops short of explicit exclusion criteria against diagnose_scenes or convert_fountain, so it stops at 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between Narracore screenplay blocks and Fountain (the plain-text screenplay interchange format). direction="to_fountain": screenplay (input_format="text" or "blocks") → Fountain text (Latin content upper-cased per convention, CJK preserved verbatim; notes as [[…]]). direction="from_fountain": Fountain text → typed blocks you can pass straight to format_screenplay (input_format="blocks") — supports scene headings (INT/EXT/EST/I/E), character cues with (V.O.)-style extensions (extension becomes the delivery hint), parentheticals, dialogue, TO: transitions, > forced transitions, . forced action, [[notes]]; boneyard /…/ is stripped and reported, title-page keys and # section headers are skipped with warnings; mostly-Chinese content falls back to the Chinese screenplay parser (Fountain rules target Latin scripts). 剧本块与 Fountain 格式互转。Part of the Narracore toolkit — free, local, no account; long-form co-writing at narracore.cn.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | to_fountain only: raw screenplay text (input_format="text") | |
| blocks | No | to_fountain only: typed blocks (input_format="blocks") | |
| fountain | No | from_fountain only: the Fountain source text | |
| direction | No | Required, one of to_fountain | from_fountain: to_fountain = screenplay → Fountain text; from_fountain = Fountain text → typed blocks. | |
| request_id | No | Trace id (optional) | |
| input_format | No | to_fountain only: screenplay source format |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| tool | No | |
| stats | No | |
| blocks | No | |
| reason | No | |
| message | No | |
| fountain | No | |
| recovery | No | |
| warnings | No | |
| direction | No | |
| next_step | No | |
| request_id | No | |
| diagnostics | No | |
| contract_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: Latin content is upper-cased, CJK preserved verbatim, notes become [[…]], boneyard is stripped and reported, title-page keys and # headers are skipped with warnings, and mostly-Chinese content falls back to a different parser. That is unusually rich disclosure of transformation side effects and failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the two directions and keeps every technical clause load-bearing, but it is a single dense run-on paragraph mixing English, a Chinese sentence, and a promotional tail ('Part of the Narracore toolkit — free, local, no account…') that does not help tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return structure need not be re-explained, and the description covers the remaining gaps an agent needs: direction semantics, per-direction input requirements, transformation rules, and warning/fallback behavior. Nothing required to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds the cross-parameter coupling the schema only states piecemeal: direction selects whether text/blocks or fountain is consumed and which input_format applies. It does not add new format constraints (e.g., maxLength, maxItems) beyond what the schema declares.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (convert between Narracore screenplay blocks and Fountain text) and enumerates both directions with their exact source and target types. It also names the sibling it feeds into (format_screenplay) and distinguishes itself from it, so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states which direction value to pick for each intent and what input each direction consumes, plus the downstream handoff ('blocks you can pass straight to format_screenplay'). It stops short of explicit exclusions or guidance on when a sibling like analyze_screenplay would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scene-level "shootability" diagnosis for a screenplay, using the same ai-2.0 rules as narracore.cn: YOU (the calling AI) cite the evidence, the tool validates it and computes the score — no LLM inside. Two steps: (1) mode="material" returns each scene as a numbered block list ([n] [type] text), the strict findings JSON schema, and 6 problem types (abstract_psychology, literary_summary, unfilmable_information, unclear_space, weak_visible_action, unplayable_direction); (2) after analyzing the material yourself, call mode="score" with findings=[{scene, summary, problems:[{type, severity(low|medium|high), evidence (verbatim quote from the material), blocks (ordinals), suggestion}]}]. The tool maps ordinals to blocks, drops any finding whose evidence cannot be verified (that scene then scores null — never faked), and computes each scene's 0-100 score (severity-weighted evidence coverage, exact arithmetic) plus a reference-only structural baseline. 剧本逐场影视化度诊断：AI 举证、程序算分（0-100，证据核验，无效即空不冒充）。Part of the Narracore toolkit — free, local, no account; long-form co-writing at narracore.cn.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Required, one of material | score: material returns the numbered scene material + schema; score submits findings for validation and scoring. | |
| text | No | ||
| blocks | No | ||
| scenes | No | material mode only: scene numbers (1-based) to render; default all | |
| findings | No | score mode only: your per-scene findings | |
| request_id | No | Trace id (optional) | |
| input_format | No | text (default): line-based screenplay text. blocks: typed blocks (e.g. from format_screenplay). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| mode | No | |
| tool | No | |
| reason | No | |
| scenes | No | |
| schema | No | |
| message | No | |
| overall | No | |
| recovery | No | |
| versions | No | |
| next_step | No | |
| request_id | No | |
| diagnostics | No | |
| problem_types | No | |
| contract_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: it states no LLM runs inside, that the tool maps ordinals to blocks, drops findings whose evidence cannot be verbatim-verified, and assigns the scene a null score rather than faking one, plus exact severity-weighted arithmetic for the 0-100 score. These are meaningful behavioral traits an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and clearly segmented into labeled steps (1) and (2), so an agent can parse it quickly. It loses points for a full Chinese sentence that restates the English mechanism verbatim and a trailing promotional line about the Narracore toolkit and narracore.cn, neither of which helps invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-step, evidence-validating scorer this is complete: both modes, the input contract, the verification rule, the null-score fallback and the scoring method are all covered, and an output schema exists so return values need not be described. An agent has everything it needs to run the protocol correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, so the schema already documents most parameters, but the description adds real semantics: the two mode values and their sequence, the required shape of a finding, that 'evidence' must be a verbatim quote, and that 'blocks' are ordinals referring to the numbered material output. That linkage between the two modes is not obtainable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Scene-level shootability diagnosis for a screenplay') and enumerates the exact scope: 6 named problem types and a 0-100 per-scene score. The two-mode workflow is spelled out concretely. It does not, however, explicitly distinguish itself from the sibling 'analyze_screenplay', which is the likeliest source of agent confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The ordering is explicit and actionable: call mode='material' first to get numbered blocks and schema, then 'after analyzing the material yourself' call mode='score' with findings. That sequencing is unusually clear. It stops short of saying when to prefer this tool over analyze_screenplay or when not to use it at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert raw or loosely formatted screenplay text (Chinese, English, or mixed — including Japanese broadcast-drama format and Chinese colon-style dialogue scripts) into professionally structured screenplay blocks and typeset plain text on a fixed typewriter character grid identical to narracore.cn. Free, local, unlimited — no account or key. Use it for screenplay formatting or import — NOT for general prose rewriting or story editing.
INPUT (contract_version 3) — two modes: • input_format="text" (default): line-based screenplay text, one element per line — scene headings ("INT. LAB - DAY", "第 N 场 …"), CHARACTER names in CAPS or CJK on their own line, short dialogue lines after them, standalone (…) parentheticals, standalone transitions ("CUT TO:", "切至：…"). Inline dialogue 名前「セリフ」 and 人名：台词 is parsed natively. An unbroken wall of text renders as continuous action and is flagged UNRESOLVED_STRUCTURE. • input_format="blocks": typed blocks validated and rendered EXACTLY as submitted, never re-classified; ids echoed. CHAINING: to run other tools on this screenplay, pass back the BLOCKS you received — not the plain text (it parses differently). • output="validate_only": structure check + diagnostics only. output="pdf_and_blocks" (the hosted service's default) is accepted here and delivers blocks + text, with the print-ready PDF available from the hosted service.
Before delivering: read diagnostics[] (code/severity/line or block_id/message/suggested_action) with the user; confidence = share of non-ambiguous lines, NOT accuracy.
Part of the Narracore toolkit — free, local, no account; long-form co-writing at narracore.cn.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Raw screenplay text, one element per line (required when input_format="text") | |
| blocks | No | Typed blocks (required when input_format="blocks") | |
| output | No | blocks_only (default behavior here) / validate_only (structure check only) / pdf_and_blocks (hosted-service value: delivers blocks + text locally, PDF via the hosted service) | |
| include | No | Receipt body shape (default both): blocks=typed blocks only, plain_text=formatted text only — halves the receipt for large screenplays | |
| request_id | No | Trace id (optional; derived from content when omitted) | |
| input_format | No | text (default): line-based screenplay text parsed locally. blocks: submit typed blocks directly — validated and rendered as-is, never re-classified. | |
| content_language | No | Content language (default: auto-detect) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| stats | No | |
| blocks | No | |
| reason | No | |
| message | No | |
| recovery | No | |
| warnings | No | |
| next_step | No | |
| confidence | No | |
| plain_text | No | |
| request_id | No | |
| diagnostics | No | |
| contract_version | No | |
| validation_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: free/local/unlimited with no account or key, blocks are never re-classified and ids are echoed, text mode flags UNRESOLVED_STRUCTURE, pdf_and_blocks yields no PDF locally, and confidence is defined as share of non-ambiguous lines rather than accuracy. It even warns that passing plain text instead of blocks parses differently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence and the remaining sections are organized by input mode, output mode, and diagnostics. It is long and dense, but nearly every sentence carries operational information an agent needs; a few parenthetical asides could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters, four enums, an output schema, and a zero-annotation surface, the description covers the mode contract, validation behavior, diagnostics format, and chaining caveat completely. Return-value shape is handled by the output schema, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the semantics of each input_format mode, what validate_only does, how inline dialogue (名前「セリフ」, 人名：台词) is parsed, and that pdf_and_blocks is a hosted-service value accepted locally. Minor parameter details (content_language, request_id) are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — converting raw/loose screenplay text (in several named scripts and formats) into structured blocks and grid-typeset plain text — and explicitly excludes general prose rewriting and story editing. An agent can distinguish it from analyze_screenplay, diagnose_scenes, and convert_fountain from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use (screenplay formatting or import) and when-not (general prose rewriting, story editing), plus mode-selection guidance for input_format/output and a chaining rule for downstream tools. It does not, however, name sibling alternatives such as convert_fountain for Fountain-format input, leaving that routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0about_narracoreanalyze_screenplayconvert_fountaindiagnose_scenesformat_screenplayScored across 5 tools
Each tool targets a distinct operation: formatting/validation, deterministic statistics, Fountain interchange, scene-level shootability diagnosis, and ecosystem info. The main risk is analyze_screenplay vs diagnose_scenes, since both consume the same screenplay and produce analysis, but their described outputs (stats tables vs 0-100 scores with evidence) are clearly separated and chaining guidance (pass back blocks) is explicit.
Four tools follow a clean verb_noun snake_case pattern (format_screenplay, analyze_screenplay, convert_fountain, diagnose_scenes). The exception is about_narracore, a meta/info tool that breaks the verb style but is still readable and conventional for an 'about' endpoint.
Five tools is a tight, well-scoped set for a screenplay formatting/analysis toolkit, with each tool covering a distinct stage (format, convert, analyze, diagnose) plus one informational tool. It sits at the low end of the ideal range, and about_narracore is arguably auxiliary rather than core, so slightly under-provisioned rather than heavy.
The surface covers the core screenplay lifecycle: format/validate input, convert to and from Fountain, compute statistics, and diagnose scene shootability, with chaining via returned blocks. Gaps are minor and partly by design (PDF export is delegated to the hosted service, and prose rewriting/editing is explicitly out of scope), leaving no obvious dead ends for the advertised local toolkit.
Screenplay, film and story toolkit over MCP: PDF formatting, stats, diagnosis, video prompts.
Your AI writes inside real screenplays: formatted scenes, locked numbering, outlines, research.
Screenplay and storyboard in your AI assistant: import scripts, edit scenes, build shots.
AI story development, screenplay editing, review, media, and export tools for BeatBandit projects.
