Skip to main content
Glama
Cyan Eclipse Cadence MCP

Cyan Eclipse Cadence MCP

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CADENCE_MCP_HOMENoOptional path to another Cadence checkout for the server to inspect instead of its own checkout.
CADENCE_MCP_STATE_DIRNoRecommended path to a writable directory where successful calls append content-minimal hash receipts and proposals are written as JSON files.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
cadence_scripts_listA

List the performance scripts stored in this Cadence checkout, with each script's identifier, repository-relative path, SHA-256 of its file bytes, and segment count. Use this first to discover a valid script_id for cadence_scripts_read or cadence_render_propose. This tool does not compile a score or start a render; use cadence_scripts_read when persona, segment text, and compiled-score evidence are needed. Behaviour: local stdio only, with no network, authentication, credentials, or external service; a successful call appends a content-minimal hash receipt (argument and result hashes only) to the facade receipt chain. Returns an object with scripts, receipt_id, and receipt_head.

cadence_scripts_readA

Read one stored performance script and compile its performance score with Cadence's own compiler, returning the script identifier, path, file SHA-256, persona when present, segment texts, segment count, rule set, compiled span count, and canonical score SHA-256. Use when the actual script and compiler evidence are needed; use cadence_scripts_list for discovery only and cadence_render_propose only to record a non-executing render proposal. An unknown identifier returns an error and creates no proposal. Behaviour: local and deterministic for unchanged files; no synthesis, network, authentication, or credential use; a successful call appends a content-minimal hash receipt. Returns the script object plus receipt_id and receipt_head.

cadence_voices_listA

List the voice catalogue exactly as stored in this Cadence checkout's synthesis-adapter constants, returning voice_id, engine, adapter, timeout_secs, and an explanatory note for each entry. Use to identify the stored voice before reading scripts or proposing a render; use cadence_renders_list to find which voice a stored render record used. This tool cannot add, select, change, or certify a voice and it does not synthesize audio. Behaviour: local stdio only, with no network, authentication, credentials, or external service; a successful call appends a content-minimal hash receipt. Returns an object with voices, receipt_id, and receipt_head.

cadence_renders_listA

List Cadence's stored render and acceptance records with record_id, episode, take, voice, duration_s, state, and in_band_pct. Use this first to discover a valid record_id for cadence_renders_read. These are historical stored records, not live render status; this tool cannot start, retry, or inspect an in-progress synthesis. Behaviour: local file reads only, with no network, authentication, credentials, or audio playback; a successful call appends a content-minimal hash receipt. Returns an object with renders, receipt_id, and receipt_head, with null fields where a record does not carry a value.

cadence_renders_readA

Read one stored render or acceptance record in full by exact record_id, returning its episode, take, audio reference, voice, duration, basis, gate counts and percentage, state, source file, and stored receipt hash when the record is a sealed receipt. Use after cadence_renders_list when full evidence is needed; use cadence_receipts_verify for the facade's own call-receipt chain rather than a render record's stored receipt. An unknown record_id returns an error. Behaviour: local file read only; no synthesis, network, authentication, credentials, or external service; a successful call appends a content-minimal hash receipt. Returns the record plus receipt_id and receipt_head.

cadence_receipts_verifyA

Recompute this MCP facade's hash-chained call receipts and report whether the chain verifies, the first diverging sequence when it does not, the receipt count checked, and the chain head. Use to audit whether recorded facade calls remain internally consistent; use cadence_renders_read when the target is a stored render record rather than the facade receipt chain. Behaviour: the verdict describes the chain before this call's own successful-call receipt is appended; the server has no network, authentication, or credential surface, and verification changes no record other than that normal receipt append. Returns an object with ok, diverging_seq, count, head, receipt_id, and receipt_head.

cadence_render_proposeA

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.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a distinct resource+action pair (scripts list/read, renders list/read, voices list, receipts verify, render propose), and the descriptions explicitly cross-reference sibling tools to steer selection (e.g. renders_read vs receipts_verify, scripts_list vs scripts_read). No two tools can be plausibly confused for one another.

Naming Consistency4/5

All names follow a predictable cadence_<resource>_<verb> pattern with snake_case throughout. The only blemish is singular/plural drift on the same resource: cadence_render_propose versus cadence_renders_list and cadence_renders_read.

Tool Count5/5

Seven tools is well within the ideal 3-15 band and each one maps to a concrete operation on a small local domain. Nothing feels padded or redundant for a read-only audit/proposal facade.

Completeness3/5

Scripts and renders both have list+read pairs and receipts have verification, but proposals only have a create path — there is no way to list or re-read a proposal after creation, and no receipt listing. The absence of synthesis/start/apply tools is explicitly declared as out of scope, so the gap is moderate rather than severe.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues