cedulon

cedulon_audit

Read-only

Reconcile payment receipts against a rail extract or internal ledger to confirm every settlement has a matching receipt. Returns balanced audit or findings naming the account, rail, and window.

Instructions

Reconcile the in-process receipt chain and checkpoint against the rail extract: this server's own ledger, or a signed extract you present. Returns audit: balanced or findings, names the account, rail and window it was computed over (scope) when an extract declared one, and counts the class every receipt and row landed in (counts).

Input Schema

TableJSON Schema

Name	Required	Description
`trust`	No	Rail key you hold out of band: { publicKeyPem, accountId?, railId?, windowStartMs?, windowEndMs? }
`extract`	No	A signed rail extract you were presented with: { body: { accountId, railId, windowStartMs, windowEndMs, settlements: [{ ref, amount, currency, timestampMs }], clockSkewMs? }, signature, publicKeyPem }. Present, it is the settlement side of the audit: this server's in-process settlement rows are not consulted, rows added through extraSettlements are refused beside it (an empty list adds nothing and is accepted), and the result carries scope. The receipt side is still this server's own receipt chain and checkpoints, so an extract for an account or rail this server did not settle on reports this server's receipts as unmatched; that is the correct reading of that pairing, not a defect. A body the library would refuse to sign (malformed window, amount outside the grammar, negative clock skew), an empty account, rail or signature, or a key that is not a PEM is refused as extract: ... before anything is reconciled. Absent, the audit runs over this server's own ledger and declares no scope.
`manifest`	No	A Trade Manifest you were presented with. Omit for a no-manifest deployment. Present without manifestTrust is unauthenticated-manifest.
`payeeTrust`	No	Payee keys you hold out of band, keyed by payee: { "payee-1": publicKeyPem }
`issuerTrust`	No	Issuer key(s) you hold out of band: { publicKeyPem: string \| string[] }. Without it the audit checks this server's records against this server's own key.
`witnessTrust`	No	Transparency log key you hold out of band: { publicKeyPem: string \| string[] }
`manifestTrust`	No	Manifest publisher key(s) you hold out of band: { publicKeyPem: string \| string[] }
`extraSettlements`	No	Optional extra extract rows, used to inject a bypass settlement in tests

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.12.0Sep 3, 2026

addedInput schema / properties / extract

Added value: +{
+  "description": "A signed rail extract you were presented with: { body: { accountId, railId, windowStartMs, windowEndMs, settlements: [{ ref, amount, currency, timestampMs }], clockSkewMs? }, signature, publicKeyPem }. Present, it is the settlement side of the audit: this server's in-process settlement rows are not consulted, rows added through extraSettlements are refused beside it (an empty list adds nothing and is accepted), and the result carries scope. The receipt side is still this server's own receipt chain and checkpoints, so an extract for an account or rail this server did not settle on reports this server's receipts as unmatched; that is the correct reading of that pairing, not a defect. A body the library would refuse to sign (malformed window, amount outside the grammar, negative clock skew), an empty account, rail or signature, or a key that is not a PEM is refused as extract: ... before anything is reconciled. Absent, the audit runs over this server's own ledger and declares no scope.",
+  "type": "object"
+}

Changed6 schema fields changedv0.5.1Aug 30, 2026

addedInput schema / properties / issuerTrust

Added value: +{
+  "description": "Issuer key(s) you hold out of band: { publicKeyPem: string | string[] }. Without it the audit checks this server's records against this server's own key.",
+  "type": "object"
+}

addedInput schema / properties / manifest

Added value: +{
+  "description": "A Trade Manifest you were presented with. Omit for a no-manifest deployment. Present without manifestTrust is unauthenticated-manifest.",
+  "type": "object"
+}

addedInput schema / properties / manifestTrust

Added value: +{
+  "description": "Manifest publisher key(s) you hold out of band: { publicKeyPem: string | string[] }",
+  "type": "object"
+}

addedInput schema / properties / payeeTrust

Added value: +{
+  "description": "Payee keys you hold out of band, keyed by payee: { \"payee-1\": publicKeyPem }",
+  "type": "object"
+}

addedInput schema / properties / trust

Added value: +{
+  "description": "Rail key you hold out of band: { publicKeyPem, accountId?, railId?, windowStartMs?, windowEndMs? }",
+  "type": "object"
+}

addedInput schema / properties / witnessTrust

Added value: +{
+  "description": "Transparency log key you hold out of band: { publicKeyPem: string | string[] }",
+  "type": "object"
+}

First observedv0.2.3Aug 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Even with readOnlyHint=true, the description discloses a great deal beyond the annotation: it states what is compared, what result is returned, that in-process settlement rows are not consulted when an extract is present, that malformed/empty inputs are refused, and that mismatched extracts still produce a defined outcome. This is exactly the behavioral context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and output, and the two sentences are dense with no filler. The use of semicolons packs a lot, but every clause earns its place given the tool's complexity.

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 tool with eight parameters and no output schema, the description states purpose, mode selection, and return contract (balanced/findings, scope, counts) well. It does not enumerate the trust/manifest parameters, but the 100%-covered input schema compensates, so nothing critical is left to guesswork for invocation.

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 description coverage is 100%, so the baseline applies and the parameter descriptions already carry rich semantics. The tool-level description contributes conceptual framing (own ledger vs extract, output counts) but adds no new parameter-level syntax or format beyond the schema.

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?

The description opens with a specific verb and resource: 'Reconcile the in-process receipt chain and checkpoint against the rail extract' and immediately distinguishes the two modes (own ledger vs signed extract). It also names the result shape ('balanced or findings', scope, counts), so an agent can tell this audit tool apart from sibling operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when to run against the server's own ledger versus a signed extract and what happens when the extract's account/rail doesn't match server activity. It does not explicitly name sibling tools or state 'don't use this when X', but the extract/absent distinction provides actionable routing.

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

Deploy Server

cedulon_audit

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools