Cyan Eclipse Cadence MCP

Official

Overview Schema Source Related Servers Discussions Admin

Read and compile one Cadence script

cadence_scripts_read

Reads a stored performance script and compiles its performance score with Cadence's compiler, returning script details, segment data, rule set, and hash receipts for verification.

Instructions

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.

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

Input Schema

Name	Required	Description	Default
`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
`path`	Yes
`sha256`	Yes
`persona`	Yes
`rule_set`	Yes
`segments`	Yes
`script_id`	Yes
`receipt_id`	Yes	Identifier of the content-minimal receipt appended for this successful call.
`span_count`	Yes
`receipt_head`	Yes	Hash head of the facade receipt chain after this call's receipt was appended.
`score_sha256`	Yes
`segment_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Explains the non-obvious side effect that justifies readOnlyHint=false: a successful call appends a content-minimal hash receipt and returns receipt_id/receipt_head, which also accounts for why the call is not idempotent (each call writes a new receipt). It further declares no network, authentication, or credential use and determinism for unchanged files, so the agent knows the safety profile beyond the annotations.

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 the verb and resource, then usage routing, then behavior. The long enumeration of return fields (path, SHA-256s, persona, segments, rule set, span count) consumes real space that the existing output schema already covers, which is the main redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-plus-compile tool with an output schema, annotations, and full parameter coverage, the description supplies the behavioral facts that matter: local/deterministic execution, no credentials, error on unknown id, and the receipt write. Only minor gap is that the return-field list duplicates the output schema rather than describing anything extra.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single script_id parameter is already documented in the schema, including the '.md extension' convention and where to obtain valid identifiers. The description adds no further syntax or format detail beyond that, so the baseline 3 applies.

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 (read one stored script and compile its performance score) plus the concrete outputs it produces. It distinguishes itself from cadence_scripts_list (discovery) and cadence_render_propose (non-executing proposal), so an agent can separate the three without opening schemas.

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 selection rule: use this when the actual script and compiler evidence are needed, use list for discovery only, use render_propose only to record a proposal. It also states the failure case (unknown identifier returns an error and creates no proposal), which is a when-not condition.

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

Deploy Server