tokenizedblock

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

Goes well beyond the annotations by disclosing that this call signs nothing, that the panel renders the proposal with buttons and the user decides, that `send` requires the user to confirm twice, and that the tool is rate-limited to one command per second. These are meaningful operational facts (confirmation flow, throughput limit, non-committing semantics) that the readOnlyHint/destructiveHint flags alone would not 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 purpose and no filler sentences; the mode enumeration is dense but every element maps to a real parameter/mode. It would be easier to scan as a list rather than one run-on paragraph, which is the only structural weakness.

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 16-parameter, 8-mode tool with no output schema and only 2 required params, the description covers the mode semantics, confirmation flow, and rate limit well. It could say more about what the call returns and how errors (e.g. closed session, rate-limit rejection) surface, which matters given no output schema exists.

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 contributes genuine additional meaning: it lists the concrete brain task ids accepted by `task` (trade_tblock, launch_wake, feed_trusted, …) where the schema description only says 'the brain task id' and enums are absent, and it clarifies amount units per mode plus an example swap (USDC to a tokenized stock). It adds less for parameters already well documented, hence not a 5.

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 first sentence delivers a precise verb+resource ('Proposes one command to an open control panel') and the rest enumerates the eight command types (select/show/trade/swap/send/task/birth/say), so an agent immediately understands the scope of this polymorphic tool. The constraint that the panel must already be open implicitly distinguishes it from session-creation siblings like tblock_panel_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?

Usage is only implied: the description makes clear a session is required and enumerates what each `type` does, which guides selection among modes. However, it never says when to prefer this tool over alternatives such as tblock_plan_swap or tblock_plan_birth, which are listed as siblings and appear thematically overlapping. No explicit when/when-not guidance 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?

Annotations cover readOnlyHint and openWorldHint, so the safety profile is already established; the description adds meaningful behavior beyond that, disclosing that the output is conditionally an unsigned call, that the exit is a two-stage request-then-withdrawal process, that the request halts the share immediately, and that the withdrawal follows after 7 days.

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 that front-loads the read purpose before the conditional exit behavior. Every clause carries information, though the run-on structure and the second half (exit flow detail) make it slightly heavy for one sentence.

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 carry the return burden and does so: it enumerates returned content (who deposited, how much, whether the 0.03% share is flowing) and explains the conditional unsigned call. The main remaining gap is the lack of any explicit note on the sibling tool to use for pure planning/execution.

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 the schema already documents all three parameters, setting a baseline of 3. The description clarifies the special conditional role of `account` (only produces the exit call when it matches the creator), which adds marginal value but 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?

States a specific verb (reads) and resource (creator minimum deposited for a block's market) with concrete scope, and further distinguishes its conditional mode (returns the unsigned exit call when account is the creator). It does not explicitly name or differentiate from sibling tools like tblock_command or tblock_plan_swap, 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?

It implies usage via the conditional 'when `account` is that creator' branch and describes the two-step exit sequence, giving the agent a sense of context. However, it never states when to reach for this tool versus the sibling tblock_plan_* or tblock_command tools, nor any exclusions, so guidance is only implied.

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 and openWorldHint; the description still adds real value by disclosing server endpoints, null cases (pot null if not read; BlockRolls null means practice/free rolls with nothing to sign) and the effect of supplying `wallet`. It stops short of describing response shape or freshness/caching behavior, so it is good but not rich.

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 entire definition is a single sprawling sentence with deeply nested parentheticals, making it hard to parse and locate a given field. The content is largely load-bearing (it substitutes for a missing output schema), but it is not front-loaded or structured 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 correctly carries the burden of enumerating return sections and their null semantics, which is the right call for a multi-part read tool. It is close to complete, though the enumeration's density makes some fields easy to miss on a first read.

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 schema description is thin ('wallet whose ticket and progress to read'), so the description genuinely extends it: adding `wallet` yields that wallet's held/not-held status, verified volume, skin pass, its 5-trait ticket face, and this week's entries. This is information the schema alone does not convey.

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 and resource ('Reads the Game tab ... GET /api/tirage') with an enumeration of the exact payload sections (tickets, pot, preview face, BlockRolls, practice rolls). It does not explicitly contrast with siblings like tblock_panel_state, so an agent must infer the division of labor, but the purpose itself is unambiguous.

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 statement of when to call this versus siblings; the only routing hint is incidental ('the 5-trait guess tblock_plan_roll uses by default'), which explains lineage rather than when to pick this tool. 'Read-only' is a property, not usage 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 and openWorldHint, so safety is covered; the description goes further by disclosing the exact failure mode ('REFUSED with tableau = PAS_OUVERT' when the contract is not deployed) and the backing endpoint. That error contract is the kind of detail annotations cannot carry. It stops at 4 because there is no mention of caching/refresh semantics for a board that changes server-side.

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 endpoint, with the field list packed into a parenthetical rather than padded into prose. The refusal clause is placed after the payload description, which is reasonable. Slightly dense, but nothing is wasted.

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-shape burden and does so by naming the contract plus each mission field. It also covers the error condition and confirms the absence of inputs. For a zero-parameter read tool, an agent has everything needed to call it 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?

The tool takes zero parameters, so the baseline is 4. The description reinforces this with 'no input', which matches the empty schema and additionalProperties: false, leaving no ambiguity for the caller.

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 and resource ('Reads the Block Missions board') and even pins the underlying endpoint (GET /api/missions), plus enumerates the payload shape (id, reward token/amount, done/maxDone, holding, state). That is far more specific than a tautology. It does not explicitly contrast itself with siblings like tblock_pairs or tblock_game_state, 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?

Usage is only implied: an agent infers it should call this when it needs mission-board state. There is no statement of when to prefer it over tblock_game_state or tblock_pairs, and no workflow context. The one genuinely useful signal is the precondition that the call is REFUSED while the contract is undeployed, which is a partial substitute for real 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 and openWorldHint, so safety is covered. The description adds return-content context: the exact currency set, the creator minimum floor per currency, and an `echanges` swaps field built by `tblock_plan_swap`, which is valuable because there is no output schema. It repeats 'Read-only, no input' and omits pagination/auth details, keeping it from 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?

A single front-loaded sentence beginning with the verb and primary resource. The parenthetical currency list and `echanges` clause are dense but informative, though the sentence is somewhat 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 must carry return-value information, and it does name the currencies, creator minimums, and an `echanges` swaps field. It still lacks output structure or pagination details, but for a zero-param read-only reference tool it is reasonably complete.

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 has zero parameters, so the baseline is 4. The description's 'no input' is consistent with the empty schema and requires no further parameter explanation.

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 ('Lists') and resource ('currencies a new block can be paired with at birth on TokenizedBlock'), enumerates the currencies, and names the related `tblock_plan_swap` builder. An agent can tell this is a reference/list tool rather than a plan-building or panel-state 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?

No explicit when-to-use or when-not-to-use guidance. The description says it is read-only and takes no input, but that is not usage routing; it does not tell the agent when to choose this over `tblock_creator_minimum` or `tblock_plan_swap`.

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 tell the agent it is non-readonly and non-destructive. The description adds the crucial interaction model beyond annotations: 'Commands are proposals: the block's brain accepts or refuses each task, and only the user's wallet signs,' plus the manual step 'Give the link to the user,' clarifying the agent cannot complete the flow itself.

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 the return value, followed by workflow guidance. The tab enumeration '(the block in the centre; Market, Trade, Brain and Chat tabs)' is somewhat verbose but helps the agent describe the panel, so only minor trimming is warranted.

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 no output schema, the description explains the return value (a link), the required user action, the sibling workflow, and the proposal/signing behavioral model. Nothing an agent needs to call this 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 the single optional 'block' parameter is already documented as 'the block to show first.' The description references the block only incidentally ('the block in the centre') and adds no format or selection semantics beyond what the schema provides, so the baseline 3 fits.

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: 'Opens a remote-control session and returns the link of the TokenizedBlock control panel.' It further specifies the resource as a visual dashboard with named tabs, so an agent can distinguish it from siblings like tblock_command or tblock_panel_state 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?

Explicitly routes the agent: 'Give the link to the user. Then send commands with tblock_command and read what happened with tblock_panel_state.' This names the alternative tools and the sequence for using them, 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes further by disclosing the semantics of the return payload — the brain's verdict on each command, plans built, and what the user signed (transaction hash) or declined — which is genuinely useful given there is no output 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?

A single dense sentence that front-loads the action and then enumerates the return content; nothing is wasted. The backtick-laden, metaphor-heavy phrasing ('wired to the block's brain') costs a little readability but does not pad 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?

For a two-parameter read tool with no output schema, the description does the important work of explaining what the response contains. It omits pagination/volume behavior and error conditions (e.g. invalid or expired session), which are the remaining minor 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 description coverage is 100%, so both `session` and `since` are already fully documented in the schema. The description only echoes that `evenements` are events 'since `since`' without adding format, limits, or edge-case behavior, 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?

States a specific verb ('Reads') and resource ('the control panel') and names the two payload fields it returns, `cerveau` and `evenements`, so an agent knows exactly what it gets back. It stops short of positioning itself against siblings like tblock_panel_open or tblock_command, so it is clear but not fully differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named. The only routing hint is indirect: the session parameter is described (in the schema, not the description) as coming from tblock_panel_open, so the agent must infer that this is the follow-up read after opening a panel.

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 only declaring readOnlyHint and openWorldHint, the description adds substantial behavioral context: it returns *unsigned* calls (explaining why it is read-only), states the 0.001 ETH fee, describes the response payload (every cost `cout`, the block address, and the result of simulating the whole sequence from that wallet), and flags the non-ETH preconditions. This is well beyond what the annotations 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?

Every clause carries information — output, fee, response contents, precondition — and the core purpose is front-loaded. The single long, em-dash-heavy sentence is dense and slightly hard to parse, but there is no filler or redundancy.

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 high-complexity, multi-step planning tool with no output schema, the description covers the essentials an agent needs: what gets created, the fee, the return summary (costs, address, simulation), the signing order, and the non-ETH precondition. Nothing required for correct invocation 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%, so the baseline is 3, but the description adds cross-parameter meaning: it clarifies that `pair` selects ETH or a tblock_pairs currency, that `account` is the signer of the ordered calls, and that the whole sequence is simulated from that wallet. These reinforce 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 states a precise verb and compound resource: it returns the unsigned calls that create a B20 token block AND open its market, enumerating the sub-steps (createPaid, approvals, registration, market opening). This is clearly distinguishable from siblings like tblock_plan_swap or tblock_command, which an agent can rule out on the stated action alone.

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 for use — plan first, then sign the listed calls in order with `account` — and states a concrete prerequisite (for a non-ETH pair the wallet must already hold the creator minimum in that currency). It references tblock_pairs as the currency source but does not explicitly contrast itself with sibling planning tools, so it falls short of a full when/when-not routing 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 only mark the tool as read-only and open-world; the description adds that it returns unsigned calls rather than executing, approves exactly rolls x 0.50 USDC, uses rollWithPass when a day pass is active, resolves after 2 blocks, scores traits in common out of 5, reads mutable live prizes, caps prizes at the pot, defaults the guess from the wallet's ticket face, and refuses practice mode.

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 return type and batch behavior, and every sentence carries operational detail about payment, day pass, timing, prizes, default guess, or refusal. It is dense and could be easier to scan as bullets, but there is little 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, and the description identifies the return as unsigned calls for one wallet_sendCalls batch and explains the refusal case. It covers the paid and day-pass paths, block timing, live prize source, default guess, and wallet-signing requirement, which is 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%, but the description adds real meaning: guess defaults to the SHA-256(wallet|day) ticket face, rolls affects both exact payment and call count, and the guess is scored by traits in common out of 5. Some parameter details repeat the schema, but the added default derivation and gameplay semantics justify more than baseline credit.

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: it returns unsigned calls for 1-10 BlockRolls rolls in one wallet_sendCalls batch signed by wallet. It also distinguishes the planning output from live contract-state reads by naming tblock_game_state for prizes/minScore, and distinguishes the paid path from the day-pass 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?

Explains the primary context, planning a roll batch before signing, and gives a clear when-not case: it is refused with state when no contract is served in practice mode, so nothing should be signed. It does not explicitly contrast with sibling planning tools such as tblock_plan_birth, tblock_plan_settle, or tblock_plan_task, so it stops short of full alternative 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 declare readOnlyHint=true, but the description adds substantial context beyond them: it enumerates the four roll states, explains that the returned transaction is unsigned (no mutation by this tool), specifies the permission model ('anyone may send it, the prize always goes to the player'), and names the failure mode (REFUSED when no contract is served). Only minor traits like rate limits or batching behavior are 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?

A single dense but front-loaded paragraph that begins with what it reads and ends with the failure condition. The inline state enumeration is compact, though the parenthetical list makes the sentence heavy.

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 explaining the return value (one unsigned settleMany call for the settleable rolls) and the possible states. Combined with the covered single parameter and annotations, it is nearly complete; only explicit guidance on when to invoke it versus siblings 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 rollIds parameter is fully documented in the schema (format, range, comma-separated 1-50). The description only refers to 'each roll' without adding syntax or meaning beyond the schema, 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?

States a specific verb and resource ('Plan the settle of rolls', reads settleableUntil per roll) and precisely describes the output: an unsigned settleMany call. It is clearly distinguishable from the sibling plan_* tools (birth, roll, swap, task) 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?

Usage is implied rather than stated: it tells the agent the resulting call may be sent by anyone and that it is REFUSED when no contract is served, which is a precondition. However, it never says when to prefer this tool over the sibling planning tools or what state the rolls must be in to call it. Adequate but with clear gaps.

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 and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it produces unsigned calls the caller must sign, and spells out a multi-step `APPROBATIONS` workflow ('sign the approvals, then ask again'). The one phrase is terse, but it discloses a non-obvious retry loop the annotations do not.

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, which is good, but the first sentence is a long run-on with a dense, comma-chained route enumeration that is hard to parse. The trailing `APPROBATIONS` clause is cryptic and underspecified. Content mostly earns its place, but structure and density hurt readability.

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 routing tool with no output schema, the description conveys the essential return shape ('unsigned calls') and the sign-then-retry approval flow, while the schema fully covers parameters and annotations cover safety. It stops just short of explaining the structure of the returned calls or how `APPROBATIONS` surfaces, but it is largely 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?

Schema description coverage is 100%, so the four parameters are already fully documented in the schema. The description's '`amount` is in raw units of the token paid' duplicates the schema's own 'Raw integer units of the token paid' almost verbatim, adding no new meaning. 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 and resource: it returns unsigned swap calls routed by TokenizedBlock, and enumerates the supported route families (block-to-quote, block-to-block, block-to-tokenized-stock, ETH/USDC, OUSD). This is far more precise than a tautology. It does not, however, contrast itself with siblings like tblock_command or tblock_plan_birth.

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 infers it should call this when it wants to prepare a swap. The OUSD note ('ETH <-> OUSD is refused, swap through USDC in two trades') is genuinely useful route-validity guidance, but there is no explicit when-to-use or when-not-to-use versus the other tblock tools.

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: it discloses the exact approve amount (reward x maxDone), the two-call sequence, the swap mechanism, the 24 h hold, the 7-day open window, one-completion-per-wallet, the signing wallet, and refusal conditions. readOnlyHint=true is consistent with a tool that only returns unsigned calls rather than executing them.

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 return value and the call sequence, then mission mechanics, then refusal conditions. Dense but every clause carries operational detail; a slight cost in readability from long compound 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?

No output schema, but the description explains the returned calls, the signer, and the failure modes. Combined with readOnly/openWorld annotations, an agent has enough to invoke it correctly; only the precise encoding of the unsigned call objects is left unspecified.

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 relational meaning: approve is EXACTLY reward x maxDone, and hold is the raw-unit minimum held for 24 h. This ties the parameters together in a way the schema alone does not.

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 outcome (returns the unsigned approve+postTask calls that post a mission on the Block Missions board) and scopes it to a block. This clearly distinguishes it from siblings like tblock_plan_swap or tblock_plan_birth, which plan other actions.

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 when-not conditions (REFUSED while the board contract is not deployed, or when the block has no TokenizedBlock pool) and characterizes the mission semantics. It does not, however, name a sibling alternative or state when to prefer this over the other plan_* tools, leaving some routing inference to the agent.

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