Cyan Eclipse Cadence MCP

Official

Overview Schema Source Related Servers Discussions Admin

List the stored Cadence voice catalogue

cadence_voices_list

Lists the stored Cadence voice catalogue with voice_id, engine, adapter, and timeout details so you can identify a voice before reading scripts or proposing a render.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cadence_voices_list"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`voices`	Yes
`receipt_id`	Yes	Identifier of the content-minimal receipt appended for this successful call.
`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.4/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false, which is surprising for a list tool, and the description earns credit by explaining it: a successful call appends a content-minimal hash receipt and returns receipt_id and receipt_head. It also discloses the local-stdio-only, no-network, no-auth execution profile, which annotations cannot convey. However, it says nothing about whether the catalogue can be empty, how large it is, or whether the receipt write can fail, and the deliberate choice to omit all of that is a real gap against a 0-param call so cheap to describe fully.

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-loaded with what the tool returns, then when to use it, then what it cannot do, then behavior — a sensible order with no filler sentences. The middle sentence is clause-stacked and would read better split, and listing the return fields is somewhat redundant 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?

For a zero-parameter local read tool, the description covers purpose, selection guidance, negative scope, execution environment, and the receipt side effect, and an output schema already carries the return shape. An agent has everything needed to call this correctly on the first attempt.

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?

There are no input parameters, which is the baseline-4 case for this dimension. The description's enumeration of returned fields (voice_id, engine, adapter, timeout_secs, note) is output detail rather than parameter meaning, so it neither adds nor subtracts here.

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?

Uses a specific verb (list) plus resource (voice catalogue) and pins the scope precisely: the entries come from this checkout's synthesis-adapter constants, not a live service. It also names what the tool is not (no add/select/change/certify, no synthesis), so an agent can distinguish it from cadence_renders_list and cadence_render_propose without opening a schema.

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?

Gives explicit positive guidance ('use to identify the stored voice before reading scripts or proposing a render') and routes to the sibling that answers a nearby question (cadence_renders_list for which voice a render record used). It also states exclusions outright, which is the when-not half most descriptions omit.

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

Deploy Server