Candor Finance

Configure Candor Overview

candor_configure_overview

Destructive

Save exactly five unique panels as the workspace Overview. Reuse idempotency_key for transport retries, which replay the original result. After a refused action and access recovery, start a new save with a new key. Returns the saved configuration or an access recovery envelope; candor_visualize reads the configured Overview or individual panels.

Input Schema

TableJSON Schema

Name	Required	Description
`panels`	Yes
`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.
`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
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 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."

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: -[
-  "panels",
-  "reason"
-]New value: +[
+  "panels"
+]

AddedSep 11, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and idempotentHint=false, but the description adds meaningful behavioral detail: that reusing idempotency_key replays the original result, that a new key is required after a refused action and access recovery, and that the return may be an 'access recovery envelope'. This goes beyond the annotation flags without contradicting them.

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 composed of three tightly scoped sentences, front-loaded with the core action and constraint. It avoids redundancy and every clause adds operational value (panels constraint, idempotency behavior, recovery requirement, return type, and reading sibling). No wasted words.

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?

Given the operation's complexity (5 parameters, output schema, destructive annotation), the description covers essential context: exact panel count, retry semantics, recovery handling, and the return type. The existence of an output schema means return values need not be detailed. A small gap is the absence of any prerequisite or condition stating when configuration is allowed, but the description is otherwise complete.

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 80%, with detailed descriptions for reason, task_key, parent_action, and idempotency_key. The description adds minimal parameter-specific value: it reiterates the panels constraint ('exactly five unique panels') and the idempotency_key retry behavior, both already covered by schema descriptions. Thus a baseline score 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 clearly states the action: 'Save exactly five unique panels as the workspace Overview.' It specifies the resource (Overview), the constraint (exactly five unique panels), and the expected result (returns saved configuration or access recovery envelope). It also differentiates from candor_visualize by noting that the latter reads the Overview, making the separation of concerns obvious.

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?

The description provides context on when to use this tool: to configure the Overview, and indirectly when not to use it by mentioning candor_visualize reads the configured Overview. It also gives operational guidance on idempotency_key reuse for retries and recovery after refused actions. However, it does not explicitly enumerate exclusions or alternatives beyond candor_visualize, so a slight deduction from a perfect score.

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.