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

readOnlyHint=true already tells the agent nothing is mutated, and the description adds no behavior beyond that: it does not say whether the built signals are returned, saved, or how series ids are referenced by signal ids. Worse, "Needs version, data, series, and signals" misstates the contract, since the schema requires only version and data, and it silently omits money and simulation entirely.

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 short sentences, front-loaded and free of filler, so nothing is wasted. However, the brevity is under-specification rather than efficiency given the size of the payload the agent must construct.

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 whose input is a nested graph DSL (series ops, signal predicates, allocation, simulation, stops/targets) with no output schema and only a readOnly annotation, two sentences are grossly inadequate. An agent cannot construct a valid run form from this description alone.

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?

Nominally one parameter, but that parameter is a deeply nested run form with operators, id cross-references, and simulation settings at 0% schema description coverage. The description only echoes four top-level keys, omits money and simulation, and explains none of the id-linking semantics that make the DSL usable.

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?

"Build named trading signals from a run form" gives a verb and resource, but "run form" is undefined jargon and the sentence does not distinguish this from siblings like build_series or simulate. The agent learns a signals artifact is produced, but not how that differs from building a series graph or running a simulation.

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 when-to-use guidance, no ordering relative to build_series/save_strategy/simulate, and no statement of whether the result is persisted or passed onward. Usage is at best implied by the name.

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