Cubicle

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

Annotations already declare readOnly/ idempotent/ non-destructive, so the safety profile is covered. The description adds useful behavior beyond that: it is a self-scoped read (no target parameter) and it exposes capability gating by tier, which an agent could not infer from the empty schema.

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 sentences, front-loaded with what the tool returns and ending with the operative usage rule. The parenthetical tier list is dense but each element earns its place by naming valid tier values.

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 no output schema present, the description carries the return-value burden and does so fully: tier values, plan and its expiry, and the per-capability open/tier mapping. Nothing essential for calling or interpreting this zero-arg tool 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?

The tool takes zero parameters, which is the baseline-4 case per the rubric. There are no fields to explain, and the description correctly gives no parameter guidance.

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 conveys that this is the caller's own account record, enumerating its contents (tier, plan, expiry, per-capability status). It implicitly distinguishes itself from lookalike siblings such as 'plans' by scoping to the caller, though no explicit verb (returns/fetches) is used.

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 gives a concrete when-to-use rule: 'Call it before telling a trader what they can or cannot do.' That is a clear trigger condition, but no alternative tools are named or excluded, so it falls short of the top-tier when/when-not/alternatives 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, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the content shape (eight-state machine, gates, per-tool tier and caller access, flows), which tells the agent what it will get back. It does not warn about payload size or cost of pulling the entire API in one call, which would have pushed this higher.

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?

A single dense sentence plus a short imperative routing clause, with the payload contents front-loaded and the usage trigger last. Every clause carries information; there is no filler or restatement of the name.

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 no output schema and no parameters, the description bears the burden of explaining the return payload and it does so adequately by naming the three content groups. It is nearly complete, missing only practical details such as response format/size that an agent planning a first call might want.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No misleading or missing parameter guidance.

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 precisely what the tool returns: the whole API as data, broken into the state machine and gates, the tool/tier inventory, and the flows. That is a specific resource description that clearly distinguishes it from the action-oriented siblings (forge, grade, studio_move), which an agent can tell apart without opening any schema.

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?

Gives an explicit trigger condition: 'Call it first when asked what Cubicle can do.' This is clear context for when to use it. It stops short of a 5 because it offers no exclusions or disambiguation against siblings for adjacent questions (e.g. reading a specific tool's schema), though the tool is genuinely a unique discovery entry point.

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 cover the read-only, idempotent, non-destructive, closed-world profile, so the description's added value is the rendering semantics: same geometry as the on-screen chart, server-side render, envelope cone only when calibration permits, past windows only, 600-bar cap. It does not say how the PNG is delivered (inline/base64/URL) or any size limits, which is the remaining behavioral gap.

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?

Dense and front-loaded — the render-plus-JSON duality comes first, then the interpretive rule, then the hard constraints. The opening clause is long but every sentence carries distinct information; nothing is redundant.

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 no output schema, the description correctly carries the return-shape burden: a PNG plus chart_state JSON for the same window, plus the past-only and 600-bar limits. It leaves unresolved how the image is transported in the response, which is the one thing an agent might still need.

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 100%, so the baseline is 3, but the description adds real meaning: the 600-bar cap bounds how wide the from/to window can be, and 'the envelope cone when its calibration permits' qualifies what the indicators parameter can actually draw. The market/tf enums are left entirely to the schema.

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 and resource: renders a server-side PNG chart plate for one market/timeframe/window, and returns the matching chart_state JSON. It also implicitly distinguishes itself from the chart_state sibling by assigning the numbers to the JSON and the picture to the image, so an agent can route correctly without opening a schema.

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?

Gives clear usage context: use the picture for shape, quote numbers from the JSON, never read values off the image. It also states the past-windows-only and 600-bar constraints. It does not explicitly name a sibling alternative (e.g. 'use chart_state for numbers only'), so it stops short of full when/when-not routing.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the description adds the non-obvious operational constraints: past windows only and a 600-bar cap. It also explains that values are computed and deterministic rather than visually approximated, which sets expectations about precision, though it says nothing about what happens on out-of-range requests.

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?

One extremely dense sentence that front-loads the headline purpose, but it is padded with parentheticals and an enumerated return-field list ('open, close, high, low, range, change, volume, session'). The aside 'theirs — they may be used as levels the trader gave' is ambiguous and costs more than it earns.

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?

There is no output schema, so the description must convey the return shape, and it does: bars (count, first/last, last candle), indicators, trader levels/zones, the envelope and its gate, and the window fact sheet. Combined with the coverage limits and past-only constraint, an agent has enough to call it correctly; only error/empty-result behavior is unaddressed.

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 100%, so tf, from, to, market and indicators are already documented; the description only restates that a single market/timeframe/window is in play. It adds conceptual framing of what indicators and 'the trader's own marked levels and zones' mean, but no format or syntax detail beyond the schema. Baseline 3 applies.

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 opening clause names a concrete verb and resource ('what the deck's chart would show') plus the scoping dimensions (one market, timeframe, window) and the output form (ONE JSON object computed in code). It contrasts itself with a pixel-reading approach, so an agent can tell it apart from chart_image without inspecting either schema.

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?

'Use it instead of reading pixels: every number is measured, not read' explicitly routes the agent away from the image-based alternative, and 'Past windows only; at most 600 bars' states hard applicability limits. It stops short of naming the sibling tool outright or stating what to use for live/forward data, so it's clear context rather than a complete when/when-not guide.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful context beyond annotations: the 30-minute turn cadence, the 45-minute staleness threshold, and that the view is composed from logs and venue without asking a model. It does not describe return format or pagination, but no output schema exists and the content overview is reasonably complete.

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 a single dense sentence-like passage with multiple clauses; the important scoping facts (staleness, source, not a forecast) are present but not front-loaded, and there is some redundancy in describing what is composed. It earns most of its words but could be tightened and structured with shorter sentences.

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 read-only single-parameter tool with no output schema, the description covers the source of data, cadence, staleness, and the categories returned, which is enough for an agent to invoke correctly and interpret results. It stops short of specifying the exact response shape, but that is acceptable given the content summary.

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 100% and the enum lists the three markets, so the schema already documents the parameter. The description reinforces that the tool composes a view across markets when no market is given via 'each market's decision,' which clarifies the omitted-parameter behavior beyond the schema text.

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 resource ('the house Nemotron desk') and enumerates what it returns: last turn, per-market decisions, which reader decided, facts read, and venue positions with PnL. It also explicitly states 'Not a forecast,' which helps distinguish from the 'forecast' sibling, though without naming it directly. No other sibling tool appears to expose desk state, so differentiation is implicit 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?

Usage is implied by the contents described, but there is no explicit when-to-use / when-not-to-use guidance or mention of alternative tools. The 'Not a forecast' note hints at a boundary but does not direct the agent to the forecast tool or explain when this desk read is preferable.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely non-structured facts: it is free, requires no key, is computed on this server (not fetched), and nothing is stored. It does not discuss failure modes or input limits, keeping it short of a 5.

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 sentences, front-loaded with the most decision-relevant fact ('FREE, no key'), and no filler. The middle clause about agents and the coordination layer is slightly verbose but still informative.

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?

No output schema exists, but the description states the return format (64 hex characters), which is the key missing piece for this utility. For a stateless two-parameter hash function with full schema coverage, this is complete enough; only edge cases (empty input, max length) are unaddressed.

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 100% with both parameters documented, including the enum and the sha256 default, so the schema does the heavy lifting. The description restates the algorithm options and confirms the 64-hex output but adds no format or constraint detail beyond the schema.

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+resource ('the sha256 (or keccak256) digest of a text'), names both supported algorithms, and specifies the exact output shape (64 hex characters). No sibling tool in the list performs hashing, so it is trivially distinguishable.

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?

Gives clear usage context: agents/registries/coordination layer use it to verify that the server returns content verifiable by code, and notes it also works as a plain utility. It does not, however, state when NOT to use it or point to any alternative tool for related tasks.

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 only say it is a non-destructive, non-idempotent mutation. The description adds real behavioral context beyond that: the drawing persists on the chart and appears in films of that window, points must be in the past, lime ink is refused, and path points must move forward in time. It does not explain confirmation or reversal behavior.

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?

Front-loads the action and the supported shapes, then layers constraints and side effects. Dense but every clause carries information; the only expendable flourish is the parenthetical about lime and the fire.

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 5-parameter mutation with no output schema, the description covers the operation, per-kind anchor rules, price/time sourcing, ink restrictions, and the visibility side effect. It leaves only minor gaps around confirmation and how redrawing of the same anchor is handled.

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 100%, so baseline is 3, but the description materially enriches it by mapping each kind to its point requirements (line=two points, box=two corners, path=2-24 forward-moving points, note=one point plus a short word) and explaining why the lime enum value is unavailable. That goes beyond the enum lists and terse schema descriptions.

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?

Opens with a specific verb and target ("Draw on the trader's chart") and enumerates the exact artifact types it produces (line, box, path, note), each with its anchor count. An agent can distinguish this from siblings like erase and drawings purely from the text.

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?

"as they ask" and "a price the trader gave or the tape tool returned; never invent a level" imply this is user-initiated and constrain the price source, which is useful. However, there is no explicit statement of when to use this versus erase/drawings, nor prerequisites such as needing an open chart window.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, yet the description adds real context: drawings are anchored to bars with UTC times and prices, they are user-authored artifacts rather than signals, and there is a time-based reveal ('a film of the window lets each one appear as the clock reaches it'). That temporal behavior is valuable and not present in the structured fields.

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 sentences, front-loaded with the resource definition before the behavioral nuance. Despite slightly literary phrasing ('a film of the window'), no sentence is wasted and the key concept is delivered immediately.

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 single-parameter, read-only tool with full annotation coverage, the description gives the agent enough to call it correctly and understand the temporal reveal of results. The absence of any return-shape detail is a minor gap given there is no output schema, but the anchoring explanation largely compensates.

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 100% with a single enum-constrained 'market' parameter, so the schema fully documents the input. The description's talk of bar/price anchoring enriches the mental model of the returned data but adds nothing about the market parameter itself, making the baseline of 3 appropriate.

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 identifies a specific resource ('the trader's own drawings on one market's chart') and enumerates the forms it takes (lines, boxes, paths, notes), so an agent knows this is the read side of the drawing feature. It lacks an explicit retrieval verb, but the resource is unambiguous and distinct from write-oriented siblings like draw/erase.

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 only implied: the description establishes that these are the trader's existing drawings rather than signals, which nudges the agent toward a read/preview scenario. It never names alternatives such as draw, erase, chart_state or film, nor states when to prefer this tool over them, leaving routing 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?

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the agent's safety profile is fully carried by structured data. The description adds only the scoping detail (the trader's own drawings) and the 'only when they ask' constraint, without new behavioral context like reversibility or response. A 3 is appropriate given the annotations do the heavy lifting.

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?

A single front-loaded sentence with zero waste; the destructive action and its constraint are stated immediately.

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 single-parameter destructive tool whose safety profile is fully covered by annotations and whose output schema is absent, the description supplies enough to call it correctly. It does not note what happens after deletion, but with destructiveHint present that gap is minor.

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 100% and the id format (sk_ + 16 hex chars) is fully documented in the schema. The description only echoes the id source ('from the drawings tool'), adding marginal meaning beyond the schema. Baseline 3 applies when the schema does the work.

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 ("Remove") and resource ("one of the trader's drawings by its id") and points to the drawings tool as the source of ids, which helps distinguish it from siblings like draw and drawings. It is clear and specific but does not explicitly contrast with a sibling delete/alternative, so it stops short of a 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?

"Only when they ask" gives an explicit gating condition for invocation, effectively a when-to-use rule. However it names no alternative tools or edge cases (e.g., what if the id is unknown), so it is clear context without full alternatives coverage.

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 a non-read-only, idempotent, non-destructive, closed-world operation. The description adds valuable behavior beyond that: it returns a public link, plays and downloads as video, enforces a 24–360 bar past window, and instructs the agent to present the film as a replay, never a forecast. It does not discuss permissions or rate limits, but the added context is substantial.

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 front-loaded with the main action and then adds constraints and output details. It is dense but every sentence carries information: what is created, what is included, what is returned, limits, and the presentation rule. It could be split into shorter sentences for readability, but it is not bloated.

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 14-parameter mutation tool with no output schema, the description covers the essential output (public link, playback, download), the content options, and hard constraints on the time window. It also includes a critical presentation rule about not framing the film as a forecast. It does not address edge cases such as invalid windows or visibility/permissions, leaving a small gap.

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 100%, so the baseline is 3. The description adds meaningful constraints not fully captured by the schema: the window must be in the past and contain 24–360 bars, which directly qualifies the from and to parameters. It reinforces the optional content for drawings, marks, structure, and machine, but does not explain title, kicker, headline, palette, or seconds beyond the schema.

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 and resource: 'Seal a past window of the tape into a FILM.' It makes clear that the tool produces a replay video with drawings, optional structure, and machine trades. It does not explicitly distinguish this from siblings like replay_open or chart_image, so sibling differentiation is absent.

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 implies when to use it by giving constraints: '24 to 360 bars; the window must be in the past.' However, it never names alternatives or says when not to use this tool instead of replay_open, chart_image, or replay_record. The usage context is present but not explicit.

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?

Beyond the annotations (which already flag non-read-only, non-destructive, non-idempotent), it discloses that 'nothing is traded by this call,' that a new follow supersedes the existing one, what the runner does (mirrors fills under the record), and that it can be stopped with unfollow. This is rich operational context the structured fields do not carry.

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 dense, front-loaded prose that puts the core action and plan scope first, then the record contents, then the return values. Every clause carries information, though the single long paragraph is slightly heavy and could be broken up for scanning.

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 no output schema, the description carries the return burden and does so well: the record, its digest (the coordination record follow.created), and the attribution prefix copy:<you>:<model>. Combined with the supersede and runner behavior, an agent has everything needed to call and interpret the result.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: sizing as either fixed_notional usd or proportional bps of balance, the specific cap fields, and that follower_wallet is the address the runner signs mirrors with. It reinforces and interprets the schema rather than merely restating it.

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 concrete verb and resource: 'Follow a trading model (max plan): creates the follow record.' It explicitly separates itself from the siblings it could be confused with — follow_quote (validation), unfollow (stopping), and models (attribution source). An agent can distinguish it without opening any schema.

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 states the key constraint ('one active follow per model, a new one supersedes it'), points at follow_quote as the validation reference, and names unfollow as the way to stop. The main gap is that it doesn't spell out the precondition for calling it versus first quoting, leaving the order of operations partly implicit.

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=false, so 'Creates nothing and moves nothing' is partly redundant. Still, the description adds real behavioral detail the annotations cannot: it enumerates what gets validated (model liveness, sizing kind, caps) and that it computes a mirror size at a given balance.

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?

Front-loaded with the core action ('Quote following a trading model'), followed by one dense sentence and a short safety clause. Every clause carries information; the only mild cost is that the middle sentence is a long comma-chained run-on.

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 no output schema, the description still conveys the essential return concept ('shows what one mirror would be at the given balance') and the validation scope. For a 4-param, nested-object read tool it is close to complete, though the exact shape of the returned quote is not spelled out.

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 100% but the schema descriptions are only raw JSON examples. The prose adds genuine meaning by naming the sizing modes (fixed_notional usd vs proportional bps of balance) and each cap field (max_notional_usd, max_open_positions, max_daily_loss_usd, markets), clarifying the nested objects.

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 and resource: 'Quote following a trading model', and elaborates that it validates liveness, sizing, and caps and previews a mirror. However it never distinguishes itself from the sibling strategy_quote, leaving the agent to infer the strategy-vs-model split.

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 only implied: the phrase 'Creates nothing and moves nothing' signals this is a pre-flight/dry-run check before an actual follow action. No explicit when-to-use guidance, no named alternative among the many siblings, and no prerequisites are stated.

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 cover the safety profile (readOnly, idempotent, non-destructive), but the description adds that access requires a max plan and that records are private ('Yours only — no follower ever sees another's'). It also lists the possible statuses of follows, which aids interpretation.

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 compact sentences, front-loaded with the core resource and followed by a privacy clarification. No 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?

For a parameterless read tool with no output schema, the description sufficiently states the data returned (all own follows with digest and attribution) and the plan requirement. It omits pagination or sorting details, but those are minor.

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 tool takes no parameters, so the schema has nothing to document; the description correctly does not discuss parameters. Baseline 4 applies.

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 the resource ('follow records') and enumerates statuses and fields, making clear this is the listing tool for one's own follows, distinguishable from the 'follow' action sibling. It lacks an explicit verb, but the scope and content are specific.

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 when-to-use or alternatives are given; the only condition is the parenthetical '(max plan)'. An agent is left to infer that this is for viewing one's follows rather than creating or removing them.

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 readOnly/idempotent/non-destructive, and the description goes well beyond them: it states the band carries no directional information, is symmetric about the last close by construction, and that the system suppresses the deck when calibration is unmeasured. These are non-obvious behavioral facts an agent could not infer from structured fields.

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 front-loaded with what the envelope contains, then the directional caveat, then the calibration caveat. Dense but nearly every clause earns its place; the 'there is no side, no median… say so, and never turn it into up/down' passage is mildly repetitive but justified for a financially sensitive output.

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 no output schema, the description carries the full burden of describing return values, and it does — magnitude band in ATR terms, odds at 0.5/1/2 ATR over 6/12/24 bars, and calibration fields (ece, n, coverage). Combined with annotations covering the safety profile, an agent has everything needed to call and interpret it.

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 100%, with enums for market and tf and a documented `at` semantics, so the schema does the heavy lifting. The description only obliquely reinforces the `at`/timeframe scoping ('by a given time'); it adds no syntax or format detail beyond the schema.

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, self-contained resource — 'the envelope the forecast sidecar had issued for one market and timeframe by a given time' — and immediately scopes it (band, odds, calibration). No sibling tool in the list exposes this resource, so an agent can route to it without opening the schema.

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 strong interpretive guidance (treat unmeasured/uncalibrated bands as untrusted, never convert the output into up/down), but nothing about when to call this versus alternatives such as tape, chart_state, or strategy_quote. Usage context is implied by the resource, not stated.

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 non-read-only, non-destructive, non-idempotent, closed-world behavior. The description adds meaningful context beyond that: it compiles an artifact, the runner hash seeds the output, and refusal returns the next required move. It does not detail permissions or reversibility, but the annotated safety profile plus the stated gate behavior covers the key traits.

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 sentences, front-loaded with the core compile action and followed by refusal handling. The jargon is dense but every clause carries information; no 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?

With no output schema, the description still explains the produced artifact (cubicle.script v1), its grading role, and what a refusal result contains. For a one-parameter workflow tool this is close to complete, though it could clarify where the compiled script goes or whether the call is repeatable.

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 100% for the single 'intent' parameter, so the schema already defines it well. The description refers to compiling 'the trader's strategy' but does not add syntax or content guidance beyond the schema's own 'rule in the trader's words' description.

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 ('compiles') and resource ('trader's strategy' into 'cubicle.script v1'), and situates it as one of the studio machine's moves, which helps distinguish it from related siblings like studio_move. The heavy domain jargon ('gates the tape can measure', 'reader gate') slightly blurs the purpose for an outside agent.

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?

Explicitly states the prerequisite gates (READ, CLARIFIED, EXPRESSIBLE) and what to do on refusal, giving clear when-to-use and when-not-to-use context. It does not name alternative sibling tools to use instead, but the workflow condition is unambiguous.

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?

Beyond the readOnlyHint=true annotation, the description adds meaningful behavior: funds go straight into the trader's own wallet, Cubicle never holds the money, and it reports when card purchases are not yet enabled. These are real traits not captured by the annotations, and no annotation is contradicted by the non-mutating link-generation role.

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 purpose is roughly front-loaded, but the sentence mixes the tool's function with downstream workflow instructions and an awkward meta clause ('Answers plainly when card purchases are not switched on yet'). Trimmed, it would be tighter without losing content.

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 no output schema, the description is the only source on return values, and it conveys this only implicitly ('A link'). It covers the funding route and non-custodial nature but leaves the actual response shape and any flow/error semantics under-specified.

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 100%, so both 'owner' and 'amount_usd' (with its 20-10,000 range and default) are fully documented in the schema. The description adds no parameter detail, which is the expected baseline when the schema does the heavy lifting.

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 conveys that it produces a link to buy USDG via MoonPay by card, bank transfer or Apple/Google Pay, but frames it as a noun phrase ('A link to...') rather than a clear verb+resource, leaving the agent to infer it returns a URL. It does not differentiate itself from siblings such as onboard or vault_prepare.

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 gives sequencing guidance ('Then call onboard again: the next step is funding the vault') and notes the card-unavailable case, which is useful implied usage. However, it never states when to prefer this tool over alternatives like vault_prepare, so routing guidance is incomplete.

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 declare readOnlyHint=false, openWorldHint=true, and idempotentHint=false; the description adds genuinely useful context beyond them: it consumes a limited resource (one Jev decision), clarifies the two-phase evaluation (code checks facts, then Jev judges), and scopes its judgment to fidelity, explicitly not profitability. It does not contradict the 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?

Three dense but front-loaded sentences with no filler: what it does, what it costs, and what it judges. The jargon makes it compact at the expense of readability, but every clause carries 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 novel, side-effectful single-parameter tool with no output schema, the description conveys the mechanics (two-stage check), the cost model, and the evaluation criterion, which is enough to call it correctly. Return format is left implicit, but no output schema exists to conflict with that.

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 100% and the sole parameter seed_hash is documented as 'the seed hash forge returned'. With one fully documented parameter, the schema does the work and the description adds no syntax or format detail; baseline 3 applies.

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 gives a specific verb and resource — grading a forge with Jev under RUBRIC_v1 — and implicitly positions it as the post-forge evaluation step, which separates it from the sibling 'forge'. It is domain-jargon heavy ('Jev', 'RUBRIC_v1'), but the action and target are identifiable.

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 by 'Grade a forge' (i.e., after producing a forge) and it notes the cost — spending one of the trader's Jev decisions (trial, plan or key). It does not state when not to use it, nor explicitly name an alternative or prerequisite step.

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 declare readOnlyHint=false and openWorldHint=true, yet the description never explains why this access is not read-only or what side effect occurs. It does add useful epistemic guidance (numbers read off a picture are READ, not measured; verify against the tape), which is genuine behavioral context beyond the annotations, but side-effect and permission disclosure is absent.

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 one sentence, front-loaded with the action, so it is not bloated. But the em-dash-laden second half ('say plainly that numbers read off a picture are READ, not measured...') is dense and hard to scan, mixing invocation guidance with tutoring.

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 no output schema, the description should signal what comes back (an image for the agent to view? metadata?), and it only obliquely implies viewing. For a single-parameter tool the invocation side is covered, but the return side is left to inference.

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 100% (baseline 3), and the description adds provenance the schema lacks: the id is found in the studio state, telling the agent where to source the value rather than just what type it is.

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?

It conveys the resource (a chart the trader attached) and an action (look at / read it), which is more than a tautology on the name 'image'. However it never states mechanically what the tool does — fetch image bytes, return a description, or register the image into context — leaving ambiguity against siblings like chart_image and chart_state.

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 gives real context for invocation: the id lives in the studio state, and it is used when a trader has attached a chart. It stops short of naming alternatives (chart_image, chart_state) or stating when-not-to-use, so the routing signal is implied rather than explicit.

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 non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing the derivation ('venue's first-in-first-out paired closes') and the nature of the metric (realized, backward-looking), which is exactly the context needed to avoid misreading it as predictive.

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 tight sentences with the output contents front-loaded and no filler. The second sentence is an interpretive guardrail rather than a description of the tool itself, which is slightly off-topic for a definition but conceptually adjacent and worth its length.

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 only one parameter, full schema coverage, no output schema, and annotations carrying the safety profile, the description fills the remaining gaps by enumerating the returned fields and setting expectations about what the record is not. Nothing needed to call it correctly 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 100% and the single 'model' parameter is documented in the schema as the attribution from the models tool (starting with 'llm-'). The description adds nothing about the parameter, so the baseline of 3 for high schema coverage applies.

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 resource (one trading model's record) and enumerates exactly what it contains: realized PnL, max drawdown, win rate, per market, and the window. It also explicitly differentiates from siblings by stating it is neither a forecast nor a follower's simulated return, which is the distinction an agent needs against forecast/follow_quote.

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 gives clear context via exclusion: 'Always say what the record is not: a forecast, or what a follower would have made,' which implicitly routes the agent to the forecast and follower tools for those questions. It stops short of naming the alternative tools or stating a positive when-to-use trigger, so it is clear but not fully explicit.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is lower. The description still adds real context beyond them: status is derived from the last trade, all data comes from the venue rather than a model's self-report, and simulated market-maker/flow actors are excluded from the listing.

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?

A single sentence that front-loads the resource (trading LLM models on the Taifoon venue) and then enumerates returned fields and exclusions without filler. The embedded clause 'a trader can study and, on the max plan, follow' is slightly awkward and only marginally 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?

With no parameters, no output schema, and safety annotations already present, the description carries the remaining burden and does so: it says what is listed, which fields are derived and how, and what is filtered out. Pagination and plan-gating of the listing itself remain unaddressed.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No misleading parameter claims are made.

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+resource: listing trading LLM models on the Taifoon venue, with the exact fields returned (status, markets, fills, realized PnL, win rate). It does not, however, differentiate itself from close siblings like model_record or catalogue, so an agent must infer which one to pick.

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 only implied: a trader 'can study and, on the max plan, follow' these models, which hints this is the survey/list step before acting. There is no explicit when-to-use, no when-not-to-use, and no named alternative (e.g. model_record for a single model).

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, destructiveHint=false and openWorldHint=true, so the description is not the sole safety signal. It still adds real value by disclosing the data source (live chain read), the devnet-vs-mainnet distinction, and the balance decomposition (total/free/margin) plus governance fields. It does not explain why idempotentHint is false despite being a read, which is the one loose end.

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?

A single sentence that front-loads the resource and source ('the caller's trading vaults, read from the chain') before enumerating contents. The trailing field list is dense but each item carries information about the return shape; nothing is redundant with the 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?

With no output schema and no parameters, the description carries the entire return-value burden and does so credibly by naming the fields an agent will receive. It stops short of explaining the 'mandate' concept or any empty/error state, but for a read-only zero-arg tool this is close to sufficient.

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 tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The schema is closed (additionalProperties=false) and empty, consistent with the description's implicit 'no arguments needed' framing.

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 and resource ('The caller's trading vaults, read from the chain') and scopes it to the caller, which separates it from the generic 'account' sibling. It does not explicitly contrast itself with the related 'vault_prepare' sibling, so an agent must infer that this one reads rather than mutates.

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 only implied: the enumeration of returned fields (free balance, margin, mandate, administrator) tells an agent this is the tool for inspecting vault state. There is no explicit when-to-use statement and no routing away from 'vault_prepare' or 'account', leaving the choice 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true; the description is consistent and adds what is actually read (gas, USDG balance, accounts, the factory's invite gate) and the status vocabulary of the path (done, next, later, blocked). With no output schema, this disclosure of return content matters, though it stops short of stating latency, caching, or what a blocked reason looks like.

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?

Only two sentences and the purpose is front-loaded before the routing and path detail, with no filler. The first sentence is a dense run-on with nested parentheticals that takes effort to parse, which keeps it from a 5.

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 no output schema, the description carries the return-value burden and does so: it enumerates the on-chain facts reported, the single next step, and the eight-step path with its status values and path.next_step. Combined with 100% parameter coverage and read-only annotations, an agent has everything needed to call it correctly on the first try.

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 100% with two parameters fully documented in the schema, including the enum meanings for chain (4663 real money vs 36927 devnet) and the default for owner. The description adds essentially nothing about either parameter beyond implying the principal-linked wallet, so the baseline of 3 applies.

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 and resource: reads on-chain state for a wallet's progress toward a funded vault, returning both the current standing (gas, USDG, accounts, invite gate) and the single recommended next step plus a full eight-step path. It distinguishes itself from siblings by naming the tools it routes to (vault_prepare, fund_with_card) rather than merely restating its 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?

"Call it first, and again after every step the trader signs" gives an explicit invocation cadence, and the description explains that the tool itself selects among alternatives (connect, add gas, vault_prepare, fund_with_card, ready), so the agent knows not to guess a sibling. This is direct when-to-use and how-it-relates-to-alternatives 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?

Goes well beyond the annotations: message is EIP-191 personal_sign and valid only 10 minutes, the signer is recovered server-side, and refusal cases are enumerated (stale/foreign signature, wallet already used by another principal, public key, already registered on chain). It also discloses the auth requirement ('behind the second factor') and the recovery path for a lost wallet via support, which annotations (readOnly=false, idempotent=true, destructive=false) 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?

Purpose is front-loaded, but the prose is a dense run-on stuffed with parentheticals and internal vocabulary; the refusal list and the current-wallet exception are packed into single sentences that are hard to scan. Most content earns its place, but presentation could be tightened into ordered steps.

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 state-changing, two-phase signing tool with no output schema, the description covers the handshake, the returned must_sign/current_wallet signal, failure modes and auth. The only real gap is what the second call returns on success and whether the link is reversible.

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 100%, so the baseline is 3; the description earns above that by tying parameters into a sequence — signed_at comes from the first call, signature_hex must cover that message, and current_signature_hex is only required when must_sign said so. It clarifies the dependency between parameters that the flat schema cannot express.

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+resource: make a wallet the venue's payout wallet for a principal, and even pins its place in a flow ('S1 step 4'). An agent can tell it is a linking/registration action, though jargon like 'the deck's house wallet' and 'the identity door' adds decoding cost and no sibling is named for contrast.

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 two-call protocol is spelled out: call with no arguments to get the message and signed_at, then call again with wallet_hex, signed_at and signature_hex. It also names the conditional path (when the first call returns must_sign, the current wallet co-signs and you pass current_signature_hex). No explicit when-not or alternative sibling is given.

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?

The description adds real behavioral context beyond the annotations: it verifies the transfer to the treasury itself, opens the plan for 'this principal', restricts claiming to the paying wallet, and requires a Cubicle key. Idempotency and open-world nature are already covered by annotations, so this is additive rather than redundant.

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 front-loads the action and follows with the required inputs and constraints in densely packed but purposeful sentences. Slightly long and parenthetical-heavy, but every clause carries operational value.

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 mutating claim operation with no output schema, the description covers the prerequisites (payment, signature, key), the validation model, and the resulting state change ('opens the plan for this principal'). What the call returns is not described, but that is a minor gap for a claim 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 coverage is 100% (baseline 3), and the description goes further by specifying the exact signed message format ('Cubicle plan claim\nagent: <id>\ntx: <tx hash>'), which is essential for producing a valid payer_signature_hex and is not in the schema. The chain constraint is already in the enum, so no extra credit there.

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 and resource ('Claim a plan you paid for on chain') and describes the exact mechanism (tx hash + payer signature). It implicitly distinguishes itself from the sibling 'plans' tool by referencing the message that tool returns, so an agent can tell claim apart from listing plans.

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 makes clear this is the post-payment claim step and points to the 'plans' tool as the source of the exact message to sign. It also gives a hard precondition ('only the wallet that paid can claim it') and an auth requirement ('Needs your Cubicle key'), though it never states an explicit when-not-to-use case.

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 establish readOnly/idempotent/non-destructive, and the description adds meaningful behavioral context: it does not move money, the trader signs in their own wallet, renewal is every 30 days, and the wallet authorization is per-wallet. It still omits what the response looks like and any rate/availability caveats beyond the 'when live' condition.

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?

Content is front-loaded (plans and pricing first, then payment mechanics, then the safety note) with no filler sentences. It is a single dense sentence that is slightly hard to parse due to em-dash interjections, but every clause carries 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?

With no output schema, the description carries the return burden and does describe the content returned (pricing, inclusions, treasury, token, transactions). Both parameters are optional read-only inputs with full schema coverage, so little else is needed; only the concrete response shape is left implicit.

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 100%, so the schema already documents both the plan enum and the wallet address. The description mirrors this (plan pricing, wallet needed for the renewing subscription authorized for that wallet only) without adding format or usage detail beyond the schema, so baseline 3 applies.

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 identifies the resource returned (plan pricing per 30 days, inclusions, treasury/token, and the approve/subscribe steps), so an agent understands what it will get. It is less explicit about the verb (read vs prepare) and does not distinguish itself from siblings like plan_claim, catalogue, or vault_prepare.

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 (pick a plan and wallet to obtain payment steps, when the subscription vault is live) but there is no explicit 'use this when / not when' guidance and no named alternative among siblings. An agent must infer when to call plans versus plan_claim or vault_prepare.

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 read-only, non-destructive, open-world behavior, and the description adds real value on top: no key or sign-in required, a staleness flag is returned, and the tape is the same one vaults validate orders against. It does not define what 'stale' means or any rate limits, which keeps it short of a 5.

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 dense sentences with the key differentiator ('FREE, no key, no sign-in') front-loaded, immediately followed by capability and then the routing hint. No 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?

For a one-parameter read tool with no output schema, the description supplies everything needed: what is returned (price, close time, stale indicator), the market set, and the alternative for candle windows. Nothing material 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 coverage is 100% and the single parameter is an enum with a description, so the schema already carries the semantics. The description restates the allowed tickers (NQ, ES, YM, BTC, ETH, SOL) but adds no format or edge-case detail beyond the enum itself — baseline 3.

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 and resource — the tape's latest price for one market — and specifies the returned pieces (1-minute close time, staleness). It explicitly distinguishes itself from the sibling tape tool, so an agent can tell them apart without opening either schema.

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?

Names the triggering condition ('whenever an agent needs a current price') and the alternative with its constraint ('for a window of candles use tape (needs a key)'). Both when-to-use and when-to-use-something-else are explicit.

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 declare readOnlyHint=false, meaning this is not a pure read operation. The description does not explain what side effects occur (e.g., whether a rehearsal record is written, what state changes), nor does it cover auth needs or rate limits. It only describes the computation and default net-of-fees/last-week behavior.

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 front-loaded with the main action and packs useful details (fees, outputs, usage, caution) into three sentences. It is dense but not wasteful.

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?

It covers purpose, usage, expected outputs (trade count, R, random null comparison), and a caution about interpretation. Missing only behavioral side effects and any auth/rate-limit context, given no output schema and non-read-only annotation.

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 100%, so both parameters are already documented in the schema. The description adds only the default time range ('the last week by default'), which is not a parameter but contextual behavior. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (Run) and resource (forged cubicle.script over the real tape with the reference runner), and lists outputs. It does not explicitly distinguish this tool from the sibling 'script_rehearse' or 'script_validate', which likely have overlapping 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 gives a clear when-to-use condition: 'Call it after a forge when the trader wants to know whether the rule actually fires.' It also includes a caution ('never a forecast'), but does not name alternatives or exclusion conditions.

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 readOnly/idempotent/non-destructive/false-openWorld, so the safety profile is covered. The description does add UI-level behavior beyond the annotations — a studio card is created, pressing it opens the chart held at the focus moment, with a way back — plus a semantic caveat ('a replay shows what printed, never a forecast') and the 10-minute-to-30-day window bound. That is real added context, but it omits things an agent may need, such as whether the card persists or replaces an existing one, or what happens if the studio is already showing something.

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?

Roughly 85 words for a six-parameter tool is proportionate, and the core action is front-loaded in the first clause. The prose is metaphor-heavy ('time compressor', 'held and ready to play') and packed into one unbroken block, costing a little density without wasting whole sentences.

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 safety annotations covering the read-only profile and no output schema to explain, the description carries what remains: what the tool does, where the result appears, eligibility bounds, and the no-forecast caveat. It is close to complete, missing only card lifecycle details and any mention of how the card is referenced later (e.g. by note or by window).

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 100%, so the baseline is 3, but the description goes beyond it: it interprets 'focus' as the moment to hold on 'a trade, a sweep, a touch of a level' and ties 'speed' to the play-back rate, both of which give the enum and ISO fields practical meaning the schema alone does not. The note parameter is not mentioned in prose, and the from/to constraints are only implied by the ten-minute-to-thirty-day rule.

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?

'Put the trader's chart and its time compressor on a past window' names a specific verb and resource, and the card/chart-opens behavior makes the effect concrete. It is distinguishable from siblings like chart_state or image, but it never contrasts itself with near-neighbors such as replay_record or rehearse, so an agent must infer which replay-family tool to pick.

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 an explicit trigger: 'Use it whenever you talk about what happened in a window: show it on the chart instead of only describing it.' It also supplies hard eligibility bounds ('Past windows only, ten minutes to thirty days'). It stops short of naming an alternative when a user wants a static image or a rehearsed sequence instead.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real context by noting the returned hash is identical at any replay speed and by enumerating the recorded contents. It does not discuss volume, ordering guarantees, or failure modes when no replay exists.

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 sentences, front-loaded with the verb and scope, then the usage cue. The content list is dense but each element earns its place; no 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?

There is no output schema, so the description carries the burden of describing return values, and it does so by enumerating the record types plus the recording hash. Adequate for a read tool with fully documented parameters, though it omits result size/format expectations.

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 100%, so both parameters are documented in the schema; the description's enumeration of tape/strategy/user/move content loosely corresponds to the 'kinds' filter but never maps to the enum tokens (slot, fire, gate, veto, nearmiss, settle). Baseline 3 applies.

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 back) and a precisely scoped resource (the trader's last replay of ONE market), then enumerates exactly what is returned: tape beats, strategy trades/state changes, and user moves. It is clearly distinguishable from sibling replay_open, which it names as the prior step.

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?

Gives explicit triggers: 'Use it after replay_open, or when the trader asks what they just watched', and frames the goal as answering from the recording rather than memory. It names the sequencing dependency but does not state when NOT to use it or an alternative read path.

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 cover the safety profile (read-only, idempotent, non-destructive, closed-world), and the description adds meaningful behavioral context beyond them: Pine is read statically and never run, findings are graded observation/inference/unknown with ids, and inferences must never be presented as fact. This is genuine added value, though return-format detail is somewhat entangled with what a schema would normally carry.

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?

Front-loads the core purpose well, but the long run-on sentence packing the dossier contents (route, findings, checklist items, ceiling) is dense and could be broken into a short structured list. Every element is informative, yet the presentation is heavier than it needs to be.

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 no output schema, the description carries the full burden of explaining what comes back, and it does so in detail (route, graded findings with ids, checklist states, ceiling). Only minor gaps remain around edge cases and how ambiguous input is handled, but the tool is well-covered overall.

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?

Only one parameter with 100% schema description coverage, so the schema already documents it fully. The description restates the accepted content types ('the rule, the Pine source or the transcript'), which matches rather than extends the schema's own wording. Baseline 3 is appropriate.

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?

Names a specific verb (reverse-engineer) and resource (what the trader POSTED), and enumerates the accepted inputs: a rule in words, a pasted Pine script, or a chat transcript. It clearly distinguishes itself from siblings by routing charts to the image tool, so an agent can tell what this tool is for without opening the schema.

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?

States the input conditions for use (rule / Pine source / transcript) and gives a concrete routing rule: 'For an attached chart use the image tool first.' It stops short of naming the alternative analysis tools or saying when NOT to use it, but the context is clear and actionable.

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 read-only, idempotent, non-destructive behavior, but the description adds valuable details beyond them: deterministic hashing with caching, metering on the run rather than the bars, per-market default windows, and a 6,000-bar cap. It does not contradict annotations and adds meaningful operational context.

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 dense but front-loads the core operation and avoids filler. It is a single long paragraph rather than structured sections, but every sentence carries operational information relevant to invoking the tool.

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 9-parameter rehearsal tool with no output schema, the description explains the returned frames and summary in enough detail, along with determinism and default windows. It does not cover error behavior or validation failure modes, but it is otherwise complete enough for correct invocation.

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 100%, so the baseline is 3, but the description adds cross-parameter meaning: window defaults differ for NQ/ES vs crypto, `hours` is crypto-only, `frames` returns from the end with a max of 600, `params` replaces defaults within min..max and changes the hash, and `script` vs `example` are mutually alternative inputs.

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 and resource: 'Step a cubicle.script v1 over the deck's own bars with the deterministic reference runner.' It is clearly a rehearsal/backtest operation, but it does not explicitly contrast itself with siblings like script_validate or replay_open, so sibling differentiation is only implicit.

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 operational context such as passing a script or a bundled example and the default windows per market, but it never states when to use this tool versus alternatives. Usage is implied by the 'rehearse' framing rather than explicitly guided.

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 establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description adds real substance: the return is a JSON report with diagnostic codes C000–C095 located by file:line:col plus a budget (warm-up bars, memory, nodes per bar). That is exactly the behavioral/output context annotations cannot convey.

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?

One front-loaded sentence: verb+resource first, then output contract, then the safety/cost note. Every clause carries information; nothing is padding.

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?

No output schema exists, and the description compensates by enumerating what the report contains (diagnostic code range, file:line:col, budget metrics). For a single-parameter, read-only validation tool, nothing an agent needs 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 coverage is 100% and the single parameter is fully described there; the description's 'the cubicle.script v1 (the YAML text)' merely restates it. Nothing is added about format edge cases, size limits, or encoding, so the baseline 3 applies.

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?

Specific verb (validate) + specific resource (cubicle.script v1 YAML text) plus the validator it uses ('the reference validator'). 'Nothing runs' implicitly separates it from execution-oriented siblings such as script_rehearse or replay_record, so an agent can route correctly without opening the schema.

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?

'Nothing runs. Free.' gives clear context that this is a safe, cost-free pre-check to prefer before anything that executes or simulates. It stops short of explicitly naming the alternative (script_rehearse) or when-not to use it, so no exclusions are stated.

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 readOnly/idempotent/non-destructive/closed-world, so the safety bar is low. The description adds genuinely useful context beyond that: what the output means (full vs reduced size), that it is a house-model output cross-checked against a rule in code, and that it is sizing-only. It omits any caveats about staleness or caching, but the added behavioral context is solid.

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 purpose is front-loaded, but the parenthetical model-provenance chain ('trained by the 120B, distilled to the 4B, promoted because it matched the clean room's PROVEN rule on unseen weeks') is internal jargon that consumes a large share of the text without helping an agent invoke the tool. Trimming it would sharpen the definition.

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 one-parameter, read-only, idempotent tool with full schema coverage and annotations, the description supplies the key missing piece: what the returned size value signifies (full vs reduced) and that it is sizing-only. No output schema exists, yet the description covers the return semantics adequately; only minor caveats are absent.

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 100% with a single enum parameter whose default ('all three') is documented in the schema, so the schema does the heavy lifting. The description restates the BTC/ETH/SOL scope but adds no syntax, format, or selection nuance beyond what the schema already provides. Baseline 3 is appropriate.

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 concrete resource (trade size for the crypto session open now) scoped to BTC/ETH/SOL, and explicitly carves out its role as 'a sizing input only, never a direction', which distinguishes it from direction-oriented siblings like forecast. The verb is implicit ('how big to trade') rather than a clean action verb, but an agent can tell what it returns.

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 implies usage by contrasting sizing vs direction, and explains the two output regimes (full size when vol is high, reduced when quiet), which helps interpret results. However, it never states when to call this tool versus alternatives, nor any prerequisites or timing constraints.

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 cover the safe-read profile (readOnly, idempotent, non-destructive). The description adds real behavioral context beyond that: a whole class of skills is sealed and requests will be refused, which is a failure mode the agent must anticipate.

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?

One sentence, front-loaded with the core action, and the refusal caveat packed into the trailing clause. No waste.

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 single-parameter read tool with no output schema, the description covers the action and the key error case well. It does not hint at the shape of the returned SKILL.md content, a minor gap only.

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 100% and there is only one parameter ('name'), whose schema description already says it is the name as listed by the skills tool. The description adds no syntax, format, or naming detail beyond that, so baseline 3 applies.

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) and resource (one skill's method / SKILL.md), plus scope. It distinguishes this from the sibling 'skills' tool by clarifying it fetches a single skill's content rather than listing skills.

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?

Explicitly states when-not: strategy, lens, pillar and copy skills are sealed and will be refused, so the agent knows which names to avoid. It does not name an alternative tool to use for those sealed skills, which keeps it from a 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 establish read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine value beyond them by decoding the status vocabulary (runnable / stub / concluded) and warning that a stub is a promise rather than a capability — a real risk-of-misinterpretation note.

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 with what is listed and followed by the one caveat that matters. No filler or restatement of the tool name.

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?

Zero-parameter read tool with no output schema, and the description still tells the agent what the payload contains and how to interpret status values. Only the absence of any ordering or size expectation for the bank listing keeps it short of full completeness.

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 tool takes zero parameters, so there is nothing to document and the baseline is 4. The description usefully names the fields the bank returns, which is a small bonus over the empty schema.

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?

Specific verb (List) plus resource (the Cubicle skill bank) and an explicit enumeration of the returned fields (name, family, grade, status). The scope — the whole bank rather than one entry — cleanly separates it from the sibling skill_read.

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 only implied: an agent can infer it should call this to survey the catalogue. The description never names skill_read as the alternative for fetching a single skill, nor states when the bank listing is preferable to reading one entry. The stub caveat is guidance about citing results, not about tool selection.

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 only cover the basic safety profile, and the description adds substantial context the annotations cannot: the five-minute TTL, the required header name and target endpoint, the 2FA/unlocked/agents-allowed preconditions, and the consequence that a key without a second factor cannot withdraw at all. It leaves the response shape and re-mint behavior implied rather than stated.

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 dense sentences, front-loaded with what the token is and where it goes. The URL restatement (api.taifoon.dev/vault/withdraw) is mildly redundant with the POST /vault/withdraw path and makes the second clause feel run-on.

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 no parameters and no output schema, the description covers purpose, invocation, and eligibility gating, which is what an agent needs to call it correctly. It stops short of stating what the call returns (an opaque token string) or whether repeated calls mint separate tokens, though idempotentHint=false implies that.

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?

Zero parameters, so there is no parameter semantics to clarify; baseline 4 applies. The description appropriately spends its words on preconditions and embedding instructions instead of inventing parameter detail.

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 concrete artifact (a five-minute proof of second-factor passage), its scope (venue vault / withdrawal), and the exact verb-resource pairing. An agent can distinguish this from siblings like vault_prepare or my_vaults without opening any schema.

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?

Gives explicit invocation context (send as the x-step-up header of POST /vault/withdraw) plus the preconditions under which it can be minted: second factor configured, account unlocked, agents allowed. It does not name a sibling alternative or an explicit when-not path, so it falls short of a 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 declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes beyond them with genuinely useful behavioural context: strategies are 'not live with real funds yet', and the vault itself enforces limits — both of which materially change how an agent should treat the output.

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?

A single front-loaded sentence that opens with the resource and then lists its facets in a parenthetical. Dense but zero filler; the nested clauses make it slightly harder to scan than a two-sentence split would be.

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 no input schema and no output schema, the description must describe the return payload itself, and it does so by enumerating what each strategy entry covers, plus the honest-status caveat. Adequate for a read-only reference tool, though it never states the shape or volume of the result.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param tool applies. The description correctly focuses on payload content rather than inputs.

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 concrete resource and scope: the set of strategies rentable to run a Cubicle spot vault, and enumerates the content returned (parameters, venues, assets, limits, fee, rental path, status). It does not, however, distinguish itself from near-neighbours like 'catalogue', 'plans', or 'strategy_quote', so the agent must infer the boundary.

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 only implied: the mention of 'how to rent it' suggests this is the discovery step before renting, but there is no explicit when-to-use, no when-not, and no pointer to strategy_quote/plans/my_vaults as the alternatives for pricing or managing a position.

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 cover readOnly/openWorld/idempotent, but the description adds real context: 'A static call: nothing is signed or sent' and the concrete acceptance behavior (at most 1% worse than the tape). It also implies freshness ('right now'), consistent with the non-idempotent hint. Missing only things like rate limits or failure modes.

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?

Purpose is front-loaded in the opening clause, and the short final sentence cleanly covers the safety trait. The first sentence is dense with a colon-separated return list, but each element carries meaning; slightly heavy for a two-parameter tool.

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 no output schema, the description responsibly describes what the quote returns and the vault's 1% acceptance rule, which is the key decision context. It is close to complete; only quote validity/expiry and any access constraints are unaddressed.

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 100%, and the schema already documents both parameters including the ETH/BTC enum and the USDG denomination, so the baseline is 3. The description restates the USDG spend and asset choices but adds no format, bounds, or minimum/maximum detail beyond the schema.

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 ('A live quote for one accumulate buy') and pins the scope to Robinhood Chain, ETH/BTC via Uniswap. It also enumerates the actual outputs (fill amount, tape price, cost in bps, vault price-rule verdict), so an agent can distinguish it from follow_quote or tape without opening a schema.

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 conveys implied usage (pre-buy pricing check for a single accumulate order) and clarifies the call is static and safe, but never states when to prefer it over siblings like follow_quote or tape, nor any prerequisites or exclusions. Usage is inferable rather than spelled out.

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 cover safety (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description adds real context beyond that: the data is bounded to past bars of one tested week, defaults to the newest test, and is explicitly 'a description, never a forecast and never advice'. This scope and framing are genuinely useful and not in the 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 core purpose is front-loaded in the first sentence, but the run-on phrasing ('the move (ready to in a trade, and so on)') and a list-heavy middle sentence make it dense and slightly awkward. It conveys the information without much waste, but it is not tightly structured.

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 no output schema, the description must convey what is returned, and it does so thoroughly, including the win/loss-entry averages per watched item. A read-only tool with full annotation coverage does not need more, though the return-value enumeration could be more crisply organized.

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?

Both parameters are fully documented in the schema (100% coverage) with enums and defaults. The description adds nothing beyond that—the market default is already stated in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 identifies the resource: the steps the trader's last tested strategy took on one market, enumerating its returned fields (time, move, conditions, trade, watched-item values). This is specific enough to distinguish it from list-style siblings like strategies or quote-style siblings like strategy_quote. It stops short of naming an alternative sibling explicitly.

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 gives concrete usage contexts with example questions ('what was the RSI when it bought', 'why did it enter there', 'what do the winners have in common'), which tells the agent when to reach for it. There is no explicit when-not guidance or named alternative tool, so it does not reach a 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?

With annotations already declaring idempotentHint=true and destructiveHint=false, the description adds real context: the secret never leaves the machine, keys are sealed per UTC day, non-key holders see ciphertext, and re-calling re-sends today's keys. It does not spell out auth requirements or whether 'forget' is reversible, but it goes well beyond the annotation set. Minor tension exists between destructiveHint=false and 'forget (remove your key)', but re-registration is possible, so it is not a hard contradiction.

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?

One front-loaded sentence establishes what the tool is, followed by the required input, then the outputs and the re-call/forget behavior. It is dense with pricing tiers and SDK jargon, but every clause carries information and nothing is padded.

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 no output schema and no required parameters, the description correctly fills the gap by naming the return values (holder id, stream URL, decode command) and the state-changing behavior of re-calls and forget. Combined with annotations covering idempotency and safety, an agent has enough to invoke it correctly; only auth/permission prerequisites are omitted.

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 100%, so the baseline is 3, but the description adds meaning the schema does not: that 'x25519' is a public key whose private counterpart is generated locally via the SDK keygen command, and that register refreshes an existing registration. The action semantics (register/status/forget) are reinforced rather than merely restated.

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 and resource: registering an X25519 public key to receive a paid, daily-sealed signal stream, with concrete outputs (holder id, stream URL, decode command). The purpose is unambiguous, though it is embedded in a dense, jargon-heavy sentence and never explicitly contrasts itself with siblings like watch_set or follow.

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 gives mode-level guidance ('Register...', 'Call again to have today's keys re-sent', 'action forget stops it') that mirrors the register/status/forget enum, so the when-to-use for each action is implied. There is no explicit statement of when NOT to use this tool or which sibling to pick instead, so guidance stops at implied usage.

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 destructive=true and readOnly=false, but the description adds non-obvious behavior: score_parts requires the trader's TypeSafe key, accept_parts skips Jev scoring, choose_coverage depends on measurable gates, and the tool only executes the chosen move without deciding gates. It omits failure modes and reversibility details.

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?

One dense sentence followed by a semicolon-delimited guidance clause. It is front-loaded with the action and maps each enum option, though the jargon is heavy and the structure is compressed.

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?

Covers the trigger, all move options, the conditional choice parameter, consent requirements, and the tool's limited role in the state machine. For a no-output-schema mutation tool with annotations, this is nearly sufficient, though it omits post-move result or failure behavior.

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 100%, but the schema descriptions are minimal. The description supplies meaning for each move enum value, including the conditional choice for choose_coverage, materially improving correct parameter selection.

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 and resource: moving the trader's rule through the studio's state machine. The trigger 'when forge is refused' and enumeration of the four moves distinguish it from the sibling forge tool.

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?

Explicitly conditions use on forge being refused and instructs the agent to ask the trader before accepting or choosing on their behalf. It also maps each move option, giving clear routing 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 readOnly/idempotent/non-destructive, and the description goes well beyond them: NQ has a weekend halt and a 21:00 UTC daily break, past windows are SEALED and therefore cacheable, and the same data is served keyless over HTTP. The note that this is the tape the conformance check replays is a genuinely non-obvious behavioral guarantee.

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?

Scope and the use/don't-use rule are front-loaded, and the sentence about sealed windows is high-value. The HTTP mirror paragraph with OpenAPI link and User-Agent instruction is arguably adjacent to invoking this MCP tool and costs some density, though it does earn its place as an auth-free fallback.

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?

Covers the tricky parts an agent needs — market break schedule, immutability/caching, and authoritative-source guarantee — for a 4-param required-everything read tool. The one gap is that with no output schema, the description never says what a bar actually contains (OHLCV fields, ordering, gaps at breaks).

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 100% with enums for market and tf, so baseline is 3. The description adds real value on top: it stresses the window must be in the past, and it clarifies the format split (MCP takes ISO-8601 while the HTTP mirror takes unix SECONDS), which is precisely the kind of mistake an agent would otherwise make.

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?

Opening sentence states a specific verb and resource — 'Read real candles from the Taifoon tape for one market' — and the 'never to predict' clause implicitly separates it from forecast-style siblings like forecast or plan_claim. It never names an actual sibling, so an agent still has to infer which of the ~48 tools is the alternative read path.

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?

Gives a clear intended use ('ground an answer in what the market actually did in a past window') plus an explicit exclusion ('never to predict'), which is exactly the routing signal an agent needs. It does not say what to do when the window is in the future or which sibling serves live/current data instead.

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 idempotent=true and destructiveHint=false, but the description adds real substance beyond them: the follow record is 'marked stopped and kept' rather than deleted, and 'open mirror positions stay yours to manage' clarifies downstream side effects. It also states the return value ('the stopped record, or says there was none'), covering the no-op case.

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?

A single tight sentence with the action front-loaded and the side effects and return value following in order of importance. Minor ambiguity in 'at once' (immediately vs. simultaneously), but no wasted text.

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 one-parameter mutation tool with no output schema, the description supplies what the structured fields can't: the soft-delete semantics, the untouched mirror positions, and the return value including the none case. Annotations cover the safety profile, so nothing an agent needs 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?

Only one parameter ('model'), and schema description coverage is 100%, so the schema already documents it as 'the model's attribution'. The description adds nothing about the parameter format or identifiers beyond the schema. Baseline 3 applies when the schema carries the load.

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+resource ('Stop following a model') and immediately scopes it with the eligibility clause 'any tier may stop'. The inverse relationship to the sibling 'follow'/'follows' is obvious, though no sibling is named explicitly to rule out confusion with 'follow_quote' or 'replay_open'.

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?

'Any tier may stop' is a genuine eligibility/prerequisite disclosure that tells the agent who can invoke it, and the use case (stop an active follow) is clear from the verb. It stops short of naming an alternative tool or a when-not condition, so it doesn't reach the top band.

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?

Adds real context beyond the annotations: 'Signs and sends nothing' resolves what readOnlyHint=false actually means here, and the chain note discloses that 4663 uses real USDG, has no deposit cap, and runs on unaudited contracts — material risk information no structured field carries. It stops short of describing what the returned transaction/typed-data payload looks like or what happens if a later-step parameter is supplied on the first call.

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?

Front-loaded with purpose, then phase instructions, then the risk note last — a sensible ordering. The chain parenthetical is dense and carries two ideas (money realness and audit status) in one clause, but every sentence contributes information an agent needs.

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 12-parameter, multi-phase tool with no output schema, the description covers the state machine, the prerequisite read (my_vaults), and the safety posture well. It does not say what the unsigned transaction and typed-data objects look like or whether the call can be safely repeated after partial signing, which are the remaining gaps.

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 100%, so baseline would be 3, but the description adds phase semantics the schema cannot express — 'call without vault' for the first phase, 'call again with the new vault's address' for the second, and the queue-then-claim ordering for withdraw_shares/claim_shares. It also reinforces the 4663 real-money vs 36927 devnet split that governs the chain parameter.

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 and resource — produces the wallet steps for a Cubicle vault as unsigned transactions plus EIP-712 typed data for the owner's wallet — and immediately breaks that into the three concrete verbs (open, fund/hire, withdraw). This clearly separates it from my_vaults (read) and operator_link, which an agent could otherwise confuse it with.

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?

Explicitly routes by state: 'Open: call without vault', 'Fund and hire: call again with the new vault's address (from my_vaults)', 'Withdraw: withdraw_shares queues shares, then claim_shares pays'. It names the sibling to read first (my_vaults) and the required ordering of the withdrawal pair, leaving nothing 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral content beyond that: what is reported at every strategy step, how the vocabulary is grouped, and that items can be expressions like 'rsi14 > 50' rather than literal fields only.

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 scoping statement and the watch_set relationship are front-loaded, and the indicator/field enumeration earns its place for a discovery tool. The middle sentence is dense and parenthetical-heavy, which costs it a point but does not bury the key point.

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 no output schema, the description carries the burden of explaining what comes back, and it does reasonably well: indicator groups, example field names, and expression items. It does not describe the actual response shape or ordering, which keeps it from a 5 for a discovery 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 tool takes zero parameters, and the schema correctly declares an empty object. With no parameters to document, the baseline of 4 applies; there is no parameter semantics work for the description to do.

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 what the tool surfaces: the trader's current watch list plus the full vocabulary of trackable fields, grouped by indicator, including field names and expression support. It is clearly distinguishable from watch_set, but it opens with a noun phrase ('What a strategy test reports...') rather than a crisp verb, so the action itself must be inferred.

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 a sibling and a sequencing rule: 'Call it before watch_set, and when the trader asks what can be tracked.' That gives two concrete invocation contexts. There is no explicit when-not guidance, so it stops short of a 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 only flag it as a non-read-only, idempotent, non-destructive mutation, but the description adds real behavioral context: it replaces the existing list, its effect is deferred to the NEXT test, and validation is partial ('an item that cannot be read is refused by name and the rest are kept'). That refusal-by-name semantics is exactly the kind of state detail annotations cannot convey.

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?

Front-loaded with the core action and constraint, and every sentence carries distinct information (format, replacement, timing, failure behavior, usage trigger). It is a dense single block rather than cleanly segmented, but there is no 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?

For a single-parameter mutation tool with no output schema, the description covers what is required: input grammar, replacement semantics, deferred effect on the next test, partial-failure handling, and the routing trigger. Nothing an agent needs to call it correctly 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 coverage is 100% and describes 'items' generically, but the description adds the grammar the schema omits: up to 8 items, each a field id from watch_fields or an expression using numbers, + - * /, brackets, and optionally one comparison (< > <= >=). This is material syntax not present in the schema.

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 (Set) and resource (what the trader's strategy tests report at every step, i.e. the watch list), and specifies the accepted input formats. An agent can distinguish it from watch_fields (which supplies field ids) and rehearse without opening any schema.

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?

Gives a concrete trigger ('Use it when the trader says what they want tracked') with a worked example ('watch the RSI and how far price is from the EMA'), plus the follow-up action (offer to rehearse again) and the field source (watch_fields). No explicit exclusion of alternatives, but the routing context is clear.

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?

Despite annotations covering read-only safety, the description adds substantial behavioral context: the half-hour refresh cadence, the fact that social feeds are explicitly excluded, that tags and tone are computed in code with recency weighting, and the specific efficiency-ratio method for regime detection. This goes well beyond what annotations provide.

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 front-loaded with the core purpose and every clause (methodology, refresh rate, limitations) earns its place, but the first sentence is a dense run-on with multiple nested parentheticals that could be split for easier parsing. Still, it avoids unnecessary repetition.

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 no output schema, the description fully explains the return shape (tone, band, headlines with times/links, regime, sky word) and includes operational context (refresh rate, data sources excluded). Combined with the annotations, an agent has everything needed to call and interpret the tool correctly.

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 100% and the only parameter (`market`) has an enum with a default, but the description adds no additional meaning about the parameter—no explanation of what 'market' represents beyond the enum values or how the default behaves. The schema does the heavy lifting, so the baseline 3 is appropriate.

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 specifies exactly what the tool returns: a recency-weighted tone from 72h of headlines, the headlines themselves, a tape regime from efficiency ratio, and a sky word. It explicitly distinguishes itself from a forecast or trade direction, preventing confusion with siblings like `forecast` or `price`.

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 clearly states when-not to use it: 'A mood, never a forecast or a direction to trade; social feeds are not read.' However, it does not name specific alternatives (e.g., use `tape` for raw price or `forecast` for predictions), leaving the agent to infer which sibling to pick for different needs.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuine behavioral context beyond them: the reader is deterministic, extracts only from the trader's own words, and outputs which required parts are missing, plus an explicit constraint not to invent parts.

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 front-loaded sentences with no filler; the purpose and output shape come first, then the usage directive. The 'way the studio does' framing and parenthetical seven-part list cost some space but carry real 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?

There is no output schema, so the description correctly carries the burden of describing the return: the filled 7 parts and the list of missing required parts. It is nearly complete, though it doesn't specify the exact output shape beyond the part names.

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?

With one parameter and 100% schema description coverage, the schema already defines the input fully. The description reinforces 'the trader's OWN words' but adds no syntax, format, or bounds beyond what the schema's 'in their words' already states.

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 ('read') and resource ('a trading idea'), and enumerates exactly what the deterministic reader produces: the 7 named parts plus a report of missing required parts. This distinguishes it from the sibling 'forge', which the description positions as the downstream step.

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 gives an explicit trigger ('Use it before restating or forging a rule') and names the alternative workflow ('forging'), which gives the agent a routing signal. It stops short of full when/when-not coverage, giving no conditions under which this should be skipped or is inapplicable.

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