Cyan Eclipse Cadence MCP

Official

Overview Schema Source Related Servers Discussions Admin

Verify the Cadence facade receipt chain

cadence_receipts_verify

Recompute hash-chained call receipts to verify chain integrity and report the first diverging sequence, checked receipt count, and chain head for auditing recorded facade calls.

Instructions

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.

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

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`ok`	Yes
`head`	Yes
`count`	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.
`diverging_seq`	Yes

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?

Explains the non-obvious mismatch with annotations: readOnlyHint=false is accounted for by 'verification changes no record other than that normal receipt append.' It also discloses ordering semantics ('the verdict describes the chain before this call's own successful-call receipt is appended') and states there is no network, authentication, or credential surface — details the 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?

Three dense sentences, front-loaded with the purpose, then routing, then behavior. Every sentence carries information, though the return-field enumeration is somewhat redundant given an output schema exists and makes the middle sentence heavy.

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 audit tool with an output schema, the description covers the remaining unknowns an agent needs: side effects, ordering of the verdict relative to the receipt append, absence of auth/network, and the divergence reporting semantics. Nothing material is missing.

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 the baseline is 4; there is no parameter semantics to add. The description does not waste effort on inputs and instead spends its words on behavior, which is the right trade-off.

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 ('Recompute this MCP facade's hash-chained call receipts') plus exactly what is reported: verification verdict, first diverging sequence, receipt count, chain head. It also explicitly distinguishes itself from the sibling cadence_renders_read by naming the different target (facade receipt chain vs stored render record).

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 both sides of the routing decision: 'Use to audit whether recorded facade calls remain internally consistent' and 'use cadence_renders_read when the target is a stored render record rather than the facade receipt chain.' The alternative and the condition selecting it are named outright, so no inference is required.

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

Deploy Server