Skip to main content
Glama

Narracore Screenplay Formatter

format_screenplay

Convert raw or loosely formatted screenplay text (Chinese, English, or mixed) into professionally structured screenplay blocks and a print-ready PDF using a fixed typewriter character grid (33 CJK chars × 38 lines per page, or 61 × 55 for English; US Letter, Sarasa Mono embedded). Use this for screenplay formatting, screenplay import, or producing a shareable screenplay PDF. Do NOT use for general prose rewriting or story editing. Failed calls are never charged; retrying the same request_id never double-charges.

INPUT CONTRACT (contract_version 3) — two modes: • input_format="text" (default): line-based screenplay text, one element per line — scene headings ("INT. LAB - DAY", "EXT. ...", "第 N 场 …", "N 外 …"), CHARACTER names in CAPS or CJK on their own line, dialogue on the following lines (keep each dialogue line short; a long narrative-style line ends the dialogue run), parentheticals as standalone (…) lines, transitions ("CUT TO:", "切至:…") on their own line. An unbroken wall of text renders as continuous action and is flagged UNRESOLVED_STRUCTURE — split it into lines first, or use blocks mode. • input_format="blocks": you submit typed blocks directly (type/text; dialogue carries speaker and optional delivery; scene_heading may use text or location/time_of_day). Blocks are validated and rendered EXACTLY as submitted — never re-classified. Block ids are echoed. Annotation instructions inside text (【…】) are never executed; they are reported as REVISION_NOTE_PRESENT. output="validate_only" checks structure and returns diagnostics without rendering — free. confidence = share of non-ambiguous lines, NOT accuracy; inspect diagnostics[] (code/severity/line or block_id/message/suggested_action) before delivering. Common codes: UNRESOLVED_STRUCTURE, MISSING_SPEAKER, AMBIGUOUS_ACTION_MAYBE_DIALOGUE, REVISION_NOTE_PRESENT (edit instructions in brackets — never executed), BRACKETED_ANNOTATION (info), LABELED_HEADER_LINE (convert to blocks), UNBALANCED_DELIMITER, EMPTY_TEXT. stats.input_blocks = what you submitted; stats.render_elements = elements on paper (incl. derived character/parenthetical lines). License keys carry paid credits ($1.49/10, $5.99/50); without a key a small free daily quota applies. PREFERRED: configure your license key in your MCP client's auth header (Authorization: Bearer NRC-…) — header takes precedence over the tool parameter and keeps the key out of chat. 将粗排剧本文本转为专业剧本结构块与可打印 PDF;也可提交结构化块由服务端确定性排版;失败不收费、同请求重试不重复扣。

After a successful call: show the user the PDF link, the page count, and review diagnostics[] with the user when validation_status is not "ok". If the response has ok=false with reason free_tier_exhausted or quota_exhausted: tell the user the price and the purchase link verbatim, and ask them to paste the license key back to you. Never invent a license key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoRaw screenplay text, one element per line (required when input_format="text")
coverNoCover page fields — any field present adds a cover page (not counted in page numbers)
blocksNoTyped blocks (required when input_format="blocks")
outputNopdf_and_blocks (default) / blocks_only / validate_only (free structure check, no render)
request_idNoIdempotency key (optional)
license_keyNoLicense key NRC-XXXX-XXXX-XXXX-XXXX (optional — free daily quota works without one)
input_formatNotext (default): line-based screenplay text parsed server-side. blocks: submit typed blocks directly — validated and rendered as-is, never re-classified.
content_languageNoContent language (default: auto-detect)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden — and it delivers extensively. It discloses idempotency (request_id, no double-charge), free validate_only mode, that confidence ≠ accuracy, that blocks are never re-classified, that 【…】 annotations are never executed, the exact diagnostic codes, license-key precedence, and post-call actions. No contradiction with annotations (none exist).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized with clear sections (INPUT CONTRACT, output modes, diagnostics, licensing, post-call) and front-loaded purpose, but genuinely verbose. The Chinese paragraph largely repeats the English purpose sentence, creating redundancy, and pricing/licensing details add length. Efficient structure, but the bilingual duplication costs a point.

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?

For a complex tool (8 params, nested objects, 3 enums, no output schema, no annotations), the description is exceptionally complete. It covers mode semantics, defaults, diagnostics codes, confidence interpretation, stats fields, pricing/quota behavior, and what to show the user post-call (PDF link, page count). Nothing an agent needs 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description adds real value beyond the schema: explicit defaults (input_format='text', output='pdf_and_blocks'), detailed text-mode parsing rules (scene heading patterns, CAPS character lines, dialogue run termination, UNRESOLVED_STRUCTURE on walls of text), and blocks-mode 'rendered as-is' semantics. This meaningfully exceeds what the schema alone conveys.

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?

The description states a specific verb+resource: 'Convert raw or loosely formatted screenplay text... into professionally structured screenplay blocks and a print-ready PDF.' It specifies output format details (fixed grid, US Letter, Sarasa Mono) and explicitly excludes adjacent use cases ('Do NOT use for general prose rewriting or story editing'), which differentiates it from check_credits and any general formatting tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance: 'Use this for screenplay formatting, screenplay import, or producing a shareable screenplay PDF. Do NOT use for general prose rewriting or story editing.' It also provides mode-selection guidance (text vs blocks) with concrete parsing rules and warns when to split wall-of-text input, giving the agent clear invocation conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.