finance_investment_cash_movement_request

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

Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the behavioral profile is partially known. The description adds useful context about routing through the domain-agent dispatcher under JWT, tenant, and company scope. However, it does not disclose what effects the action triggers, whether approvals are involved, or what the destructive nature consists of. There is 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 compact and the argument list is easy to scan. It front-loads the routing/scope context and keeps the parameter docs brief. It loses a point because the opening sentence mostly repeats the tool name rather than adding new information.

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 that dispatches a domain agent action with free-text and JSON inputs, the description is too thin. It omits the intended effect, input contract, example usage, and behavioral consequences. An agent selecting or invoking this tool would have to guess what a valid cash movement request looks like and what the action will do.

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 0%, so the description carries the full burden for explaining parameters. It provides only minimal labels: message is a "free-text objective" and inputs is an "Optional JSON string of structured inputs." It does not explain what the objective should contain, what structured inputs are accepted, what format or keys are valid, or how message and inputs relate to the underlying 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 first sentence, "Run the finance domain agent action `investment_cash_movement_request`", is essentially a tautology—it restates the tool name without explaining what a cash movement request actually does. It adds that this goes through a domain-agent dispatcher, but that is routing mechanics, not purpose. An agent cannot distinguish this from the many finance investment siblings based on this description.

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 provides no guidance on when to use this tool versus other finance tools or when to avoid it. There is no mention of alternatives, prerequisites, approval flows, or conditions under which this action is appropriate. The dispatcher and scope information is context, not usage guidance.

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