Cyan Eclipse Cadence MCP

Official

Overview Schema Source Related Servers Discussions Admin

Record a non-executing Cadence render proposal

cadence_render_propose

Create a local render proposal for a stored script so it can be reviewed later by a human or production pipeline; this records intent only and does not generate audio.

Instructions

Create a local render proposal for one stored script, returning proposal_id, script_id, the stored voice, the optional note, applied: false, started: false, state: proposed, and the disposition text. Use when a render should be recorded for later human or production-pipeline review; do not use it to produce audio, because no render-start or render-apply tool exists on this server. An unknown script_id returns an error. Behaviour: each successful call writes one new proposal JSON file in the facade state area and appends a content-minimal hash receipt; it makes no network call, uses no credentials, invokes no synthesis engine, and is not idempotent because repeated calls create separate proposals. Returns the proposal plus receipt_id and receipt_head.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "script_id": "<script_id>"
    },
    "name": "cadence_render_propose"
  }
}

Input Schema

Name	Required	Description	Default
`note`	No	Optional free-text note stored verbatim in the proposal record. It has no execution effect and does not select a voice, change a script, or start a render.
`script_id`	Yes	Exact stored script identifier without the .md extension, for example ep18-script. Obtain valid identifiers from cadence_scripts_list.

Output Schema

Name	Required	Description
`kind`	Yes
`note`	Yes
`state`	Yes
`voice`	Yes
`applied`	Yes
`started`	Yes
`script_id`	Yes
`receipt_id`	Yes	Identifier of the content-minimal receipt appended for this successful call.
`disposition`	Yes
`proposal_id`	Yes
`receipt_head`	Yes	Hash head of the facade receipt chain after this call's receipt was appended.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that each call writes a proposal JSON file, appends a content-minimal hash receipt, makes no network call, uses no credentials, invokes no synthesis engine, and is not idempotent. It also states the error behavior for unknown script_id, which annotations cannot convey.

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?

Front-loads the action and return fields, then usage, then behavior. Dense but every sentence carries information; the enumerated return list is slightly verbose given an output schema exists.

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?

Covers purpose, usage, side effects, idempotency, error cases, and return shape for a two-parameter tool. Nothing an agent needs to invoke it correctly is missing, even though an output schema is also present.

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 value by clarifying the note is stored verbatim with no execution effect and that an unknown script_id errors. The script_id format guidance largely duplicates the schema, keeping this just below a 5.

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 ('Create a local render proposal for one stored script') and immediately distinguishes it from audio production by noting no render-start or render-apply tool exists. An agent can tell exactly what this does and does not do.

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?

Explicitly says when to use it ('when a render should be recorded for later human or production-pipeline review') and when not to ('do not use it to produce audio'), with the reason supplied. This is a complete routing instruction.

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

Deploy Server