Narracore Format

format_screenplay

Convert raw or loosely formatted screenplay text into structured screenplay blocks and typeset plain text for import or formatting; not for prose rewriting.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server