Candor Finance

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

Annotations already flag destructiveHint=true, and the description aligns by mentioning 'confirmed deletion', adding that deletion requires confirmation. It also warns that subscription changes are out of scope, which is extra behavioral guidance beyond the annotation. No contradiction found.

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

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

Two terse sentences with no redundancy. The primary capability is front-loaded and the exclusion is stated plainly. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and nested objects, the description is too high-level. It does not explain how to invoke inspection vs deletion, what the 'operation' parameter expects, or what the output represents. An agent would need substantial inference to correctly call this tool for a specific account action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43% and the description provides no information about any parameter, such as 'operation' or 'reason'. The agent is left without guidance on how to specify whether to inspect or delete, or how to fill the required fields. The description fails to compensate for low schema coverage.

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

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

The description clearly states the tool's dual purpose: inspect saved sign-in details or perform confirmed deletion for the signed-in Candor account. The verb 'inspect' and 'perform' with resource 'account' make the action explicit and distinguish it from sibling tools like candor_write or candor_get.

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

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

It provides a clear context for account management and explicitly excludes subscription changes by noting they happen only on secure Candor account pages, which tells the agent when not to use this tool. However, it does not name alternative tools or describe scenarios that select inspection vs deletion.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'without acknowledging workspace activity' (clarifying no side effects on history) and 'deterministic' (echoing idempotency). This is useful but minimal; it does not describe the return format or pagination behavior. No contradiction with annotations.

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

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

The description is a single sentence that front-loads the core action and contains no redundant phrasing. It is concise and to the point, though possibly too sparse given the tool's complexity. For length and structure, it earns a high score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fails to explain what 'changes' means, what the output contains (despite an output schema existing, it is not referenced), how the seven parameters are used, or the appropriate usage context. For a tool with 7 parameters and an output schema, this is severely under-specified, leaving an agent unable to invoke it correctly without external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29% (only 'reason' and 'inline_response' have descriptions). The tool description does not mention any of the seven parameters or provide additional context for them. Since coverage is low, the description must compensate, but it provides nothing about limit, domain, task_key, parent_action, or account_identity_id, leaving an agent without guidance on parameter usage.

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

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

The description states a specific action ('Read deterministic factual changes') and a resource ('changes'), which is clear on the surface. However, 'deterministic factual changes' is ambiguous and does not specify what kind of changes are involved, nor does it differentiate from sibling tools like candor_query or candor_get. The title 'Inspect Candor changes' adds little beyond restating the name.

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

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

The description offers no explicit guidance on when to prefer this tool over alternatives. The phrase 'without acknowledging workspace activity' implies read-only usage but does not state that explicitly or name any sibling tools or exclusion criteria. An agent would have to infer the appropriate context, which is a significant gap.

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

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

Annotations already declare the tool destructive (destructiveHint=true) and non-idempotent (idempotentHint=false). The description adds scope clarity by clarifying that connection management is not done here, which is useful. However, it does not disclose what 'refresh' actually does to data (e.g., whether it overwrites cached data or has side effects beyond the destructive hint). With annotations covering the safety profile, this is adequate but not rich.

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

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

The description is two sentences with no fluff. The core purpose is front-loaded, and the pointer to an alternative is included. Every sentence earns its place, and the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a complex tool with 7 parameters, including a required 'operation', nested objects, and destructive behavior, the description is far from complete. It doesn't explain what the 'operation' parameter expects, how to target a specific connection, or any side effects beyond the annotations. An agent would likely misuse this tool without more guidance, making it insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43% (3/7 parameters have descriptions). The description provides zero parameter-level information. The required 'operation' parameter is not explained at all, and there is no guidance on how to specify which connection to refresh. The description fails to compensate for the schema coverage gap, leaving agents with insufficient information to construct valid calls.

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

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

The description clearly states 'Refresh already-connected sources' with a specific verb and resource. It differentiates from connection management by noting that connection/reconnection/disconnection happen only in the secure web portal, implying this tool does not handle those. However, it does not explicitly name a sibling tool, so it gets 4 rather than 5.

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

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

The description gives clear usage context: use this tool to refresh existing connections, and for inspection it directs to 'query the accounts dataset' (which corresponds to a sibling tool like candor_query). It implicitly says not to use this for connection changes, but it does not explicitly name the alternative tool, so it's not a full 5.

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

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint false, openWorldHint false). The description adds beyond this by disclosing response behavior — large responses default to resource links and inline_response may return very large payloads. This is valuable context about output size and materialization that annotations do not express.

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

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

Three sentences with zero filler; the core purpose is front-loaded, followed by the prerequisite routing and then the response-size caveat. Every sentence earns its place and no information is repeated from annotations or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter tool with nested objects, the description covers purpose, prerequisites, and response behavior, and the presence of an output schema relieves it of return-value explanation. However, it leaves idempotency_key, parent_action, and task_key semantics unexplained, so an agent is under-specified on the action-history/idempotency parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is ~50%; the schema documents args (path/query), input (request body), and inline_response. The description adds linkage by tying args to candor_schema-discovered operations, but leaves operation, task_key, parent_action, idempotency_key, and reason semantically thin in both schema and prose, so it only partially compensates for the coverage gap.

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

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

States a specific verb ('Read') with a resource ('one typed object or exact manifest-backed operation'). It is clearly a read tool, distinct from candor_write, but it doesn't explicitly name overlapping read-side siblings like candor_open or candor_query, so an agent must infer the differentiation.

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

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

Provides clear contextual guidance: route unfamiliar operations through candor_schema first, and only set inline_response when the client can materialize large results. It does not, however, state explicit when-not-to-use conditions against sibling read/query tools, so exclusions are absent.

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

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

All annotations are false (readOnlyHint=false, idempotentHint=false), indicating the tool may mutate state, but the description discloses no side effects, permission requirements, or other behavioral traits. It simply restates the action verbs without explaining consequences like workspace creation or state changes.

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

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

The description is a single sentence, front-loaded with the primary action, and contains no filler. It's concise, though the cramming of three operations into one phrase makes it slightly ambiguous yet still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, no required fields, and an output schema, the description should clarify how the tool behaves in different modes and what each parameter does. It does not explain mode semantics, interaction between parameters, or any side effects. The output schema exists, so return details are covered, but the overall context for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29% (only inline_response has a description; mode has an enum but no explanation). The tool description adds minimal parameter clarity—'acknowledge an opening checkpoint' hints at acknowledge_checkpoint, but reason, task_key, parent_action, and idempotency_key are entirely unexplained, forcing the agent to infer their meaning from names alone.

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

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

The description names specific verbs ('Open', 'check', 'acknowledge') tied to resources ('workspace', 'pulse', 'opening checkpoint'), which distinguishes it from the sibling tools like candor_get or candor_query. However, the three actions are conflated in one sentence without explaining what each entails, so it's not fully explicit.

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

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

No guidance is provided on when to use this tool versus its many siblings (candor_get, candor_write, etc.). There's no mention of alternatives, prerequisites, or contextual triggers. The 'open' semantics imply session initialization, but that's left to inference.

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

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

Even though readOnlyHint=true and idempotentHint=true already declare the safety profile, the description adds genuinely valuable behavior: large responses default to short-lived resource links with a JSON Pointer and value-free JSON Schema, the payload must be downloaded into a sandbox, and model-visible output should stay bounded. This gives the agent actionable data-handling expectations that annotations do not cover.

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

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

Four sentences, each earning its place: purpose, default resource-link behavior, sandbox handling instruction, and the inline_response alternative. It is front-loaded with the core purpose. Slightly dense in the middle (JSON Pointer, value-free JSON Schema, bounded output delivered in one sentence) but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists so return-value shape is covered, and annotations carry the safety profile. The description explains the resource-link default and inline_response path. The remaining gap is the two undocumented parameters, task_key and parent_action, which appear to relate to action-history tracking but are never explained, leaving an incomplete picture for a 6-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%; the schema documents reason, dataset (with enum), filters, and inline_response. The description adds real meaning to inline_response by specifying the client-capability condition under which it should be set. However, task_key and parent_action are entirely unexplained in both schema and description, so the description only partially compensates for the coverage gap.

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

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

The description opens with a specific verb+resource: 'Run one limited query against a declared financial dataset.' This clearly conveys a query operation against a pre-declared dataset and the scope qualifier 'one limited query' helps separate it from bulk or write operations among the siblings. It stops short of naming which sibling it differs from (e.g., candor_get), so differentiation is implied rather than explicit.

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

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

The description offers parameter-selection guidance (when to set inline_response based on client resource-link support) but gives no tool-vs-tool guidance, such as when to prefer candor_query over candor_get, candor_schema, or candor_write. No alternatives or exclusions are named, so an agent must infer the usage boundary from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool can perform three distinct operations, which is a behavioral trait beyond the annotations. However, it does not explain how these modes are selected (via which parameters) or what the response structure looks like, so the transparency is partial.

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

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

The description is a single sentence with no wasted words, making it concise. It lists three potential actions in a straightforward list format. However, it is not front-loaded with the most critical information; the primary purpose is unclear, but the sentence itself is efficiently constructed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 parameters, none required, and multiple possible behaviors, but the description is extremely terse. It does not explain how parameters interact, what output to expect, or how the different actions are triggered. Even though an output schema may exist, the description itself is inadequate for an agent to safely and correctly invoke the tool without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25% (only 'reason' and 'inline_response' have descriptions). The description itself provides zero parameter semantics. It does not mention any of the 8 parameters or how they map to the three claimed actions. With low schema coverage, the description fails to compensate, leaving the agent without meaning for the majority of parameters like 'dataset', 'operation', 'task_key', and 'parent_action'.

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

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

The description lists three distinct actions ('Inspect workspace schemas, describe an operation, or search the operation catalog') without indicating which one the tool actually performs or how they are combined. It is not a single clear purpose and does not distinguish itself from siblings like candor_query or candor_get. The verb 'inspect' is generic and the phrase 'describe an operation' is ambiguous, leaving the agent uncertain about the tool's core function.

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

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

There is no guidance on when to use this tool versus its siblings. It does not mention that it might be preferred for schema inspection or catalog searches, nor does it state any exclusion criteria. The description gives no context about when to invoke it or what triggers each of the three mentioned actions, leaving the agent to guess.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the default behavior of returning short-lived MCP resource links for large responses and the condition for inline_response. It also states the scoping constraint. These are useful additions, but it doesn't describe the output format or other side effects like response size limits.

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

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

The description is two sentences, front-loaded with the core purpose, and each sentence earns its place. There is no fluff or redundant detail, and the guidance on inline_response is clearly separated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 6 parameters and nested objects, the description is minimal. It does not explain the purpose or format of required parameters like reason and datasets, nor does it clarify task_key or parent_action. It lacks guidance on when to prefer this tool over candor_query or candor_get, and there is no mention of output structure beyond the schema. The presence of an output schema mitigates some gaps, but the description remains incomplete for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains inline_response (though the schema already has a detailed description for it) and mentions datasets are from candor_schema, but it does not elaborate on required parameters like reason, datasets, filters, task_key, or parent_action. With only 50% schema description coverage, the description fails to compensate for undocumented parameters, particularly the required 'reason' and 'datasets'.

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

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

The description states a specific verb (compose) and resource (analytical response), and adds a clear scope: 'using only the snapshot datasets declared by candor_schema.' This differentiates it from generic query tools and implies a specific use case, making it stand out from siblings like candor_query.

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

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

Provides explicit guidance for the inline_response parameter (when to use it and when not to), but does not address when to choose this tool over sibling tools. The scope restriction ('only the snapshot datasets') implies a use case, but there is no explicit 'use this when' or 'use candor_query instead' guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds no behavioral context beyond the basic purpose – it does not mention that the tool returns a resource link, that it can produce large responses, that it does not render visuals, or any side effects. It provides no additional nuance to guide invocation.

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

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

The description is a single concise sentence with no wasted words, and the main action is front-loaded. It is appropriately sized for a simple tool, though it sacrifices completeness for brevity. Given the tool's complexity, more detail could be added without harming conciseness, so a 4 is appropriate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 6 parameters, an enum, an output schema, and nested objects, yet the description provides almost no context. It does not explain what the six 'kind' options mean, how to choose among them, what inputs are expected in 'args', or what the returned dataset looks like. The description is far too sparse for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description says nothing about any parameter. Schema coverage is only 50%, and the description does not compensate for the undocumented 'kind', 'task_key', or 'parent_action'. The enum values for 'kind' are likely central to selecting the correct visual dataset, yet they are unexplained both in schema and description. This is a critical gap.

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

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

The description states a specific action ('Build the factual dataset') and a clear resource ('for one optional financial visual'). It distinguishes this from rendering visuals by saying it 'builds the dataset needed', implying a preparatory role. It could be more explicit about the kinds of visuals, but it is not tautological and clearly names the purpose.

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

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

There is no guidance on when to use this tool versus the many sibling tools (candor_query, candor_snapshot, candor_get, etc.). It does not state any preconditions, alternatives, or exclusions. An agent seeing only this description cannot determine whether to call candor_visualize or candor_query for a given task.

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

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

Annotations already declare destructiveHint=true, so the mutation aspect is known. The description adds that the write goes through validation, action-history, and audit boundary, which provides extra context beyond the annotations. However, it does not disclose what specific consequences the write has (e.g., overwriting, creating new records, irreversible changes), nor does it mention any permission or approval prerequisites beyond the word 'approved'.

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

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

The description is a single, well-structured sentence that front-loads the action 'Write'. It contains no filler or redundant phrasing. It efficiently communicates the core purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, nested objects, destructive behavior, and an output schema), the description is far too thin. It does not explain what 'operation' refers to, how to construct args versus input, the purpose of idempotency_key, or the role of task_key and parent_action. Even with the schema's partial descriptions, an agent would struggle to call this correctly without additional documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any of the seven parameters. With only 43% schema description coverage, the description fails to compensate for the undocumented parameters like operation, task_key, parent_action, and idempotency_key. It would be helpful to at least note that 'operation' should be obtained from candor_schema, or clarify the distinction between 'args' and 'input'.

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

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

The description clearly states the action (Write) and the resource (approved typed financial state), and the phrase 'through Candor's validation, action-history, and audit boundary' adds specificity. It differentiates from the read-oriented sibling tools (candor_get, candor_query) by implying a mutation. However, 'typed financial state' is somewhat jargon-heavy and could be clearer about what 'state' encompasses.

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

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

The description does not provide any explicit guidance on when to use this tool versus alternatives. It does not mention conditions, exclusions, or refer to sibling tools such as candor_schema for operation details. The only implicit cue is that it is a write operation, but no explicit 'use when' or 'instead of' guidance is given.

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