Narracore Screenplay Formatter

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

No annotations are provided, so the description carries the full disclosure burden. It reveals non-obvious traits: the call is free ("Costs nothing"), it returns recent usage and a purchase link, and it supports a preferred bearer-token authentication pattern. It does not explicitly state side-effect status, but "check" strongly implies a read operation.

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?

The description is compact and front-loaded: purpose, then value (cost/returns), then auth guidance. The Chinese sentence duplicates the English purpose but is short and may serve bilingual users; it is minor redundancy rather than significant waste.

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 tool with zero required parameters, no output schema, and one unrelated sibling, the description is complete. An agent knows what the tool returns, that it is free, how to supply the key, and the preferred auth path. No critical information needed 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 100% and the license_key parameter already has a regex pattern and description. The tool description adds value by explaining that the key is optional if already configured in the client auth header, which is essential for deciding whether to pass it. This goes beyond 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 uses a specific verb and resource: "Check the remaining formatting credits for a Narracore license key." It clearly distinguishes from the only sibling, format_screenplay, by focusing on account/credit status rather than formatting operations. It also mentions the return contents (recent usage, purchase link), making the tool's purpose unmistakable.

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 description gives concrete operational guidance: the tool is for checking credits and usage, costs nothing, and the preferred auth method is setting the key in the MCP client header rather than passing it in chat. It does not explicitly discuss when-not-to-use or alternatives, but there is no meaningful competing sibling for this purpose, so the context is clear enough.

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

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.

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.

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.

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.

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.

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.