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 safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial extra context: the render uses the same geometry as the screen, the envelope cone appears only when calibration permits, output is PNG plus JSON, windows must be in the past, and there is a 600-bar cap. These are real behavioral traits beyond 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?

Three sentences, front-loaded with the core purpose, and every sentence carries information (what is rendered, how to treat the outputs, the limits). The middle sentences are dense but not redundant; 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 correctly takes on the burden of explaining returns — it specifies a PNG plus chart_state JSON and warns how to interpret each. It also covers the window and bar-count constraints, so an agent has everything needed to call it 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%, so the baseline is 3, but the description adds meaning the schema lacks — a 600-bar ceiling on the from/to window, the 'past windows only' constraint, and the note that the indicators selection controls whether the envelope cone is drawn. That extra semantics lifts it above the baseline.

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 (server-side render) and resource (a chart plate for one market/timeframe/window), and names exactly what is produced: a PNG plus the chart_state JSON. It implicitly differentiates itself from the chart_state sibling by declaring it returns both the picture and that JSON, so the agent knows what it is getting 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 and constraints — 'Past windows only; at most 600 bars' and the rule to quote numbers from the JSON rather than the image. It does not explicitly say when to prefer chart_state or the image sibling over this tool, so there is no full when/when-not routing, but the operating conditions are well 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 profile is covered. The description adds behavior annotations do not: results are computed in code rather than read from pixels, only past windows are valid, and there is a hard 600-bar cap. It does not cover error behavior or latency.

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 body is one long run-on sentence with nested parentheticals, e.g. '(theirs — they may be used as levels the trader gave)', which is hard to parse and obscures the return shape. Information density is high but structure is poor.

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 the return payload, and it does enumerate the returned sections (bars, indicators, marked levels/zones, envelope with draw gate, fact sheet). Coverage is good; minor ambiguity in the levels/zones parenthetical and no error/empty-window behavior keeps it from 5.

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 all five parameters are already documented (including defaults for indicators and the past-only constraint on 'to'). The description echoes those constraints ('indicators drawn', 'Past windows only') but adds little new syntax or semantics, so baseline 3 is correct.

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+scope: what the chart would show for one market/timeframe/window, returned as a computed JSON object. It explicitly contrasts with the pixel-reading sibling ('Use it instead of reading pixels'), so an agent can distinguish chart_state from chart_image 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?

Gives a clear selection rule against the obvious alternative ('instead of reading pixels: every number is measured, not read') and adds operating constraints ('Past windows only; at most 600 bars'). It does not name the alternative tool explicitly or state when-not to use it, so it falls just short of 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 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 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 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 this is a non-destructive mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety profile is covered. The description adds meaningful behavior beyond that: a gated precondition and the fact that a refusal returns the awaited move inside the result, which tells the agent how to handle failure.

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 action and followed by the gating/fallback rule. Dense with jargon, but every clause carries information and 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 mutation tool with no output schema, the description covers the failure path well, but it never explains what READ, CLARIFIED and EXPRESSIBLE are or where an agent verifies them, and it says nothing about what a successful compile yields. An agent can call it but may not know how to reach the prerequisite state.

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?

There is only one parameter and schema coverage is 100%, so the schema already carries 'the rule in the trader's words, every part included'. The description adds nothing about the intent string's expected content or granularity, 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 core action is recoverable — it compiles the trader's strategy — but the phrasing is wrapped in domain jargon ('the studio machine's FORGED move', 'gates the tape can measure') that an agent cannot decode from the text alone. It gives no differentiation from nearby siblings like studio_move, strategies, rehearse or grade, so an agent has to guess where this sits in the workflow.

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 a concrete precondition for success (the strategy must have passed READ, CLARIFIED and EXPRESSIBLE) and prescribes the fallback when refused: report the move the studio is waiting for. That is real when-to-use guidance, though it never names an alternative tool to call instead and leaves the gate names undefined.

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?

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 already declare the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=false). The description adds useful defaults ('the last week by default') and an interpretation caveat ('evidence about the past, never a forecast'), but never explains the non-read-only side effect implied by readOnlyHint=false, leaving a 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?

Three front-loaded sentences with no waste: the first states the action and returns, the second the trigger, the third the interpretive caveat. Every sentence 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 output schema, the description compensates by naming what comes back (trade count, R, null comparison) and the default window. It is nearly complete for a two-parameter tool, missing only an account of the state change implied by its 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% for both parameters, so the schema carries the parameter semantics (market enum, seed_hash provenance). The description only adds the internal 'last week' default, which is not even an exposed parameter, so it does not meaningfully exceed 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 ('walk a forged machine over the real tape') and names the concrete outputs (trade count, R, random-null comparison). It also explicitly distinguishes itself from the sibling forecast tool ('never a forecast') and ties itself to forge, so an agent can tell it apart from neighbours.

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 and sequencing rule: 'Call it after a forge when the trader wants to know whether the rule actually fires.' It contrasts with forecast, but stops short of naming forecast as the alternative to use when a forward-looking answer is wanted.

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 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 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 cover the safety profile, but the description adds substantial context they don't: NQ's non-continuity (weekend halt, 21:00 UTC break), that past windows are SEALED and safe to cache, and the no-key HTTP equivalent with its own parameter conventions. This is exactly the behavioral value structured fields cannot 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-loaded with the core action, then layers constraints, caching guidance, and the HTTP mirror without padding. Dense but every sentence carries information; slightly long for a four-parameter read 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 should hint at return shape; it names 'real candles' and defers detail to the OpenAPI spec link. It covers continuity, sealing, and caching well, but the bar format itself 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 description coverage is 100% and both enums are documented, so the schema does the heavy lifting. The description notes the HTTP variant uses unix SECONDS versus the schema's ISO-8601, which is a useful distinction but not a semantics addition for the MCP parameters themselves.

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 ('Read real candles from the Taifoon tape for one market'), scoping it to a single market and a past window. This cleanly separates it from siblings like chart_image, chart_state, and forecast.

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 when-to-use context ('ground an answer in what the market actually did in a past window') and an explicit exclusion ('never to predict'). It does not name a specific sibling alternative to use instead, so it stops short of the top tier.

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 past the annotations by stating 'Signs and sends nothing' (reinforcing readOnlyHint with concrete meaning) and by disclosing real behavioral risk: chain 4663 uses real USDG, has no deposit cap, and the contracts are not externally audited, so deposits can be lost; 36927 is test money. That is material context an agent cannot get 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?

Dense and front-loaded with the core purpose before the phase-by-phase routing and risk notes. It is efficient with no filler, though the single semicolon-chained block is heavier to parse 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?

For an 11-parameter tool with no output schema, the description supplies what is otherwise missing: the return shape (unsigned transactions plus EIP-712 typed data), the multi-call sequencing, and the chain/risk context. Nothing essential to invoking it correctly is 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% and the parameter descriptions are already rich, so the baseline is 3. The description adds sequencing meaning beyond the schema by clarifying which parameters belong to the open call versus the funding/hiring call and where the vault address comes from (my_vaults).

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 precise verb and resource: it produces the wallet steps for a Cubicle vault as unsigned transactions and EIP-712 typed data. It also names the source of the vault address (my_vaults), which anchors the tool among its siblings. An agent knows this constructs payloads rather than executing anything.

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?

Explicit lifecycle routing: call without `vault` to open, call again with the vault address for allow + deposit and the mandate, and the two-step withdraw path (withdraw_shares queues, claim_shares pays). Both the first-call and second-call conditions are spelled out, leaving little 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 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.