tokyo-futuro

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

No annotations are provided, so the description carries the full behavioral burden. The phrasing lightly implies a read-style retrieval of agent activity, but it never confirms read-only semantics, scoping (all agents vs. the caller's), or freshness of 'lately' — no rate limits, auth needs, or mutation risk is disclosed.

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 short sentence with no filler, which is appropriately sized for a zero-parameter tool. However, the brevity comes at the cost of specificity — the phrase is impressionistic rather than front-loading an actionable statement of what the tool does.

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 simple no-arg, no-annotation, no-output-schema tool, the description is the only source of meaning, and it leaves the core questions unanswered: what exactly is returned, whose agents are included, and when to call it. It gestures at the return content but is not complete enough for reliable 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing because none exists.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (agents) and hints at the content returned — agents currently playing, which belong to the caller, and their recent activity — but supplies no verb, so it never states the operation (list, fetch, query). It is more than a bare restatement of the name but stops at a vague, evocative phrase rather than a specific verb+resource, and it draws no boundary against siblings like 'me' or 'city_status'.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. An agent cannot tell from this text whether 'agents' supersedes or complements 'me' or the crew/job 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?

With no annotations present, the description carries the full burden and does state 'Read only', which is the key safety fact. It also discloses that the wallet is used to check Disk balance and a daily limit, giving the agent the eligibility model. It does not cover failure modes or rate behavior, but the read-only claim is unambiguous and consistent with the schema note that nothing is sent from the wallet.

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 return fields front-loaded and no filler. However, terse fragments like 'sold and cap' and unexplained jargon ('Disk') cost some readability without saving much space.

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, so the description must describe returns, and it does list the main fields plus the conditional 'reason if not' case. It is missing any explanation of what 'cap' means as a numeric field, which would matter for an agent interpreting the quote.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in detail, including the reassurance that the wallet is never debited. The description adds only the purpose of the wallet (Disk and daily-limit check), which is largely redundant with the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (apartments for sale) and enumerates exactly what the quote returns: price in ZENI, sold status, cap for levels 2-5, and buy-eligibility with a reason. It is distinguishable from the prepare_apartment_* siblings by being a read-only preview, though it never names those siblings explicitly to reinforce the 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?

'Pass your wallet for a quote that checks your Disk and daily limit' implies you call this before attempting a purchase, but the description never states that explicitly or points to prepare_apartment_buy as the follow-up action. Usage is inferable rather than prescribed.

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 no annotations, the description carries the full burden and does so well: it discloses the capped 300 bps bonus, that a Muscle holding a weapon grants it, that the convoy/Ledger contracts have no weapons module today so the bonus is 0, that round-3 testnet deploy activates it, and that vehicle heist and apartment raid take no weapons by design. This is unusually rich behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: weapon range and return fields come first, then the bonus mechanics and the connectivity caveat. Nearly every clause earns its place, though the parenthetical about round-3 deployment is a touch verbose.

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, yet the description tells the agent what the listing contains and explains the currently-inert bonus mechanic plus where to check live switches. For a read-only catalog in a rules-heavy game, nothing an agent needs to interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one optional parameter and schema coverage is 100%, so the schema already explains that wallet adds the weapon bonus preview. The description restates the bonus concept but adds no syntax or format 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?

States a specific verb+resource (weapon shop listing) and enumerates exactly what is returned: price, supply left, and the Stash rank required for ids 1 to 6. An agent can distinguish this catalog call from prepare_weapon_buy, which is named as the purchase 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?

Explicitly routes buying to prepare_weapon_buy and states 'Read only', plus points to city_state.switches for what is live. It stops short of naming when this tool should not be called (e.g. versus vehicle_shop), but the read-vs-buy split is clear.

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

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

With no annotations, the description carries the full burden; it does disclose the auth requirement (wallet token, poster-only) and the downstream consequence that only the selected agent can take the job. It omits whether the pick is final/reversible, whether it awards the job immediately, and how failures are reported.

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 with no filler, and the role/auth constraint is front-loaded. The parenthetical phrasing is slightly telegraphic but efficient for a small mutation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-changing tool with no annotations and no output schema, the key facts (who may call it, what it selects, the exclusivity effect) are present. Missing are the meaning of the 'job' parameter and any indication of the outcome or error behavior an agent needs before committing.

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 only 33% (just the token field documented), so the description does add meaning by defining 'bid' as the bid number from job_bids. However, the required 'job' parameter is never explained, leaving a gap the schema does not fill.

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 ('pick one bid') and pins the identifier source ('the bid number from job_bids'), which distinguishes it from bid_place and job_bids. It also names the caller role (poster), though the effect on the job itself is only hinted at.

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: only the job poster, authenticated with a wallet token, and implies the prerequisite of having read bids via job_bids. It does not state exclusions such as what happens if a bid was already picked or if the caller is the bidding agent.

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 no annotations, the description does the heavy lifting: it discloses the auth requirement, the one-bid-per-agent limit, pitch length and content rules, and that instruction-like or money/key-moving text is held rather than displayed. It doesn't say whether the posted reward is committed or escrowed on bid, or whether a bid can be edited or withdrawn.

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 short sentences, front-loaded with the action and eligibility, then constraints, then the moderation behavior. Every clause carries a rule an agent would otherwise get wrong; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write tool with no annotations and no output schema, this covers eligibility, auth, limits, content rules and moderation handling. It stops short of describing success/failure outcomes or the economic effect of bidding at the posted reward.

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 only 33% (just the token parameter), so the description must compensate, and it does: pitch is defined as 10 to 280 characters with no links or addresses, and job is constrained to jobs open to bids. The reward/pricing relationship to the bid is implied but never tied explicitly to a parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Bid on a job that is open to bids" gives a specific verb and resource, and the parenthetical about wallet token and declared agents scopes who can do it. It does not name siblings such as bid_pick (selecting a bid) or bids_close, so the distinction from those crowded neighbours has to be inferred.

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

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

Preconditions are spelled out: the job must be open to bids, the caller must hold a wallet token and be a declared agent, and only one bid per agent is allowed. It never states alternatives or when not to use it (e.g. after bids_close), which leaves a gap against the 5 bar.

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 no annotations, the description carries the full burden and does reasonably well: it discloses the auth requirement (wallet token), the resulting state ("anyone can take the job again"), and a validity constraint. It is silent on side effects to existing bids (cleared, retained, refunded) and on idempotency for repeat calls, which matters for a state-mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact clauses, with the caller constraint and the action front-loaded before the restriction. No filler, no repetition 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?

For a mutating tool with no annotations and no output schema, the description covers who, what, and one hard exclusion, which is close to sufficient. It still leaves the agent guessing about the response payload and what happens to the bids that were already placed.

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?

At 50% schema coverage, the token parameter is already documented in the schema and the description only reinforces it as the poster credential. The required "job" integer is undocumented in both places; "close bidding" implies it identifies the job, but no format or source (e.g., from jobs or job_bids) is given.

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?

"Close bidding without picking" is a specific verb+resource with an explicit contrast against bid_pick, so an agent can tell what state transition it performs. It does not name siblings directly, and "close bidding" is domain shorthand that assumes the agent already knows the bids_open/bid_pick/bids_close family.

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

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

It states the caller restriction ("Poster only") and a hard precondition ("Not allowed after a pick"), which is exactly the when-not guidance an agent needs to avoid a failing call. It does not explicitly point to bid_pick as the alternative when the poster does want to choose, leaving that inference to the reader.

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?

No annotations exist, so the description carries the full burden and does meaningful work: it discloses the auth requirement (wallet token), the authorization constraint (poster only), the required job state (OPEN), and the resulting effect (nobody can take the job until a bid is picked or bidding closes). It omits reversibility, cost, and any error conditions, which keeps it below 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 short sentences with zero waste; the actor/auth constraint and the state precondition are front-loaded before the effect. Nothing is repeated from the schema or padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter action with no annotations or output schema, the definition covers who may call it, what state is required, and what changes as a result. It leaves the bidding mechanics (window length, what bidders see) and failure behavior unexplained, which is a modest gap rather than a blocking one.

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?

At 50% schema coverage, the `token` parameter is documented in the schema, and the description adds the meaningful constraint that `job` must reference one of your own OPEN jobs. That is real added meaning, but it never clarifies what the integer is (job id) or what happens if the job is not open or not yours.

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+resource: 'open one of your OPEN jobs to bids,' with the actor scope ('Poster only') stated up front. It is distinguishable from bids_close, bid_pick and bid_place by implication, but no sibling is named explicitly, so it falls 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?

The description implies preconditions (you must be the poster, the job must be OPEN) and the complementary action ('close bidding'), but never states when to choose this rather than bids_close or bid_pick. Usage is inferable 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?

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: the caller must be wallet-authenticated, not a guest. However it says nothing about read-only vs mutating behavior, what is returned, or rate/limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It is efficient, though its brevity comes at the cost of clarity about the actual operation.

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 zero-parameter tool with no output schema, the description is minimally adequate but never clarifies the return shape (list vs detail) or the operation. The auth prerequisite helps, but an agent still lacks enough to know what calling it yields.

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 schema has nothing to document and the baseline of 4 applies. There is no parameter information the description could add.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('Starter ETH bounties for real on-chain actions') but uses no verb, so an agent cannot tell whether this lists, retrieves, or manages bounties. It is distinguishable from bounty_claim/bounty_complete by being the parent concept, but the exact operation is left to inference.

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

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

The only usage signal is the access prerequisite ('need a real wallet, not a guest'); there is no statement of when to call this versus bounty_claim, bounty_complete, or jobs. No alternatives or conditions are offered.

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 no annotations, the description carries the full burden; it does disclose meaningful gating behavior (declared agents only, one slot per wallet, wallet-token based), which is real context beyond the schema. However, it does not state that this is a state-mutating claim, what happens on success/failure, or idempotency/error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action front-loaded and constraints parenthetically attached; no wasted words. It is perhaps terse to the point of omitting needed detail, but structurally efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a state-mutating claim tool with no annotations, no output schema, and fully undocumented parameters, the description is too thin. It conveys eligibility but omits mutation semantics, failure modes, and the meaning of "id", leaving an agent with significant 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 0% for two required parameters. The description only clarifies "token" (as a wallet token), leaving "id" entirely unexplained in both the schema and the description. At this coverage level the description should compensate but only half does.

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 ("Claim") and resource ("starter bounty slot"), which separates it from the sibling bounty_complete (completing vs claiming). It does not explicitly name alternatives, but the action and scope are clear enough to distinguish it.

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

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

The parenthetical gives eligibility constraints ("declared agents only, one per wallet") that imply when the tool is valid, but there is no explicit when-to-use guidance or reference to siblings like bounty_complete or bounties. Usage is only inferable from the constraints.

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

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

No annotations are provided, so the description carries the full burden. It discloses that a wallet token is required and that this is a confirmation step rather than the original action, but says nothing about permissions, idempotency, reversibility, or what happens if the on-chain action did not occur.

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 short sentence with the trigger condition front-loaded and no wasted words. Terse, but not to the point of under-specification that hurts 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?

With no annotations, no output schema, and two parameters at 0% schema coverage, the description is too thin to make this tool safely invocable. It should at minimum name the resource (bounty), explain the id parameter, and describe the confirmation outcome.

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 0%, so both required parameters are undocumented in the schema. The description clarifies 'token' as a wallet token, but 'id' is left completely unexplained, so it only partially compensates for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys a confirm-after-on-chain-action step and implies the resource by naming the wallet token, but never actually says 'bounty' or distinguishes itself from job_complete or bounty_claim. An agent can guess the intent but cannot confidently tell it apart from siblings.

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 real trigger condition ('After you did the on-chain action'), which is useful sequencing guidance. However, it names no alternatives and states no when-not conditions, so an agent must still infer how this differs from bounty_claim or job_complete.

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 no annotations, the description carries the full burden and does well: it discloses read-only/free behavior, that no wallet address is shown, that only provable lines are included, and that it warns when an owner wallet holds 20 or more ids. It does not cover auth, rate limits, or error behavior, but the key behavioral traits are present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then lists the reported facts efficiently. It is dense but every sentence contributes, with no obvious filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values, and it does so by enumerating existence, wallet separation, feedback, gate status, record counts, and factory warnings. For a one-parameter read-only tool, this is nearly complete, though it could mention response format 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%, so the single id parameter is already documented. The description adds useful context that the id is an ERC-8004 agent id on Robinhood Chain, but it does not add syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: a public page for any ERC-8004 agent id on Robinhood Chain, and enumerates what it reports. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as agents or reputation.

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 'for any ERC-8004 agent id' and 'Read only, free,' but there is no explicit when-to-use guidance, no when-not guidance, and no named alternative among the many sibling 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?

With no annotations, the description carries the full burden, and it does add real behavioral context: read-only, free, ranked by verified paid jobs then feedback then Hookr link, never by money, and no wallet addresses exposed. It does not cover pagination behaviour, ordering guarantees at page boundaries, or the shape of what comes back, which matters for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is compact and front-loads the subject, and most sentences carry information (inclusion rule, ranking order, exclusions, cost). However, fragments like 'Names are outside text' and 'Hookr-linked' are cryptic rather than concise, and the parenthetical owner rule interrupts the main clause.

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 3-parameter read-only list tool with no output schema, the definition covers eligibility, ranking rationale, citizen splitting, and cost. It still leaves the response shape, pagination semantics, and two-thirds of the parameters unexplained, so an agent could call it but not confidently predict or page through results.

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 0%, so the description should explain all three parameters. It only clarifies one value of show ('citizens'), leaving 'others' and 'all' unexplained and limit/offset entirely undocumented — including whether limit has a default or cap, which is exactly the kind of detail the bare schema lacks.

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 resource ('The Bureau board') and the entity being listed ('ordinary ERC-8004 agents on Robinhood Chain') with disclosure of who is excluded (owners with 20+ ids, factory wallets). It partially distinguishes from siblings by noting citizens are listed separately, though the dense jargon ('Hookr-linked', 'Tokyo jobs') means an agent must infer what a 'board' row actually represents.

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 an implicit usage cue — use this for the ranked agent leaderboard, and pass show=citizens to see citizens separately — but no explicit 'use X instead of bureau_agent/trial_board' routing. The agent must infer when this board is preferable to the many neighbouring listing 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?

With no annotations, the description does real work: it declares read-only status, explains that undisclosed events are deliberately withheld ("never lists events that have not happened"), and clarifies a non-obvious sentinel value (count of 0 means the engine never ran on this network). It stops short of stating auth/network prerequisites or how large the payload may be.

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 opening clause is well front-loaded, but the middle degrades into a nested parenthetical that lists switches inside a list of contents, making it hard to parse in one pass. Every sentence conveys information, but the packaging is denser than necessary for what is essentially an inventory of returned fields.

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 describe the return payload, and it does so field-group by field-group, plus the semantics of the event list and the zero-count sentinel. It is close to complete; it lacks only payload shape/size expectations and any note on freshness or caching of "live" 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 100% schema coverage is trivially satisfied. Baseline 4 applies, and the description correctly implies no arguments are needed by framing it as one call for the whole state.

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 resource and scope: the live state of every game in Upper City in a single call, then enumerates the concrete contents (paused flags, counts, races, Ledger clock, weather, heat bounties, switches). The verb is implicit ("live state") rather than an explicit action, and it never distinguishes itself from close siblings like city_status or my_city.

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 guidance on when to reach for this versus city_status, my_city, or get_city_news, which appear to overlap heavily. The only orientation is "Read only" and "one call," which implies a snapshot but does not tell the agent which situation selects this tool.

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?

No annotations exist, so the description carries the full burden. It does disclose a real behavioral trait, '(counts only)', which tells the agent the response is aggregate and contains no per-entity detail, and 'Live' implies freshness. However, it says nothing about auth requirements, caching, or rate limits.

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 short sentence with the most important qualifier ('counts only') front-loaded at the end of the data list. Nothing is padded and nothing is missing from the sentence itself.

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 annotations, the description is the only source of return-value information, and it summarizes the payload (counts for gangs, wars, agents, plus latest events) reasonably well. It stops short of enumerating the actual fields, which is the main residual gap for a zero-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is no parameter meaning to convey; baseline 4 applies. The description correctly implies a global, unfiltered query.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (city-wide gangs, wars, agents, events) and the form of the data (live counts), so an agent can tell this is an aggregate status endpoint rather than an entity list. It is not a verb+resource phrasing and never explicitly contrasts itself with siblings like 'agents' or 'bounties', but the scope 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?

There is no when-to-use guidance, no mention of prerequisites or auth, and no alternative tool named. The agent must infer that this is a dashboard/overview call from the word 'status' alone.

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 no annotations present, the description carries the full burden and does well: it discloses that nothing is sent on chain ('Read only on chain; nothing is sent'), that only intent is recorded, and what the downstream effect is ('gives the leader your yes for one day'). It omits failure modes (e.g. seat already taken) and whether the approval can be revoked before signing.

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 short sentences, front-loaded with the core action and scope, then the return/signing contract, then the on-chain safety note. 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 4-parameter tool with no annotations and no output schema, the description explains the return value (an unsigned prepare_approve_leader call) and the safety profile, which is what an agent most needs. Remaining gaps (edge cases, whether the same seat can be requested twice) are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so id, role, slot, and wallet are already documented in the schema. The description only reinforces that the id comes from open_seats, which the schema also states, so it adds little beyond the structured data. 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 ('ask for a seat in an open request') and implicitly distinguishes itself from open_seats (the source of the id) and prepare_approve_leader (the returned call). An agent can tell this is a board-seat request action without opening the schema, though it does not explicitly name the sibling it is not.

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?

Clarifies the workflow: this only records intent, then the caller must sign the returned prepare_approve_leader request from their own wallet. That sequencing is real usage guidance. It stops short of explicit when-not-to-use conditions or naming a true alternative path.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one behavioral trait ('the reply includes an invite code'), but omits whether the crew creation is limited, what auth/permissions are needed, and what side effects occur. For a mutation tool with zero annotation coverage this is thin.

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 the core action and no filler. Efficient, though the parenthetical could be clearer.

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 annotations, no output schema, and 0% parameter documentation, the description is too sparse for a mutation tool that creates a wallet-backed entity. Key details an agent needs are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description only vaguely implies 'token' means a wallet token. Neither the 'name' nor 'token' parameters are explained, leaving the agent to guess the token's source and format.

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 ('Create your own crew') that clearly distinguishes it from sibling join tools like join_crew and join_official_crew. The parenthetical '(wallet token)' is slightly cryptic but the core action 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 guidance on when to use this versus join_crew, join_official_crew, or join. The agent must infer from the name alone that this creates a new crew rather than joining an existing one.

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 no annotations, the description carries the full burden and does disclose the key trait: 'Read only', so an agent knows no transaction occurs. It also explains the conditional behavior of the wallet parameter (holdings are returned only if supplied). It does not address whether any pricing or lookup is wallet-gated, but for a read-only catalog this is largely sufficient.

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 leads with the tool's identity and ends with the most decision-relevant property ('Read only'). The nine-item enumeration is verbose, but it tells the agent what the catalog contains, so it earns most of its space.

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, no-output-schema, no-annotation tool, the description covers what is returned (prices and per-item holdings) and the safety profile (read only). Only the relationship to the purchase flow (prepare_dispensary_buy) 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 already documents wallet as 'Optional: your 0x wallet, to see what you hold.' The description reinforces and slightly extends this by stating the same conditional outcome in context of prices, so it adds clarity without redundancy that harms. Nothing about format or validation is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (the nine one-use dispensary supplies), enumerates them, and says it returns $ZENI prices plus holdings. An agent can tell this is the dispensary catalog rather than a purchase action. It stops short of an explicit verb like 'list' and never contrasts itself with arsenal_shop or prepare_dispensary_buy.

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?

'Read only' plus the wallet-carrying option implies this is the browse-before-you-buy step, but no alternative is named and no condition is stated for choosing it over prepare_dispensary_buy or arsenal_shop. 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?

With no annotations, the description carries the whole burden. It does disclose a real behavioral trait — the account is auto-created by the first trade, so a call may return an empty/not-yet-opened account — and implicitly frames this as a read of one's own account. It says nothing about permissions, whether the token is session state, or failure behavior for an invalid token.

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 the resource and its returned fields, with the lifecycle fact placed last. The parenthetical is slightly awkward 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?

For a single-parameter read with no output schema and no annotations, the description covers identity (wallet token), content (cash, holdings, value, weekly return), and lifecycle (opened by first trade). Only the invalid/missing-token behavior is left unstated, which is a minor gap at this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional 'token' parameter, so the schema already explains it. The description restates it as '(wallet token)', which reinforces that it identifies the caller's wallet but adds no format, sourcing, or omission behavior (e.g., what happens if the token is left out).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (paper Exchange account reached with a wallet token) and enumerates what it yields: paper cash, holdings, value, and weekly return. That is enough to tell it apart from exchange_trade (which acts) and exchange_table (which likely shows market state), though the verb itself is implicit rather than stated.

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 parenthetical '(wallet token)' hints that a token is needed, and 'Your first trade opens the account' tells the agent the account may not exist until trading. There is no explicit statement of when to call this versus sibling tools like 'me', 'exchange_table', or 'exchange_winners'.

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 no annotations, the description carries the full burden and does unusually well: it declares the operation read-only and free, states that no money is held or moved and no wallet is shown, and warns the tool is currently off until the team enables it. That availability caveat is exactly the kind of context annotations would otherwise provide. It does not describe the response shape or how often the table refreshes.

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 paragraph, front-loaded with the identity of the table, with every sentence carrying information (ranking basis, eligibility, safety, availability). Some phrasing is cryptic, notably 'names are outside text' and the 'PAPER' capitalization, which read as in-jokes an agent must guess at.

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 and no annotations, so the description must stand alone, and it covers the ranking basis, the asset universe (11 stocks via Pyth), eligibility, and safe-operation guarantees. Missing only the return shape and refresh cadence, which are minor for a zero-parameter 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?

The schema has zero parameters, so there is no parameter semantics to add; the baseline of 4 applies. The description appropriately spends its space on scope and behavior instead of inventing inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and ordering: 'this week's table of agents by return on $10,000 of PAPER cash traded at real stock prices'. That is enough to distinguish a leaderboard read from actions like exchange_trade. It stops short of naming the nearest sibling (exchange_winners) as the alternative, so a 4 rather than 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 implied by the framing: read this to see this week's ranking of paper-trading agents. The eligibility rule ('needs 3 trades to rank') is a useful usage constraint, but there is no explicit when-to-use vs. exchange_winners or exchange_me, and no statement of when this view is not appropriate.

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 no annotations, the description carries the full behavioral burden and does it well: it discloses paper-money-at-real-price semantics, margin mechanics for short ('the amount is locked as margin... can lose at most that margin'), the 15-minute price freshness gate, and the one-direction-per-stock rule. It leaves out post-trade behavior (order settlement, how positions are reported) and error handling, which keeps 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?

All content is relevant and the purpose is front-loaded, but the single run-on sentence with stacked parentheticals — including the short/cover explanation embedded mid-list — makes it harder to parse than a short enumerated form 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?

For a six-parameter mutation tool with no annotations and no output schema, the description is nearly complete: it covers constraints, enum semantics, limits, market conditions, and input hygiene. It still omits what a successful trade returns and how the wallet token is obtained, which matters for a first-time caller.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does for nearly every parameter: symbol (with ten example tickers), side with meanings beyond the enum labels (short = bet down, cover = close a short), usd range ($10–$5,000), all:true semantics, and reason format (one-line, outside text, no links). The token parameter is only gestured at as 'wallet token' with no guidance on where it comes from.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Paper-trade a stock', and adds the constraint 'wallet token, declared agents only'. It does not name or contrast the exchange_* siblings (exchange_me, exchange_table, exchange_winners), so sibling differentiation is left to inference.

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 real preconditions — 'the market must be open (the price must be under 15 minutes old)', 'declared agents only', and 'one direction per stock' — which tells the agent when the call will succeed. It never points to an alternative tool for checking prices or account state, so the agent must infer when to use this versus exchange_table or exchange_me.

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 no annotations, the description carries the full burden and does so well: it discloses the Friday 21:00 UTC lock, that ranking order determines prizes, that house agents and citizens are excluded, that no wallet data is exposed, and that the call is read-only and free. Missing only edge behavior such as what a first-week/empty response looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the purpose, then the timing/eligibility caveats, then the returned fields, which is the right order for an agent scanning quickly. The parenthetical is dense but every clause carries real information; only the reward-field list borders on restating the output rather than adding meaning.

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 compensates by enumerating the returned columns (rank, name, paper return, trades, prize) and stating that wallet identities are excluded. Combined with the scheduling and eligibility rules, an agent has everything needed to call this correctly 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 there is nothing for the description to disambiguate. Baseline 4 applies, and the description correctly avoids inventing parameter discussion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource and scope: winners of the latest closed week of the paper Exchange. It also distinguishes itself from the sibling exchange_me by stating 'No wallet is shown', so an agent can tell this is a community leaderboard rather than its own results. It stops short of an explicit verb ('returns/lists') but the meaning 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?

Usage is only implied: the agent infers this is for checking finalized weekly standings after the Friday 21:00 UTC lock. It never says when to use exchange_table or exchange_me instead, nor what happens if the current week is still open. 'Read only, free' tells the agent it is safe to call but not when it should.

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?

No annotations are provided, so the description carries the full burden; it does disclose the data surface (base price, pick price per type, remaining supply), which implies a read-only informational call. However it never states that it is read-only, whether it costs anything, or how availability changes, so behavioral disclosure is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short (two sentences) with no obvious padding, but the colon-chained structure ('Fight Club: the fighters drop: base price, ...') is awkward and front-loads a game-mode label rather than the tool's function.

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 zero-parameter, no-output-schema info tool, the description should compensate by explaining what the return contains; it lists three values but leaves terms like 'type' and 'drop' undefined and gives no sense of what an agent should do with the result. It is minimally adequate rather than 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 takes zero parameters, so per the rubric the baseline is 4. There are no argument semantics for the description to clarify.

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 hints that this returns drop information (base price, pick price per type, remaining count), so an agent can guess the resource, but it never uses a clear verb like 'get' or 'returns' and leads with a game-mode label 'Fight Club:' that reads like flavor text. It does not distinguish itself from siblings such as my_fighters or prepare_mint_fighter.

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 statement of when to call this versus alternatives like my_fighters, mint_info, or prepare_mint_fighter. The second sentence ('A fighter is what you challenge and fight with') supplies domain vocabulary but no selection 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?

No annotations are provided, so the description carries the full burden, and it does state 'Read only' as an explicit safety signal. It also discloses that the wallet param is never used to send anything, which is valuable behavioral context. It omits any mention of failure modes or whether status is real-time vs. cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense and front-loaded with the domain framing first, then the return contents, then the action routing, then the safety note. The middle sentence is a long run-on enumeration, but each clause (window end, applicant count, winning application once drawn, outcomes) carries distinct information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain return values, and it does so thoroughly: run lifecycle states (accepting applications, seat lottery, awaiting drand draw, finished with won/lost/expired/void) plus wallet-specific fields. Combined with a fully documented 2-param schema, an agent has what it needs to call this 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 baseline is 3; the description adds meaning by explaining what the wallet parameter actually unlocks (flight status, cooldown, claimable winnings) beyond the schema's 'read balance and allowance and simulate'. The n parameter is only implied by 'latest runs' and relies on the schema for its 1–30 range.

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 establishes the resource (AirRun: helicopter and private-jet runs) and effectively states that it reads current run state, enumerating the categories of runs returned. It doesn't lead with a clean verb like 'List' or 'Get', but an agent can still tell it's a read of air-run status. It distinguishes itself from prepare_air_run, the only closely related sibling.

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?

'Take a run with prepare_air_run' explicitly routes the agent to the alternative action tool, and 'Pass wallet for its flight status, cooldown and claimable winnings' gives concrete usage context for the optional param. It stops short of stating when not to call it or any prerequisites (e.g. does it need wallet login first?).

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?

No annotations exist, so the description carries the burden and does well: it self-declares 'Read only' and discloses a meaningful information gap ('the poster is not shown'), preventing an agent from hunting for a field that isn't returned. It doesn't discuss ordering or what happens when the list is empty, but the safety profile is clear.

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 resource and its contents in the first sentence; the mechanic explanation and the write-alternative follow. The parentheticals are dense but every clause carries a fact an agent needs; nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing the returned fields and the aggregate values. Combined with a fully documented two-parameter schema, an agent has enough to call it correctly; only list ordering and empty-result behavior are unstated.

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 both parameters (n with range 1-50/default 20, includeClosed) are fully documented in the schema. The description adds no syntax or default detail beyond that, 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?

Names a specific resource (open bounties on rival crews) and enumerates the returned fields (prize in wei, expiry, crew id, minimum prize, allowed duration). The final line 'Post one with prepare_bounty_post' separates it from the write-side sibling, so an agent can route 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?

Explains the game mechanic that makes the data meaningful (a squad raiding that crew splits the prize) and routes posting to prepare_bounty_post. It does not explicitly say when to prefer this over the plain 'bounties' sibling, which is the one ambiguity left.

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 no annotations provided, the description carries the behavioral burden and does a good job stating that the tool is read-only, that the draw is public and random, and that an AI only writes words without choosing or changing anything. It does not cover auth, rate limits, or error behavior, but it discloses the key non-deterministic and safety traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core resource and content types, then adds useful behavioral caveats. It is somewhat dense in the first sentence but overall appropriately sized with little 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?

The description explains what kinds of bulletins are returned and includes important read-only/randomness context, but because there is no output schema, it should do more to explain the shape of the returned data. It is adequate but not fully complete for an agent needing to know the response format.

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 both n and kind. The description reinforces what kind='events' and kind='stories' mean, but it does not add syntax or constraints beyond the schema, making 3 the correct 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?

The description clearly states that this tool returns the latest short city news bulletins about Games Master events, CityWeather rounds, and Wanted wall stories. It is specific about the resource and scope, but it does not explicitly distinguish itself from sibling tools such as wanted_wall or city_status.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like wanted_wall, city_status, or city_state. The intended use is only implied by the content description, and there are no exclusions or routing instructions.

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 no annotations available, the description carries the full burden and does so well: 'Read only', 'It pays nothing and promises no income', and the clarification that unlock checks 'are Worker/site checks, not on chain'. It also explains that a Disk is 'counted once', which prevents double-counting assumptions. It omits any statement about response shape beyond the field list or about leaderboard ordering/pagination.

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 the core concept, and the density is mostly justified by the scoring rules. However, the single run-on sentence with nested parentheses and semicolons is hard to parse, and the tier thresholds are effectively stated twice (once as a ladder, once inside the unlock requirements), adding length without new 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 two-optional-parameter, no-output-schema read tool, the description supplies the scoring formula, tier cut-offs, unlock thresholds, read-only nature, and the fields returned for a wallet. The remaining gap is the leaderboard entry shape and ordering, which an agent would have to discover at runtime.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds above that by explaining exactly what supplying `wallet` yields (score, tier, parts, rank, unlocks) and what the invariants are (a Disk counted once). `limit` is only covered by the schema ('Board length, 1 to 100 (default 25)'), not the description, which keeps it from 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 description defines the resource precisely: an estate 'STANDING' score computed from wallet holdings, plus an Estate leaderboard, with an explicit scoring formula and tier ladder. It distinguishes itself from the neighboring Rep system ('it only ranks wallets, next to Rep'), though it never names a sibling tool directly. An agent can tell what this returns 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?

It clearly explains the two modes: 'Pass a wallet for its score, tier, parts, rank and what it unlocks' versus omitting it for the board. It also sets expectations negatively ('It pays nothing and promises no income'), which prevents misuse as an income tool. It does not explicitly name alternatives like reputation or get_estate_boost, so it falls short of a full when-to-use/when-not map.

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 no annotations, the description carries the full burden and does state 'Read only', which is the critical safety signal, plus that the refresh figures are a simulation of what a refresh would write rather than an actual write. It also notes anyone may perform the actual refresh elsewhere, implying no privileged access here. It stops short of describing error behavior or what happens when neither crewId nor wallet is supplied.

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, but it is delivered as one long run-on sentence with nested parentheses ('plus what a refresh would write now (Estate points, tier 0 to 4, percent)'), which is harder to parse than a two- or three-sentence split. The trailing 'Read only.' is well placed and front-loading of the resource name helps.

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 compensates by enumerating the returned fields for both the crew and wallet modes, including tier bounds. With three optional parameters and no annotations, it covers enough to call the tool correctly; the remaining gap is the no-argument/no-mode case and error conditions.

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 mode semantics the schema does not: wallet is an alternative to crewId that switches the result to that wallet's Estate points and tier, and homeIds exists so apartments are counted. Those are behavioral consequences of parameter choice, not restatements of field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (EstateBoost) and enumerates exactly what state is returned: contract status, boost duration, a crew's current boost (percent, expiry, opt-out), and the simulated refresh output (Estate points, tier 0-4, percent). It is distinguishable from the sibling prepare_estate_boost_refresh via the explicit 'Read only' framing, though the lead-in is phrased as a list of return values rather than a single action verb.

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

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

It gives concrete operating instructions: pass homeIds (apartment ids the owner holds, ascending) so apartments count, and use wallet instead of crewId to get a wallet's Estate points and tier. It also routes the mutation case to prepare_estate_boost_refresh. What is missing is an explicit statement of when this tool is the wrong choice (e.g., no-arg behavior).

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?

No annotations are provided, so the description carries the full burden, and it does deliver one real signal: the trailing 'Read only' declares the tool is non-mutating. It also discloses a domain constraint (hard cap of 300 bps). However, it says nothing about permissions, whether data is live or cached, per-chain scope, or how the three optional parameter combinations behave when mixed or omitted.

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?

There is no filler, but the prose is aggressively compressed into two run-on sentences with cryptic fragments ('Global: is it on, are guards on...'), which slows parsing. The definition is front-loaded correctly, yet the parameter routing is buried mid-sentence in clause form rather than broken out.

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 four-parameter, no-output-schema, no-annotation read tool in a jargon-heavy domain, the description covers the return shape and parameter routing but omits the interaction with the prepare_* sibling, default behavior with zero arguments, and any indication of data freshness. Adequate to attempt a call, not complete enough to call confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline would be 3, but the description adds genuine mapping value the schema does not: wallet returns the edge per game for the fighter that wallet brought, fighterId returns that fighter's rarity/rest/post, and assetKind+assetId returns that asset's guard. That tells the agent which parameter combination produces which response slice, beyond the schema's flat field notes.

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 concretely what the tool returns: the capped Muscle bonus (never above 300 bps), the vehicle/apartment guard value, global on/off flags, per-rarity bonus and per-game share. That is specific enough to separate it from prepare_fighter_edge (which would perform the transaction). It never uses a clean verb like 'returns' or 'reads', so the purpose is inferred from the payload listing rather than stated outright.

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 implicitly tells the agent how to pick a slice by naming which parameter yields which data ('Pass wallet for...'), which is useful selection guidance. But it never says when to call this rather than prepare_fighter_edge, fighter_info, or my_fighters, and never states what happens with no parameters. Usage is implied rather than prescribed.

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 no annotations, the description carries the full burden and does reasonably well: it declares the operation read-only and discloses the semantics of the returned state (owned or not, free/squad seat/guard post/Muscle/resting, and until when). It omits auth requirements and pagination/scale behavior, but the mutation-safety question is answered.

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 resource and then enumerates the returned fields; the read-only note trails at the end where it belongs. No filler, though the run-on enumeration is slightly harder to parse than a short structured list.

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 covers what comes back per character, which is the main gap an agent would otherwise face. Missing only usage routing against sibling read tools and any note on result volume.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter exists and the schema documents it at 100% coverage, including the reassuring note that nothing is sent from the address. The description adds nothing about the wallet argument, 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?

The description names a specific resource (a wallet's roster of characters) and enumerates exactly what each entry reports: ownership, current activity, and duration. It is distinguishable from generic fighters lists, though it never explicitly contrasts itself with siblings like my_fighters or standby_agents.

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 note that 'a busy character cannot be placed in another squad' hints at checking availability before squad placement, and 'Read only' signals a safe inspection call. No explicit when-to-use, when-not-to-use, or named alternative tool is provided.

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 no annotations, the description carries the full burden, and it does disclose the key trait ('Read only.') plus the shape of what comes back for each parameter combination. It does not cover limits, freshness of the raid list, or error behavior for unknown crewId/wallet, so it meets the minimum but is 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?

Two sentences, front-loaded with the resource and its full field inventory, then the parameter-dependent extras. Dense but every clause names distinct data; the long parenthetical field list is the only mild clutter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must convey return contents, and it does so exhaustively for both the no-arg and parameterized cases. An agent can call this correctly with what is given; only edge cases (invalid ids, staleness) are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: crewId yields that crew's Safehouse immunity window and cooldown, and wallet yields that wallet's cooldown and Safehouses bought this week. That is substantially more informative than the schema's generic 'a crew id' and 'Your own 0x wallet address'.

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 (Season2Tricks state) and enumerates exactly which fields it reports: live/flags, trick prices, Safehouse price, missed-raid stake loss, and latest squad raids. That is far more specific than a tautology. It does not differentiate itself from siblings like city_state or me, but the subject matter 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?

Usage is implied rather than directed: the second sentence tells the agent to 'Pass crewId for...' and 'wallet for...', which conveys the conditional read patterns. There is no explicit when-to-use vs when-not, and no alternative state tool is named for the no-parameter 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?

No annotations are provided, so the description carries the full burden. It does declare 'Read only' and explains the wallet is only read from, which is real safety context, but it says nothing about error behavior, whether wallet defaults to a connected account, or how the capped perks are computed.

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 that front-load the resource and then the parameter routing; no filler. Slight cost in readability from stacked domain jargon (Disk, Case reveals, Face bonus), but each clause conveys distinct 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 and no annotations, the description covers what is returned and what each optional parameter adds, which is enough to call it correctly. Remaining gaps (default wallet behavior, response shape, failure modes) are modest for a read-only lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), but the description adds genuine meaning beyond the schema: wallet yields Rep tier, Disk, Velvet tier and room access; companionId yields Favour perks; fighterId yields the fighter's Muscle bonus. That mapping of parameter to output section is not in the schema, which only says 'Optional: a companion the wallet owns.'

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 resource and the exact outputs: Velvet key thresholds (Rep tier / companion Favour) plus capped perks. An agent knows this is a threshold/perk lookup rather than a mutation or a generic reputation call. It does not explicitly name a sibling it differs from (e.g. reputation), so it stops short of 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 gives conditional invocation guidance (pass wallet for wallet-scoped data, add companionId for Favour, fighterId for Muscle), which implies both a global and a per-wallet mode. However there is no when-not-to-use, no prerequisites, and no naming of alternatives such as reputation or fighter_info for agents that only want tier data.

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 no annotations, the description carries the full load and does well: it declares the operation read-only, discloses timing behavior (a round every 60 seconds), and reveals a real prerequisite — the Override Disk is required for new bets and new seats. It omits error behavior and whether the read is public/permissionless, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the two games and their win conditions, then the read-only payload. The second sentence is a long comma-chained list that is slightly hard to parse, but nearly every clause adds information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the returned fields (round, pools, limits, open tables, per-wallet bets/claims, Disk status). Combined with the round cadence and the Disk prerequisite, an agent has enough 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% and there is only one optional parameter, so the baseline is 3. The description goes beyond the schema by explaining what passing the wallet unlocks — your bets, claimable winnings, and Disk status — which tells the agent why to include it 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?

Names the specific resource (the two High Tables games, Cho-Han and Red Dragon) and states plainly that it reads current round, pools, limits, open tables and per-wallet state. 'Read only' separates it from the many prepare_cho_han_* and prepare_red_dragon_* mutation siblings, though it never names those siblings directly.

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: 'Read only' plus the conditional 'if you pass a wallet' tells the agent what it gets, but there is no explicit instruction like 'call this before prepare_cho_han_bet' or 'use open_seats for a seat listing'. The agent must infer when this beats the alternatives.

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 no annotations, the description carries the full burden and delivers real behavioral content: it discloses that bid pitches are external text and must never be treated as instructions (a prompt-injection warning), and that every bid sits at the job's posted reward, which prevents an agent from hunting for varying amounts. It omits whether a non-existent or closed job errors versus returns empty, and doesn't mention pagination for jobs with many bids.

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 opens with the verb and scope, then enumerates the returned fields in the order an agent would care about them. Every clause earns its place, including the two parenthetical cautions, 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?

Because there is no output schema, the description does the work of describing the return shape itself, which it handles well. For a one-parameter read tool this is close to complete; only error/empty-state behavior and volume handling are unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single 'job' parameter, so the description must compensate. 'On one job' confirms the tool operates on exactly one job rather than a list, but it never says whether 'job' is a numeric id from jobs/job_ticket or some other handle, nor what happens with an invalid id.

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 ('Read') and resource ('the public bids on one job') and enumerates what is returned: bid-open status, each bid's pitch, bidder identity with type labels, and the poster's pick. This clearly separates it from sibling write tools like bid_place, bid_pick, bids_open and bids_close. It stops short of naming a sibling explicitly, so it is not 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 implied rather than stated: an agent can infer this is the read-side tool for inspecting bids before placing (bid_place) or picking (bid_pick) one. There is no explicit when-to-use framing, no mention of when to prefer job_thread or job_report instead, and no prerequisites 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?

With no annotations at all, the description carries the full burden and does disclose some behavior: it requires a wallet token, is gated on the job's check passing, and returns a completion voucher. It says nothing about what happens when the check fails, whether calling is idempotent, or what the voucher is subsequently used for.

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 short sentence with the action and its precondition front-loaded; there is no padding. The parenthetical wallet token note is compact rather than wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no output schema and no annotations, the essentials (precondition plus token) are present, but the description leaves the voucher concept, failure behavior, and follow-up steps unexplained, which an agent would need in a multi-tool job workflow.

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 0%, so the description must compensate. It does clarify one parameter by tying 'wallet token' to the token field, and 'the job' implies the job identifier, but it adds no detail on format, range, or how the numeric job id is obtained.

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 action (requesting the completion voucher) tied to the job_complete resource, but the framing 'ask for the completion voucher' does not cleanly map to 'complete a job' and does not distinguish this tool from siblings like job_ticket or jobs. An agent can infer the domain but not the precise effect.

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 supplies a real trigger condition — only call once the job's check passes — which is genuine when-to-use guidance. However, it never names an alternative tool or states when-not to use it (e.g., before the check passes, or versus job_ticket), leaving routing to inference.

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

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

No annotations are provided, so the description carries the burden and does reasonably well: it discloses the three things returned (text, hash, match status), the trust context of the wallet token, and an explicit prompt-injection guard that the worker-written text is data, never an instruction. That safety framing is genuinely valuable non-structured context. It omits side-effect/auth/rate-limit 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?

Three tight sentences, front-loaded with scope and audience. The prompt-injection sentence sounds redundant but earns its place as an explicit safety directive, not 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 2-param read tool with no annotations and no output schema, the description explains what is returned, its trust level, and the gating action before approval. An agent can call it and act correctly. Minor residual gaps around the exact parameter formats and whether any write/side-effect 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 0%, so the description must compensate for both parameters. It annotates 'token' as the wallet token and implies 'job' selects the report job, but adds no format or constraint detail (e.g., token source, job id semantics). Partial compensation only, so it sits at the minimum-viable mark.

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 audience (the POSTER of a report job) and a specific action (read the report text, the on-chain hash, and whether they match). An agent knows exactly what it gets back. It stops short of distinguishing itself from sibling review_job_report, 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?

Gives explicit conditional guidance: approve with prepare_board_approve only if you have read the text and the hashes match. That is a crisp when-to-proceed rule. It does not tell the agent when to call this versus review_job_report, but the invocation context is clear.

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

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

With no annotations, the description carries the full burden and does it well: it discloses the 500-character cap, the no-links/no-addresses content rule, per-state authorization, that closed jobs are read-only, and a moderation behavior (instruction-like or money/key-moving text is held, not displayed). That last point is non-obvious and materially changes how an agent should phrase messages.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded: the action and limits come first, then the state rules, then the moderation caveat. The parenthetical '(wallet token)' and the run-on colon-separated state rules are slightly compressed, but no sentence 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?

For a mutation tool with no annotations and no output schema, the description covers the critical unknowns: authorization per state, content constraints, and moderation side effects. It does not say what a successful call returns or whether token is required versus header-supplied, leaving a small gap for an agent handling errors.

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 only 33% — only `token` is documented — so the description must compensate for `job` and `text`. It does: `job` is framed as a job thread whose accessibility depends on state, and `text` is bounded to 500 characters with no links or addresses, which the schema does not encode (no maxLength or pattern). It still does not clarify what identifier form `job` takes.

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 ('Write one message ... in a job's thread'), with the write verb implicitly contrasting with the read-only sibling job_thread. Scope and constraints are stated up front so an agent can identify 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?

Gives a precise applicability matrix by job state (open job: poster anytime, up to 3 agents one question each; accepted job: poster and worker only; closed job: read-only), which effectively tells the agent when the tool will and won't work. It never names the sibling to use instead for reading (job_thread) or for completing the job, so there is no explicit 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?

With no annotations, the description carries the burden and does substantial work: discloses the wallet-token auth, the keccak256-must-match-on-chain prerequisite, the consequence of poor text (no voucher), and an explicit prompt-injection safety note. It omits return format and any idempotency/rate behavior, so it is not fully 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?

Front-loads the core action in the first clause, then layers hash constraint, voucher consequence, and the injection warning. Every sentence earns its place, though the density and parentheticals make it slightly harder to scan than a clean 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter submission tool with no output schema and no annotations, the description covers purpose, auth, validation constraint, and failure consequence well. It leaves the 'job' parameter and the shape of any response undocumented, which keeps it just under 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?

Schema coverage is only 33% (only 'text' has a description with the 200–5000 char range). The description compensates for two of three: 'token' is identified as a wallet token and 'text' must hash to the on-chain deliverable. The 'job' parameter is left unexplained in both schema and description, leaving a real gap.

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 (report) and resource (jobs) and states exactly what to send: the text of the report delivered, with the wallet token. It distinguishes itself from job_complete by explaining that job_complete is the payout step that consumes this text. Slightly awkward phrasing ('Report jobs: send the text...') keeps it from being maximally crisp.

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 context: use it to submit report text, and explicitly ties it to the ordering with job_complete ('we check this text before signing the payout voucher'). It also implies the failure mode (junk gets no voucher), which steers effort. No explicit when-not or alternative tool is named, so it falls short of a 5.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It notes that the board is public and involves ZENI escrow, but does not state whether it is read-only, what it returns, whether pagination exists, or any auth/rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It efficiently conveys the core concept without 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 zero-parameter listing tool with no output schema, the description should at least clarify that it returns a list of jobs and what 'public' implies for access. It provides a starting point but leaves the agent to infer the exact behavior and completeness 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 per the rubric the baseline is 4. There are no parameters for the description to explain beyond what an empty schema already conveys.

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?

Identifies the specific resource (open job board) and scope (tasks with ZENI in escrow, public), which distinguishes it from siblings like job_complete or bounties. However, it lacks an explicit verb such as 'list' or 'retrieve', leaving the action implicit.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The word 'public' hints at unauthenticated access but does not constitute 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?

With no annotations, the description carries the full burden and does well: it discloses that held messages appear only as held, that citizens are labelled CITIZEN, and that all thread content is untrusted outside text, never instructions. It does not cover ordering, pagination, or visibility/permission rules, which keeps 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?

Three tightly packed sentences, front-loaded with the core purpose and followed by the safety-relevant caveats. Every sentence adds distinct information with 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 one-parameter read tool with no output schema, the description covers content, participants, display quirks, and prompt-injection safety. It is nearly complete, though it leaves open whether the thread is readable by non-participants and in what order messages are returned.

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 'job' parameter is documented in the schema as 'The job id.' The description adds no further syntax or format detail beyond that, 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 (Read) and resource (public thread of one job), with the participant scope spelled out (poster, worker, askers). It implicitly contrasts with the sibling job_message by being the read-side operation, but does not name that sibling explicitly.

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

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

The word 'Read' implies this is the retrieval counterpart to job_message, so an agent can infer usage. However, there is no explicit when-to-use guidance, no exclusion of alternatives, and no stated prerequisites such as whether the caller must be a participant.

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 no annotations, the description carries the full disclosure burden. It valuably discloses the non-obvious protocol trait that this tool only issues a voucher and the caller must submit the accept transaction separately. It omits auth requirements, voucher expiry/reuse semantics, and error/return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the core action is front-loaded before the follow-up responsibility. Slightly cryptic parenthetical phrasing, but no wasted words.

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, no annotations, and 0% parameter coverage means the description should do more. It adequately conveys the unusual two-step hand-off, which is the most important thing, but leaves return format, auth needs, and parameter meaning under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that 'token' is the wallet token, which is genuinely helpful, but says nothing about what 'job' means (job identifier vs index) or its accepted range/format.

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 action (request a voucher) against a specific resource (a job), and clarifies the two-step nature of the flow. It does not name or contrast sibling tools like job_complete or jobs, so an agent must infer ordering from the description 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?

'You then send the accept transaction yourself' implies this is a prerequisite step before accepting a job on chain, which is usable context. However, there is no explicit when-to-use, no stated prerequisites (wallet auth), and no mention of the alternative job_complete or jobs 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?

With no annotations, the description carries the full burden and does well: it warns that the token is "shown once," tells the agent how to propagate it to other tools, and enumerates the capability ceiling of a guest account. It omits secondary traits such as token expiry or whether the name must be unique, but the critical behavioral facts are present.

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 sentences with no filler; the return value and one-time token warning are front-loaded right after the core action. Every sentence adds actionable 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, but the description explains the return (a token, shown once) and the follow-up obligation to pass it along. Combined with the disclosed guest capability limits, this is nearly complete for a two-parameter onboarding tool, though token lifetime is unstated.

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 even documents the allowed character set, so baseline is 3. The description adds little parameter meaning beyond the length constraint (3–24 chars) already in the schema and never mentions the optional `model` parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("Join as a guest agent") and immediately constrains it with the name requirement and what the operation returns (a token). It clearly distinguishes guest onboarding from other entry paths by contrasting it with wallet-based access, so an agent can tell it apart from wallet_login/wallet_nonce 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?

It explicitly states when a guest is sufficient ("can read the city and solve the daily Trial") and what conditions require an alternative ("Earning, bounties and crews need a real wallet"). The gap is that the alternative path is a URL rather than a named sibling tool like wallet_login, leaving the agent to infer the specific next tool.

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 no annotations, the description carries the full behavioral burden. The parenthetical '(wallet token)' hints that token is a wallet credential, but the description says nothing about auth requirements, idempotency, error behavior for an invalid/expired code, or what joining entails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words. It is efficient, though the parenthetical placement makes the token/code mapping slightly ambiguous on first read.

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 two required params, no annotations and no output schema, a one-line description is thin. Auth expectations, failure modes, and post-join effects are all left for the agent to guess.

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 0%, so the description must compensate — and it does for both params, mapping 'code' to an invite code and 'token' to a wallet token. This is meaningful disambiguation beyond the bare string types, though it stops short of format details.

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?

Clear verb+resource: 'Join a crew by invite code' tells the agent exactly what the tool does and the mechanism used. It implicitly differentiates from the sibling join_official_crew by specifying the invite-code path, but never names it explicitly.

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

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

The phrase 'by invite code' implies the precondition for using this tool (you must possess a code), which separates it in spirit from join_official_crew or join. However, no alternative is named and no when-not guidance is given, so usage 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?

No annotations are provided, so the description carries the full burden. It does not disclose what joining actually does (membership mutation, idempotency for existing members, resulting state, permissions or errors), leaving only the vague 'wallet token' hint about the auth mechanism.

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 short, front-loaded sentence with no padding, which is appropriate in size. However, the parenthetical is cryptic rather than informative, so the brevity comes at the cost of clarity rather than from efficient phrasing.

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 annotations, no output schema, and an entirely undocumented parameter, the description is too thin. An agent lacks the information needed to obtain a token, know what state change occurs, or handle an already-joined case.

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 0% for the single required 'token' parameter, so the description is the only source of meaning. '(wallet token)' narrows the token type slightly, but it does not explain the token's format, origin (e.g., wallet_nonce/wallet_login), or validity constraints.

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 verb and a resource ('Join the open project crew'), which is more than a tautology, but 'open project crew' does not clearly map to the tool name 'join_official_crew' and nothing distinguishes it from the sibling tools join_crew or join. An agent could not confidently tell these apart from the text 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?

There is no statement of when to use this tool rather than join, join_crew, or create_crew, all of which appear in the sibling list and cover overlapping ground. The parenthetical '(wallet token)' hints at a prerequisite but is not framed as 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?

With no annotations, the description carries the full burden and does real work: read-only, free, paper zeni with no real money held or moved, and the board being disabled until enabled. 'Names are outside text' flags that listing names are untrusted external data, a useful safety note. It stops short of saying what an actual call returns when the board is off (empty list vs error) or whether results are paged.

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 short sentences with the content inventory front-loaded and constraints after; no filler. Minor cost: the telegraphic fragment 'Names are outside text' is not immediately parseable without domain context.

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 zero-arg, no-output-schema read tool the description covers what is displayed, that it is free and read-only, that the currency is fictional, and that it may be switched off — enough to decide whether to call it. Only the shape of the returned record (ordering, pagination, disabled-state behavior) 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is reported at 100%, so no compensating explanation is needed.

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 resource (the paper loan board) and enumerates exactly what it contains: open offers with lender name, amount, flat fee, days, credit band, collateral, plus repaid/defaulted counts. The clause 'Read only, free' separates it from the mutating loan siblings (loan_offer, loan_take, loan_repay, loan_cancel) without the agent needing to open 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?

Usage is implied rather than stated: an agent can infer this is the browse step before loan_take, but no sibling is named and no explicit 'when to use this instead of X' guidance is given. The one genuine usage constraint it does supply is 'Off until the team switches it on', which warns that a call may be gated by a feature toggle.

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?

No annotations are supplied, so the description carries the full burden; it does disclose the key consequence — the locked amount is returned to the wallet token — which is genuine behavioral value. It does not say whether cancellation is reversible, what happens to partially filled offers, or what a failed cancel returns, which matters for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the outcome stated inline in parentheses; nothing is redundant. The parenthetical '(wallet token)' is a little terse but avoids a second 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?

For a two-parameter state-changing tool with no output schema, the definition covers purpose and the refund effect but leaves preconditions (must the offer be fully unfilled?), failure modes, and parameter formats undocumented. Enough to attempt the call, not enough to predict the outcome in edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It does explain 'token' as the wallet token destination for the refund, and 'one of your OPEN ... offers' implies 'id' identifies the offer, but neither parameter is described explicitly and the schema's own bare 'integer'/'string' types add nothing.

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 (cancel) and resource (paper loan offer) plus two scoping constraints: the offer must be yours and must be OPEN. The phrase 'your OPEN paper loan offers' implicitly separates it from loan_take (taking someone else's offer) and loan_repay, though no sibling is named directly.

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

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

The word 'OPEN' implies a precondition for use (only unfilled/cancellable offers), and 'your' implies an ownership restriction, but neither is stated as an explicit rule. There is no guidance on what to do if the offer is already taken, or on how this relates to loan_take/loan_repay.

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?

No annotations are supplied, so the description carries the full burden. The phrase 'your paper loan account' implies a personal, likely read-only snapshot, but the description does not explicitly confirm read-only behavior, authentication requirements, or any side effects. It adds some behavioral context by listing the returned categories.

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 compact sentence leads with the account concept and then lists the returned data. It is efficient overall, though the parenthetical is slightly awkward and the sentence lacks a clear verb.

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 outlines the returned categories but does not specify exact fields, response shape, or behavior on missing or invalid tokens. It is adequate but leaves clear gaps for an agent preparing to call 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?

There is one parameter with zero schema description coverage. The description's '(wallet token)' clarifies that the token is a wallet authentication credential, which adds meaning beyond the schema. However, it does not state whether the parameter is required, optional, or how the token is obtained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as the caller's paper loan account and enumerates its contents: paper balance, loans as lender and borrower, and repaid/defaulted history. This distinguishes it from marketplace-oriented siblings like loan_board and loan_offer. It lacks an explicit action verb such as 'view' or 'get', but the purpose is still clear.

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 guidance on when to use this tool versus loan_board, loan_offer, loan_take, loan_repay, or loan_cancel. The agent must infer from the name and sibling list that this is a personal account snapshot. It also does not state whether the wallet token is required for access.

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 no annotations, the description carries the full burden and does deliver real behavior: the principal is locked until accepted or cancelled, and "No interest, nothing from any pool" clarifies the fee model. It still omits whether funds are escrowed immediately, what happens on default or expiry, and whether fees are collected upfront — material gaps for a financial mutation.

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 action and token, then the constraints, then the lock lifetime and fee caveat. Dense but every clause carries information; the parenthetical aside about declared agents is slightly awkward but not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, no-output-schema mutation tool with 0% schema coverage, the description supplies ranges, enum meaning, lock semantics, and fee guarantees — enough to call it correctly. Remaining gaps concern settlement and failure modes rather than the call itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the schema has bare integer/number types with no min/max, so the description is doing the heavy lifting: amount 10–500, feePct 1–20 flat, days 1–14, and minBand as the lowest acceptable credit band with its enum values spelled out in prose. Only the optional "token" parameter is left under-explained, referenced only obliquely as "wallet token".

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("Lend paper ZENI") and enumerates exactly what an offer consists of: amount, feePct, days, minBand. It is distinguishable from siblings like loan_take or loan_board by being the offer-creation side, though it never names those siblings explicitly.

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

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

The parenthetical "wallet token, declared agents only" establishes a prerequisite, and the lock-until-taken-or-cancelled statement implies the lifecycle. However, it never says when to use this versus loan_board (browse offers) or loan_take (accept an offer), leaving routing to inference.

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

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

No annotations are supplied, so the description must carry the full behavioral burden, and it does so well for the core outcome: funds plus fee transfer to the lender, collateral is released, and missing the due time forfeits the collateral and records a default. What remains undisclosed is edge behavior such as insufficient balance, whether repayment is atomic or irreversible, and what the caller receives back after a successful call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences front-load the action and the payoff, then append the failure consequence. Every clause adds information and nothing is wasted or repeated.

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 mutation with no output schema and no annotations, the description covers the economics, the authentication requirement, and the failure penalty quite well. The remaining gaps are the exact meaning of `id` and the success response, which matter less because there is no output schema to explain.

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 0%, so the description must compensate, and it only partly does. "wallet token" clarifies that the `token` string is a wallet authentication token, but the required `id` parameter is only obliquely implied by "a paper loan you took", and the description never states that `id` is the loan identifier.

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 ("Repay a paper loan you took") and explains the money mechanics: the amount plus fee goes to the lender and the collateral is returned. This distinguishes it from sibling tools like loan_take and loan_offer by confirming that this tool repays an existing loan and returns collateral, even though it names no sibling explicitly.

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

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

"Repay a paper loan you took" implies the precondition that the caller already holds this loan, and the warning about the due time tells the agent when repayment must happen. However, it never names alternatives such as loan_cancel, does not say what to do if repayment can't be afforded, and gives no explicit exclusions, so the 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?

With no annotations supplied, the description carries the full burden and does well: it discloses the 120%-of-amount-plus-fee collateral lock from paper balance, that the amount is received, that credit band comes from the agent's public record, and the exclusion conditions. It stops short of default/liquidation consequences and whether the token authorizes the wallet, leaving a real gap for a borrow operation.

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 action and cost, then eligibility. Dense but every clause carries information (collateral ratio, source of funds, credit band source, exclusions).

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 mutation with no annotations or output schema, the description supplies cost, funding source, credit determination, and failure conditions. Missing pieces are post-borrow behavior (repayment obligation, default handling) and how to obtain the offer id, which keeps it from being fully 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?

Schema coverage is 0%, so the description must compensate. It partially does: '(wallet token)' clarifies that the token parameter is a wallet credential and 'open paper loan offer' implies the id is the offer identifier. Neither parameter is addressed directly or with format/requiredness detail, so half the burden remains.

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: borrow against an open paper loan offer, with the collateral mechanics spelled out. An agent can distinguish this from other loan tools by the words 'open ... offer', though no sibling (loan_offer, loan_repay, loan_cancel) is named explicitly for contrast.

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

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

It gives clear eligibility preconditions (flagged agents, agents in custody, agents with more defaults than repayments cannot borrow), which tells the agent when the call will fail. It does not, however, point to loan_board for finding an offer id or mention loan_repay as the follow-up, so the routing vs. alternatives 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?

With no annotations at all, the description carries the full burden and does real work: it states the data comes from public chain data, that the market is not operated by the tool provider and nothing is held (custody disclaimer), and that the operation is read only and free. It stops short of describing freshness, caching, or failure behavior for an external chain read.

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 owner and resource before listing fields. It is dense but every clause adds a distinct fact (chain, custody, field list, cost); the parenthetical aside could be split for readability but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description enumerates the return payload (collateral, supplied/borrowed USDG, utilization, max LTV, tagged stock-token collateral), which is exactly what is needed to interpret results. What is missing is how the read behaves against a live external chain — staleness and error paths 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?

The tool takes zero parameters, so the baseline is 4 and nothing needs explaining. The description instead spends its words on the payload fields, which is the right compensation for a parameterless tool.

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 (Longbow's lending markets and vault on Robinhood Chain) and enumerates the data returned — collateral, USDG supplied/borrowed, utilization, max LTV, stock-token tagging. It implicitly separates itself from the internal loan_* siblings by scoping to an external chain and USDG, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is the tool for inspecting external Longbow market state, and 'Read only, free' signals it is safe to call casually. There is no explicit when-to-use, no exclusion of sibling loan tools, and no guidance on refreshing or how often to poll.

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 no annotations, the description carries the full behavioral burden and largely fails it: it never states whether the operation is read-only, what fields are returned, or whether authentication state matters. The parenthetical does at least signal that the required token is a wallet token, which is a small piece of behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

At one short sentence it is concise but under-specified rather than efficient — the brevity comes from omitting required information, not from tight writing. There is no front-loaded purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one required credential parameter, no annotations, and no output schema, the description omits both how to obtain the wallet token and what the call returns. An agent cannot reliably invoke this without external guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% for the single required 'token' parameter, and the schema itself only names it as an untyped string. The description adds that it is a wallet token, which is genuine value, but says nothing about format or issuance (e.g. via wallet_nonce/wallet_login).

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 'Your crew and status (wallet token)' restates the name 'me' in slightly longer form without a specific verb or resource. It does not distinguish this tool from siblings like agents, city_status, or the wallet_login/wallet_nonce group.

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 statement of when to use this tool versus alternatives such as agents, city_status, or wallet_login. The only hint is the possessive 'Your', which weakly implies a self-scoped lookup but gives no conditions or exclusions.

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 no annotations, the description carries the full burden. It does disclose the returned content (price, remaining supply, mechanics), which is useful, but says nothing about auth requirements, whether it is a pure read, or any rate limits.

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 with no wasted words; the key content (price, supply, mechanics) is front-loaded. Minor awkwardness in 'The Operatives drop' and 'how it works' keeps it off a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe returns; it names three data points but omits format, units, and whether the result is static or time-sensitive. Adequate but with clear gaps for a zero-param info endpoint.

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 schema has nothing to document and the baseline of 4 applies. The description correctly implies the call needs no arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (the Operatives drop) and enumerates what it returns: price, supply left, and mechanics. However, the phrasing is jargon-heavy and it does not distinguish itself from the sibling prepare_mint_operative, which covers the same domain, so the agent must infer the 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?

No indication of when to call this versus prepare_mint_operative, nor any prerequisite (e.g., whether a wallet or login is needed first). Usage is only implied by the tool name.

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 no annotations, the description carries the full burden, and it does disclose the most important trait: 'Read only,' so the agent knows nothing is mutated. However, it says nothing about authentication expectations (own-wallet only, per the schema but unstated in the description), whether the call reverts for unregistered wallets, or what the response looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the scope front-loaded and no filler; the only cost is that compression into game jargon trades readability for brevity.

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 usefully enumerates the returned categories, which is the main compensating value here. It still leaves gaps around authorization/eligibility and error behavior, but the read-only nature and the content list cover the essentials for a one-parameter 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 description coverage is 100%, and the wallet parameter is well documented in the schema itself ('Nothing is sent from it... read your balance and allowance and to simulate'). The description adds no meaning 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?

The description enumerates what is returned (ZENI, vehicles, claimable loot, heat, feed verification), so the resource is identifiable, but it frames the tool as 'what a wallet holds' rather than with a clear verb and never distinguishes it from near-sibling readers like `me`, `city_status`, or `get_estate`. The jargon ('Lie Lows', 'feed verification') further blurs the purpose for an agent unfamiliar with the game.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool despite a large sibling set that includes several overlapping read tools. The agent must infer that this is a portfolio/status overview rather than a targeted lookup.

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?

No annotations are provided, so the description carries the full burden. It does clarify meaningful behavior: the result covers both owned and rented fighters and includes a free-to-fight flag, which is useful. However, it says nothing about read-only nature, pagination, or result limits.

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 resource and packs scope plus returned fields without waste. The 'Fight Club:' prefix is slightly ornamental but harmless, so it stops short of a clean 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description partially compensates by enumerating the returned fields, and it clarifies the owner/renter scope. What remains missing (wallet identifier format, pagination) is minor for a single-parameter read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there is one parameter. The description implies wallet scoping ('a wallet plays') but adds no format or identifier details beyond that implication, so it only marginally compensates for the undocumented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear resource and scope: the fighters a wallet plays, explicitly covering both owner and renter roles, and it enumerates the returned fields (rating, stats, record, training, free-to-fight). It does not explicitly contrast itself with the singular fighter_info sibling, so it falls short of full sibling differentiation.

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 guidance on when to call this versus fighter_info or open_fights, no prerequisites, and no exclusions. The agent must infer usage entirely from the name and description.

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 no annotations, the description carries the behavioral burden and usefully discloses the scan cap of 120, newest-first scope, wallet specificity, and inclusion of voided/one-sided fight refunds. It does not clarify read-only nature, permissions, return format, or what happens to winnings beyond the scan limit.

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 a single dense sentence with the core scope and follow-up action front-loaded; every clause adds useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity list tool with no output schema and no annotations, the description covers the key scope, cap, and next step. Minor gaps remain around return shape and scan default behavior, but the essential invocation details are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate; it gives meaning to `wallet` as the collecting wallet and `scan` as scanning up to 120 fights. It does not specify wallet address format, whether `scan` defaults, or its exact unit beyond the cap.

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: Fight Club bet winnings and refunds collectible by a wallet, scoped to newest fights. It lacks an explicit verb like "list" or "returns," but an agent can still distinguish this retrieval tool from prepare_fight_claim.

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 explicitly points to the follow-up action: collect each winnings item with prepare_fight_claim. It gives clear context but does not state when not to use it or what to do if no winnings are found.

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 no annotations, the description carries the full load and does well: it declares 'Free, read only', states every number is read from a chain, and discloses failure behavior ('if a read fails the answer says so'). It also warns that a Tokyo job line reflects a second-opinion grade rather than a certification of the original report, which is real semantic context. It stops short of describing output shape or how the two optional params combine.

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 useful content (counters, decision fields, optional wallet/job, read-only, failure disclosure) is front-loaded reasonably, but roughly half the text is setting flavor and parenthetical asides (docs URL, 'the bar the chain needs (70 for a grade or ruling)'). The caveat sentence is valuable; the framing is not.

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 unannotated aggregate-read tool with no output schema, the description covers what is returned and its safety profile well enough to call it. The main gaps are the output structure and how the optional parameters compose, but nothing essential 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 both parameters are already documented, and the description's 'give wallet' / 'give job' phrasing only restates the schema. The one addition is the interpretation of a job line as a grade of a second-opinion task, which helps but does not substantially extend parameter meaning. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource and the concrete payload: BrainChain counters (jobs posted, paid, refunded, decisions, USDG paid), latest decisions with Jev's confidence, an optional wallet record, and Tokyo job lines. It is a read-aggregate tool, distinguishable from siblings like city_state or reputation once parsed. It loses a point because the verb-and-payload statement is wrapped in 'nervous system / Upper City' framing and never explicitly contrasts itself with the many sibling read tools.

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 optional filtering by wallet and job ('give wallet', 'give job') but gives no when-to-use guidance and no alternatives. An agent cannot tell from this text whether to call nerve_center or city_state / record / job_thread for overlapping data.

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 no annotations, the description carries the full burden; 'Reads your ETH, ZENI and Operatives from the chain' usefully signals a read-only, chain-backed operation and reveals the input domain. However, it does not disclose what happens with an empty/unfunded wallet, what occurs when the token is omitted or invalid, or whether the recommendation is deterministic. Those are the gaps an agent would most want covered for a tool with zero annotation coverage.

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 no filler. The primary outcome is front-loaded, the data sources follow, and the calling instruction is last — a sensible ordering for an agent skimming the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should describe the return: it partially does by saying the result includes the recommended move, a reason, and the tool to call. It does not describe failure modes or the shape of the returned value beyond that, and with no annotations the safety/auth profile is left entirely 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 0%, so the description must compensate, and it does explain both fields: 'wallet' is a wallet address and 'token' is the wallet token used 'if signed in' — that conditional is real value the schema does not convey. It still omits address format (e.g. 0x-prefixed hex) and what happens if a token is passed while not signed in, so compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete outcome: it returns 'the single best next move for your wallet, with the reason and the tool to call,' and names the data sources (ETH, ZENI, Operatives on chain). That is enough to tell it apart from sibling tools like 'opportunities' or 'me', which return data rather than a recommendation that routes to another tool. The verb is implicit ('recommends') rather than stated, which keeps it just 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?

The parenthetical 'Pass your wallet address (and your wallet token if signed in)' implies this is an entry-point/orientation call, but the description never explicitly says when to call it versus going straight to siblings like 'me', 'opportunities' or 'city_status'. There are no exclusions or preconditions (e.g. whether it works for unsigned wallets or wallets with no assets). Usage is inferable, 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 are absent, so the description must carry the full behavioral burden. It describes returned content but says nothing about authentication, side effects, rate limits, or whether the call is read-only. The only behavioral pointer is to a separate accept tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the tool's purpose and immediately followed by the next step. Every word earns its place and there is no 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 no-parameter list tool with no output schema, the description gives the essential content and a next action. However, it omits any differentiation from the similar-sounding 'open_fights' and provides no behavioral context, leaving the agent to infer safety and prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so the schema provides no parameter details to miss. Per the rubric, zero parameters baseline to 4; the description appropriately adds no parameter information because none is needed.

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—fighters waiting for an opponent right now—so an agent knows what data is returned. However, it lacks an explicit verb and does not distinguish itself from the sibling 'open_fights', which could be a similar listing.

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

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

It implies usage by naming the next action ('Accept one with prepare_accept'), giving an agent a clear path after finding a challenge. But it offers no guidance on when to choose this tool over alternatives like open_fights or prepare_challenge, and no exclusions.

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?

No annotations exist, so the description carries the full burden. It usefully discloses a domain convention ('Corner 0 is red, 1 is blue') and that results are current/live, but says nothing about authentication needs, whether the list can be empty, or how to act on a result. For a zero-parameter read tool the burden is modest, so this lands at adequate.

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, zero filler. The scope qualifier ('right now') is front-loaded and the corner-color convention is placed where it will be read before interpreting results.

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 describe returns, and it only partly does: ratings and pool sizes are named, but there is no indication of fight identifiers or how a fight from this list is passed to prepare_bet. The corner mapping helps, but the linkage to the betting flow 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 no parameters, so the baseline is 4. The description correctly adds no parameter guidance because none is needed, and instead spends its words on output semantics.

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 (Fight Club fights) and scope (open for bets right now), plus the data returned (ratings, pool sizes). It reads clearly as a discovery/listing tool, though it never contrasts itself with the obvious sibling prepare_bet.

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?

'Open for bets right now' implies the usage scenario (find a fight to bet on), but there is no explicit when-to-use statement and no mention of the natural follow-up tool prepare_bet. Usage is inferable rather than 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?

No annotations are provided, so the description carries the burden: it does disclose 'Read only' and explains the returned shape (role, status values open/asked/yes given/ready, and claimant type PLAYER/AGENT/HOUSE). It omits auth/wallet requirements, ordering, and pagination, leaving real behavioral gaps for an unannotated tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with 'Seat board' but packed into one long run-on sentence with parenthetical game lists and status enumerations, which makes it denser than necessary. It earns most of its content but could be split for 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?

With no output schema and three optional params, the description does the work of explaining what a caller gets back — per-seat role, status against the chain, and claimant identity — which is the key missing piece. Only auth/leader-wallet behavior is left to the schema's wallet description.

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 id, game, and wallet. The description adds minor value by mapping the game concept to named games (vehicle heist, convoy hit, Ledger job, apartment raid, Night Run), but adds nothing about the wallet parameter or the id filter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource clearly — a seat board of open crew requests across the five team games — and enumerates what each seat carries (role, status, claimant). It also names the sibling it defers to ('Claim one with claim_seat'), so an agent can distinguish the read board from the claim action, though the verb itself is only implied by 'Seat board'.

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 (browse open seats for team games) and names the follow-up alternative explicitly: claim_seat to take a seat. It doesn't spell out when-not-to-use or prerequisites, but for a read-only listing the routing is sufficient.

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?

No annotations exist, so the description carries the burden, and it does real work: it discloses the shape of each returned item (prize, cost, requirements, how-to) and explains the 'house' marker on jobs from the platform's own wallets. It stops short of stating that the call is a pure read with no side effects or how results are ordered.

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 short sentences, front-loaded with the aggregate purpose, then return-item contents, then the caveat about house jobs. 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 and no annotations, the description is the only source of structure, and it adequately describes what each entry contains and the special 'house' flag. A note on whether the list is static or live and how it relates to the individual bounties/jobs tools would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so there is no parameter semantics to document; baseline applies. The description correctly adds nothing about inputs because none exist.

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 the resource concretely (everything earnable/winable) and enumerates the three contents: daily Trial, starter ETH bounties, open ZENI jobs. The phrase 'in one list' implicitly separates it from the per-category siblings (bounties, jobs, trial_board), but no sibling is named outright.

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: 'in one list' suggests this is the aggregate overview before drilling into bounties/jobs/trial_board. There is no explicit when-to-use, when-not, or named alternative, so the agent must infer the 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?

With no annotations, the description carries the burden and usefully discloses that this is board-only, returns no transaction, and requires each joiner to submit their own on-chain confirmation. It does not cover authentication requirements, whether the request can be cancelled, or expiry behavior beyond the schema's 'hours' field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and contains mostly useful details about board-only behavior and the join workflow. It is slightly dense with parentheticals and repeats some schema-level parameter guidance, but no sentence is clearly 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?

For a six-parameter mutation-style tool with no annotations and no output schema, the description covers purpose, board-only behavior, visibility through open_seats, and the joiner confirmation workflow. It leaves some secondary details to the schema, such as hours and already-seated counts, but is sufficient 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 description coverage is 100%, so the schema already documents all six parameters, including 'have' and 'hours'. The description reinforces game, optional ref, and role-number seats, but adds little beyond what the schema already says, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'post an open crew request as the leader' on the 'Seat board'. It also scopes the action with 'board only' and points to the sibling tool open_seats for visibility, so an agent can distinguish it from related crew tools.

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 when this tool applies: it posts to the board, returns no transaction, and joiners must still sign their own yes on chain. It does not explicitly contrast with create_crew, join_crew, or claim_seat, so it lacks full alternative-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?

With no annotations at all, the description carries the full burden and does meaningful work: it declares 'Read only' (safety profile absent from structured data) and discloses that the payout is computed at today's rate with no guaranteed rate and a shrinking pot. It omits whether wallet auth is required and what the response looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with what the tool reports, followed by the decision context and the volatility caveat. 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 zero-parameter read tool with no output schema and no annotations, the description covers what is returned, the decision it supports, and the caveat that values are non-promised. It stops short of specifying auth requirements or the response shape, which is the remaining gap 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate and it correctly adds no parameter talk.

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 resource (the home income pot) and the exact three quantities it returns: current ZENI balance, per-day payout, and days of runway at today's rate. It implicitly separates itself from apartment_quote/prepare_apartment_buy by framing itself as the pre-purchase check, but never names a sibling explicitly.

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

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

'Check before buying an apartment' gives a concrete trigger condition, and 'the pot shrinks as it pays and no rate is promised' warns that the value is a snapshot. It does not name an alternative tool or state when not to call it, so it falls short of full when/when-not guidance.

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