tgov_info

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

With no annotations, the description carries the full burden and does a reasonable job on rule semantics: threshold crossings are spelled out (15% caps high-risk tiers at 50%, 30% pauses, 60% freezes all), the verdict set is enumerated, and 'worst case wins' plus 'full audit log' are useful behavioral facts. However, it says nothing about permissions, idempotency, cost of the call, or determinism, and it describes inputs the schema cannot accept, so the behavioral picture is incomplete and partly inconsistent.

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 body is dense but front-loaded, moving from purpose to inputs to rule thresholds to verdicts in a logical order with no filler. The default-pack parenthetical is efficient, but the text ends mid-sentence ('This tool return'), an obvious structural defect that leaves the reader without the promised closing 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 governance-simulation tool with no annotations and no output schema, the description explains what comes back (a decision per agent plus an audit log) and enumerates the possible verdicts, which is the critical missing piece an output schema would normally supply. The gaps are the truncated final sentence and the unresolved mismatch between the described inputs and the empty input schema.

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 schema declares zero properties with additionalProperties=false, yet the description specifies a fleet of agents, per-agent risk tier 1-5, mandate cap, requested amount, market volatility percentage, and optional governance rules. That is a direct conflict about how to invoke the tool: an agent following the prose would try to pass arguments the schema rejects. The parameter meaning is actually richly explained, but attributing it to a parameterless schema is misleading rather than helpful.

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 a specific verb-and-resource ('coordinated deployment decision' for 'treasury capital') and clearly frames the tool as a governance/coordination engine, which distinguishes it from the many read-only info and dashboard siblings in the list. The opening '[FREE] TGOV - Treasury Governance Coordination' plus the summary of inputs and outputs makes the purpose recognizable, but the trailing sentence cuts off mid-word ('This tool return'), leaving the purpose statement incomplete.

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?

Usage is implied rather than stated: the description conveys that this is the tool to call when a fleet of agents competes for treasury capital under volatility conditions, and the default rule pack gives a concrete picture of when verdicts escalate. There is no explicit 'use this instead of X' routing, no prerequisite or exclusion guidance, and the truncation removes whatever guidance the final sentence intended.

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