Candor Finance

Open Candor

candor_open

Read the workspace, or use mode=pulse for a compact inspection signal that carries no checkpoint. In the default opening mode the checkpoint is data.new_since_checkpoint.checkpoint_candidate, and the open.acknowledge entry in next_actions carries the same value as args.checkpoint; acknowledgment is a separate candor_write operation after processing that opening. This read records private action history and audit events without changing financial records. Return workspace context, financial position, approved state, new activity, factual attention, and executable next actions. Reading does not advance the shared checkpoint. The checkpoint for this opening is data.new_since_checkpoint.checkpoint_candidate; the same value is carried as args.checkpoint on the open.acknowledge entry in next_actions, so find that entry by command rather than by position. After processing this opening, acknowledge that exact checkpoint to mark activity as seen; acknowledgement does not resolve attention or due notes.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No
`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.

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.

Changed4 schema fields changedSep 14, 2026

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

Changed5 schema fields changedSep 11, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / acknowledge_checkpoint
```
Removed value: -{
-  "minLength": 1,
-  "type": "string"
-}
```
- removedInput schema / properties / idempotency_key
```
Removed value: -{
-  "maxLength": 128,
-  "minLength": 16,
-  "type": "string"
-}
```
- addedOutput schema / properties / metadata / properties
```
Added value: +{
+  "view_url": {
+    "format": "uri",
+    "type": "string"
+  }
+}
```
- removedOutput schema / properties / metadata / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

Changed1 schema field changedAug 27, 2026

addedOutput schema / properties / metadata

Added value: +{
+  "additionalProperties": {},
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

Changed2 schema fields changedAug 26, 2026

removedOutput schema / properties / summary

Removed value: -{
-  "minLength": 1,
-  "type": "string"
-}

changedOutput schema / required

Previous value: -[
-  "data",
-  "errors",
-  "generated_at",
-  "next_actions",
-  "request_id",
-  "schema_version",
-  "status",
-  "summary",
-  "warnings"
-]New value: +[
+  "data",
+  "errors",
+  "generated_at",
+  "next_actions",
+  "request_id",
+  "schema_version",
+  "status",
+  "warnings"
+]

Changed2 schema fields changedAug 26, 2026

removedOutput schema / $defs / __schema1

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "number"
-    },
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    },
-    {
-      "items": {
-        "$ref": "#/$defs/__schema1"
-      },
-      "type": "array"
-    },
-    {
-      "additionalProperties": {
-        "$ref": "#/$defs/__schema1"
-      },
-      "propertyNames": {
-        "type": "string"
-      },
-      "type": "object"
-    }
-  ]
-}

removedOutput schema / properties / query_scope

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "population": {
-      "additionalProperties": false,
-      "properties": {
-        "included_count": {
-          "maximum": 9007199254740991,
-          "minimum": 0,
-          "type": "integer"
-        },
-        "total_available_count": {
-          "anyOf": [
-            {
-              "maximum": 9007199254740991,
-              "minimum": 0,
-              "type": "integer"
-            },
-            {
-              "type": "null"
-            }
-          ]
-        }
-      },
-      "required": [
-        "included_count",
-        "total_available_count"
-      ],
-      "type": "object"
-    },
-    "query": {
-      "additionalProperties": false,
-      "properties": {
-        "args": {
-          "additionalProperties": {
-            "$ref": "#/$defs/__schema1"
-          },
-          "propertyNames": {
-            "type": "string"
-          },
-          "type": "object"
-        },
-        "operation": {
-          "minLength": 1,
-          "type": "string"
-        }
-      },
-      "required": [
-        "args",
-        "operation"
-      ],
-      "type": "object"
-    }
-  },
-  "required": [
-    "population",
-    "query"
-  ],
-  "type": "object"
-}

Changed2 schema fields changedAug 26, 2026

addedOutput schema / $defs / __schema1

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "number"
+    },
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    },
+    {
+      "items": {
+        "$ref": "#/$defs/__schema1"
+      },
+      "type": "array"
+    },
+    {
+      "additionalProperties": {
+        "$ref": "#/$defs/__schema1"
+      },
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    }
+  ]
+}

addedOutput schema / properties / query_scope

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "population": {
+      "additionalProperties": false,
+      "properties": {
+        "included_count": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "total_available_count": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "included_count",
+        "total_available_count"
+      ],
+      "type": "object"
+    },
+    "query": {
+      "additionalProperties": false,
+      "properties": {
+        "args": {
+          "additionalProperties": {
+            "$ref": "#/$defs/__schema1"
+          },
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        },
+        "operation": {
+          "minLength": 1,
+          "type": "string"
+        }
+      },
+      "required": [
+        "args",
+        "operation"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "population",
+    "query"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedAug 20, 2026

addedOutput schema / $defs

Added value: +{
+  "__schema0": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "number"
+      },
+      {
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      },
+      {
+        "items": {
+          "$ref": "#/$defs/__schema0"
+        },
+        "type": "array"
+      },
+      {
+        "additionalProperties": {
+          "$ref": "#/$defs/__schema0"
+        },
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      }
+    ]
+  }
+}

addedOutput schema / properties / next_actions / items / properties / args / additionalProperties / $ref
```
Added value: +"#/$defs/__schema0"
```

First observedAug 17, 2026

TDQS

A4.2/5.0

Behavior5/5

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

The description discloses important behavioral traits beyond annotations: reading records private action history and audit events without changing financial records, reading does not advance the shared checkpoint, and acknowledgment does not resolve attention or due notes. It also explains the checkpoint/acknowledgment mechanism in detail. These statements do not contradict readOnlyHint=false, since audit recording is a side effect without financial mutation.

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

Conciseness3/5

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

The description is front-loaded with the main purpose and contains rich operational detail, but it repeats the checkpoint/args.checkpoint relationship almost verbatim twice, making it longer than necessary. A single consolidated explanation of the checkpoint flow would be tighter without losing information.

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?

Given the output schema and four optional parameters, the description is complete enough for an agent to invoke the tool correctly. It covers purpose, mode differences, side effects, checkpoint behavior, the acknowledgment step as a separate candor_write operation, and the limits of acknowledgment. Nothing essential to executing the operation 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?

Schema coverage is 75%, and the parameters reason, task_key, and parent_action already carry detailed schema-level descriptions. The description adds meaningful semantics for mode, explaining that pulse is a compact inspection signal with no checkpoint while the default opening mode carries a checkpoint. This compensates for the one parameter that lacks schema-level description.

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?

The description clearly states the tool's action: 'Read the workspace' and enumerates the returned content, including workspace context, financial position, approved state, new activity, factual attention, and executable next actions. It also distinguishes the default opening mode from the compact pulse mode. However, it does not explicitly contrast candor_open with sibling read tools like candor_get or candor_query, so sibling differentiation is implicit rather than named.

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 gives concrete usage guidance for mode selection: use mode=pulse for a compact inspection signal with no checkpoint, otherwise use the default opening mode. It also describes the required follow-up acknowledgment via candor_write and cautions that the open.acknowledge entry must be located by command rather than position. It does not state when to prefer candor_open over sibling read tools, but the operational flow is clear.

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.

Open Candor

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources