Cyan Eclipse Cadence MCP

Official

Overview Schema Source Related Servers Discussions Admin

List Cadence performance scripts

cadence_scripts_list

Lists performance scripts in a Cadence checkout with identifiers, paths, SHA-256 hashes, and segment counts so you can find a valid script_id for reading or render proposals.

Instructions

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.

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_scripts_list"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`scripts`	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.6/5.0

Behavior4/5

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

The annotations (readOnlyHint=false, idempotentHint=false) would otherwise look odd for a list operation; the description resolves this by disclosing that a successful call appends a content-minimal hash receipt to the facade receipt chain, and that execution is local stdio with no network, auth, or credentials. It stops short of describing failure modes (e.g. no checkout present, receipt-chain errors), which keeps it from a 5.

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 purpose, then usage routing, then behavior, then returns — a sensible order with no filler sentences. The final sentence enumerating the returned object ("scripts, receipt_id, and receipt_head") duplicates the output schema and is the one mildly redundant element.

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, selection guidance, execution environment, side effects, and return shape for a zero-parameter read/list tool, which is everything an agent needs to call it correctly. An output schema exists, so the return-value sentence is a bonus rather than a required burden.

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?

The tool takes zero parameters, so there is no parameter meaning to add and the baseline of 4 applies. The description correctly avoids inventing inputs and instead spends its space on return fields and side effects.

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 ("List the performance scripts stored in this Cadence checkout") and enumerates the returned fields (identifier, repository-relative path, SHA-256 of file bytes, segment count). It is clearly distinguishable from cadence_scripts_read and cadence_render_propose, which are named directly.

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 an explicit entry-point instruction ("Use this first to discover a valid script_id") plus a negative boundary ("does not compile a score or start a render") and routes to the correct alternative when persona/segment/compiled-score evidence is needed. When-to-use, when-not, and the alternative are all present.

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

Deploy Server