Skip to main content
Glama

Preview Candor changes

candor_preview

Previews one POST operation in the Candor API and returns the proposed result without applying it. Use when the user wants to see what a change would do before it is saved. Arguments follow the operation's published contract (API reference: https://candor.money/developers). Previews are recorded in private action history; the proposed changes are not applied and financial records are not changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNoThe selected operation's accepted_args, as published in its contract, including declared shorthand such as the open.acknowledge checkpoint. Action context such as parent_action is a top-level field, not an argument. Request-body fields belong in input unless the operation accepts them as shorthand args.
inputNoInline request body matching the operation's published input schema. Fields such as a note's about link belong inside this object.
reasonNoConcise user-visible purpose recorded in immutable action history, including for financial reads. It names the task, such as "Check this month's dining budget", and needs no personal details from the conversation. 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_keyNoOptional 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.
operationYesExact operation id from the Candor operation catalog, such as notes.create.
parent_actionNoExisting action id in this workspace, typically returned in next_actions, that this continuation follows. A continuation with the parent's reason joins the parent's root action, whether the reason is omitted (it is then inherited) or repeated exactly; a distinct explicit reason is preserved and starts a new root that keeps this parent link. Fixed-reason orientation operations always start a new root. Omit for a new root action.
idempotency_keyNoStable 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
NameRequiredDescriptionDefault
dataYes
actionNo
errorsYes
statusYes
metadataNo
warningsYes
request_idYes
generated_atYes
next_actionsYes
user_messageNo
data_freshnessNo
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / parent_action / description
      Previous 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."New value: +"Existing action id in this workspace, typically returned in next_actions, that this continuation follows. A continuation with the parent's reason joins the parent's root action, whether the reason is omitted (it is then inherited) or repeated exactly; a distinct explicit reason is preserved and starts a new root that keeps this parent link. Fixed-reason orientation operations always start a new root. Omit for a new root action."
  2. Changed4 schema fields changed
    • changedInput schema / properties / args / description
      Previous value: -"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."New value: +"The selected operation's accepted_args, as published in its contract, including declared shorthand such as the open.acknowledge checkpoint. Action context such as parent_action is a top-level field, not an argument. Request-body fields belong in input unless the operation accepts them as shorthand args."
    • changedInput schema / properties / input / description
      Previous value: -"Inline request body matching the operation input schema returned by candor_schema. Put fields such as a note's about link inside this object."New value: +"Inline request body matching the operation's published input schema. Fields such as a note's about link belong inside this object."
    • changedInput schema / properties / operation / description
      Previous value: -"Exact operation id from candor_schema, such as notes.create. Use the tool indicated by its calls.mcp or next_call."New value: +"Exact operation id from the Candor operation catalog, such as notes.create."
    • changedInput schema / properties / reason / description
      Previous 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."New value: +"Concise user-visible purpose recorded in immutable action history, including for financial reads. It names the task, such as \"Check this month's dining budget\", and needs no personal details from the conversation. 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."
  3. Changed7 schema fields changed
    • 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"
      +]
  4. Added

TDQS

A3.9/5.0
Behavior4/5

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

Adds real context beyond the annotations: previews are recorded in private action history and the proposed changes / financial records are not altered. This usefully reconciles why readOnlyHint is false despite being non-applying. It does not discuss idempotency or retry behavior, which the schema carries instead.

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?

Four tight sentences with the core purpose and the non-applying guarantee front-loaded. The API-reference pointer is compact; nothing is wasted, though the history/records sentence partially overlaps the same idea twice.

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 complex 7-parameter tool with nested objects and an output schema (so return values need no explanation), the description covers purpose, dry-run semantics, and contract source. The main omission is an explicit pointer to the apply alternative for a routing decision.

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 all seven parameters are already richly documented in the schema itself. The description only says arguments follow the operation's published contract and links to the API reference, adding no parameter-level meaning of its own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (previews) and resource (one POST operation in the Candor API) plus the key outcome: returns the proposed result without applying it. An agent can tell this is a dry-run distinct from an apply tool, though the description never names the sibling (candor_write) it is contrasted with.

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?

Gives a clear when-to-use trigger: 'Use when the user wants to see what a change would do before it is saved.' However it never states when NOT to use it or names the alternative that actually applies the change, leaving the routing decision to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.