Fx Stack Measure

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

With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: the run takes roughly 10 s and it executes the chain the way the live engine does (i.e. a realistic re-measurement). It omits whether results are persisted/overwrite prior measurements, whether the tool blocks or is expensive enough to avoid calling repeatedly, and any side effects — significant gaps for an unannotated tool.

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?

It is short — a single sentence — and front-loads the action, but the embedded parenthetical and the colon-clause appendage make it awkward to parse on first read. Brevity is achieved at some cost to legibility.

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?

An output schema exists, so return values need not be described. Still, for an unannotated tool with zero schema coverage the description leaves key gaps: the undefined unit of "cost", the undocumented project parameter, and no indication of whether measurements are stored and how they relate to fx_stack_save/fx_stack_load.

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 0%, so the description is the only source of parameter meaning. It does explain that name=None measures every stack, which is genuinely valuable, but the project parameter is never mentioned and no format or scoping semantics are given for either.

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 verb+resource pair ("Measure a stack's cost on this machine") is present and distinguishes this from the fx_stack_save/load/list siblings, which are clearly different operations. However, "cost" is never defined (CPU load? render time? headroom?), and the parenthetical "10 s through the chain the way the live engine runs it" is too tangled to resolve the ambiguity, so an agent gets a directionally correct but fuzzy 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?

It names two trigger conditions — "after a machine change, or when a set runs behind" — which is real usage context. It does not state when NOT to measure, name any alternative (e.g. deck_cost, live_parity, live_measure siblings) that also reports performance, or explain what "runs behind" means operationally.

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