Candor Finance

Preview Candor changes

candor_preview

Preview a POST operation through the Candor API without applying the proposed changes. candor_schema describes the preview operation and its arguments or input schema. Previews record private action history and audit events.

Input Schema

TableJSON Schema

Name	Required	Description
`args`	No	Arguments listed in accepted_args by candor_schema for the selected operation, including declared shorthand such as open.acknowledge checkpoint. Put action context such as parent_action at the top level, including when it comes from a returned next action. Request-body fields belong in input unless the operation explicitly accepts them as shorthand args.
`input`	No	Inline request body matching the operation input schema returned by candor_schema. Put fields such as a note's about link inside this object.
`reason`	No	Concise user-visible purpose recorded in immutable action history, including for financial reads. A reason is not approval. Root operations require it except fixed-reason orientation operations; continuations inherit the parent reason only when no reason is supplied. Fixed-reason orientation operations always use their system reason.
`task_key`	No	Optional stable label grouping operations for the same user task. Omit to inherit the parent task key, if any. It does not schedule work or provide idempotency.
`operation`	Yes	Exact operation id from candor_schema, such as notes.create. Use the tool indicated by its calls.mcp or next_call.
`parent_action`	No	Existing action id in this workspace, typically returned in next_actions, whose root identity this continuation inherits. An omitted reason inherits the parent reason; an explicit reason is preserved, except for fixed-reason orientation operations. Omit for a new root action.
`idempotency_key`	No	Stable opaque identity for one logical POST. Reuse only with the same method, path, actor, and body for transport retries. A completed receipt replays its original result, including a refusal; changed input with the same key is rejected. After a refused action and access recovery, use a new key for the new attempt. Follow retryable and recovery guidance if the operation is still running or its outcome is unknown. If omitted, MCP derives a key from this request identity; use an explicit key to deduplicate separate tool invocations.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`action`	No
`errors`	Yes
`status`	Yes
`metadata`	No
`warnings`	Yes
`request_id`	Yes
`generated_at`	Yes
`next_actions`	Yes
`user_message`	No
`data_freshness`	No
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 14, 2026

addedInput schema / properties / idempotency_key / description

Added value: +"Stable opaque identity for one logical POST. Reuse only with the same method, path, actor, and body for transport retries. A completed receipt replays its original result, including a refusal; changed input with the same key is rejected. After a refused action and access recovery, use a new key for the new attempt. Follow retryable and recovery guidance if the operation is still running or its outcome is unknown. If omitted, MCP derives a key from this request identity; use an explicit key to deduplicate separate tool invocations."

removedInput schema / properties / inline_response

Removed value: -{
-  "description": "Return the full response payload in this MCP tool result instead of a resource link. Use only when the client can materialize large tool results into a code sandbox; the response may be very large.",
-  "type": "boolean"
-}

addedInput schema / properties / operation / description

Added value: +"Exact operation id from candor_schema, such as notes.create. Use the tool indicated by its calls.mcp or next_call."

addedInput schema / properties / parent_action / description

Added value: +"Existing action id in this workspace, typically returned in next_actions, whose root identity this continuation inherits. An omitted reason inherits the parent reason; an explicit reason is preserved, except for fixed-reason orientation operations. Omit for a new root action."

changedInput schema / properties / reason / description

Previous value: -"Concise user-visible reason recorded in action history."New value: +"Concise user-visible purpose recorded in immutable action history, including for financial reads. A reason is not approval. Root operations require it except fixed-reason orientation operations; continuations inherit the parent reason only when no reason is supplied. Fixed-reason orientation operations always use their system reason."

addedInput schema / properties / task_key / description

Added value: +"Optional stable label grouping operations for the same user task. Omit to inherit the parent task key, if any. It does not schedule work or provide idempotency."

changedInput schema / required

Previous value: -[
-  "reason",
-  "operation"
-]New value: +[
+  "operation"
+]

AddedSep 11, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that previews record private action history and audit events, making clear the operation is not fully side-effect-free even though changes are not applied. 'Without applying the proposed changes' clarifies write semantics, and nothing contradicts 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.

Conciseness5/5

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

The description is three sentences with no filler: core behavior first, schema pointer second, side-effect disclosure third. Every sentence earns its place.

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?

With an output schema and fully described parameters, the description plus schema covers what an agent needs: behavior, side effects, and the pointer to candor_schema for operation-specific arguments. It could be more complete by explicitly naming the applying sibling, but that is not a critical gap for a preview tool.

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%, and each parameter already has a detailed schema description. The tool description itself adds no independent parameter semantics beyond referring to candor_schema for operation arguments, so the baseline of 3 is appropriate.

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 precise verb and object: it previews a POST operation through the Candor API and explicitly states it does not apply the proposed changes. This clearly distinguishes it from write/apply tools and from candor_schema, which describes operations.

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

Usage Guidelines3/5

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

Use is implied: preview is for inspecting a POST operation before applying it, and the description points to candor_schema for operation details. However, it never explicitly names an alternative like candor_write for actually applying changes, nor does it state when not to use preview.

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

All Candor Finance tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.