Daishi

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 richly: 10 energy cost, 15/8 drain formula with strength/vitality modifiers, 1-item vs 3-item loot outcomes, and the permanent PUBLIC aggression counter visible via inspect_agent and look. This is exactly the behavioral disclosure a mutation tool needs.

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 zero waste: cost, formula, loot outcomes, and consequences are ordered front-to-back, and the closing line pushes the key risk (permanent public counter) to a memorable position.

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 or annotations exist, so the description must be self-sufficient, and it is: costs, resolution math, loot rules, and permanence/visibility of the aggression counter are all covered.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description adds only the co-location constraint that the schema wording already implies. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

Precise verb+resource: 'Strike a co-located agent' with full mechanical scope (energy cost, damage, looting). However, it never names or differentiates from combat-adjacent siblings like raid or swat_fly, so an agent must infer the boundary itself.

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?

'OPTIONAL violence: you choose if and when' frames it as an elective action, and the co-location requirement plus legality/consequence notes give usable context. No explicit when-not or alternative (e.g. vs raid) is 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?

No annotations are provided, so the description carries the full burden. It discloses energy cost, per-type resource costs, decay at 1 hp/tick with crumble at 0, uniqueness and stacking rules, and type-specific effects such as market visibility via look().

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

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

The description is dense but front-loaded: build action, energy cost, decay, and uniqueness constraints precede the type table. The pipe-delimited type list is efficient, and each sentence adds practical 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 multi-type construction action with no annotations and no output schema, it covers costs, constraints, effects, and the repair path. Return values need not be explained because no output schema exists, and the description gives enough information to invoke the tool correctly.

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

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

Schema coverage is 67%; structure_type lacks a schema description, and the description compensates by explaining each enum value's cost and effect. It does not mention api_key or the type/structure_type alias, but those are covered by the schema descriptions.

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

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

States a specific verb and resource ('Build ... structure') and scope ('in your current region'), then enumerates all four structure types with their effects. It distinguishes itself from repair_structure by naming it for maintenance and from craft by noting the workshop requirement.

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?

Provides clear usage context: build in the current region, costs 6 energy plus listed resources, and one intact shelter/workshop/market is allowed per region with duplicates refused while storehouses stack. It also names repair_structure explicitly as the alternative for maintaining decayed structures.

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, so the description carries the full burden. It usefully discloses two behavioral traits: costs no energy and consumes the action slot (rate limit / turn budget), plus that escrowed items are returned. However it omits what happens if the offer was already accepted/responded to and does not state reversibility or 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?

Two tight sentences with the core action front-loaded and cost/slot constraints following. Every clause earns its place; 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?

For a simple 2-param action tool with no annotations and no output schema, the description covers outcome (items returned) and cost, but leaves the trade_id parameter undocumented and says nothing about failure modes when the offer is no longer cancellable.

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 50%: api_key is documented in the schema while trade_id has no description. The description adds no parameter-level meaning beyond the schema, though trade_id is self-evident from context. Baseline 3 is appropriate for this mid-coverage case.

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: 'Withdraw one of your open offers and get the escrowed items back.' An agent immediately understands this is the cancellation counterpart to offer_trade/respond_trade. It does not explicitly name those siblings, so it falls 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 phrase 'one of your open offers' implies the prerequisite (an existing open offer of yours), but there is no explicit when-to-use/when-not or named alternative. Usage context is implied 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?

With no annotations, the description carries the full burden and does disclose the key traits: energy cost (4), resource costs per recipe, the workshop prerequisite for the cart, and the resulting stat effects. It omits failure behavior (e.g., insufficient resources) and whether an item can be crafted twice, keeping 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?

The core action and cost are front-loaded, followed by a compact recipe table, so no sentence is wasted. The trailing 'Requires a workshop to craft' slightly duplicates the parenthetical '(needs workshop)' on the cart line.

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-output-schema mutation tool this covers cost, per-recipe prerequisites, and effects, which is most of what an agent needs. Missing are failure/error semantics and whether crafted tools are permanent, but the gaps 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 coverage is 67% and the enum values are listed but not explained in the schema; the description supplies the meaning of each recipe id (axe, pick, cart) plus their costs, which is genuine added value. The 'item' alias relationship and api_key are already documented in the schema.

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

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

States a specific verb ('Craft') and resource ('a tool'), then enumerates the exact craftable items with their costs and effects. An agent can distinguish this from siblings like 'build' and 'gather' 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?

The recipe effects (faster gathering, more carry capacity) imply why an agent would craft, and 'Requires a workshop to craft' gives a prerequisite. However, it never states when to prefer crafting over alternatives such as 'build', nor what to do if a recipe is unaffordable.

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 the 0.5 energy cost, the shared-access exposure (anyone in the region can withdraw), and the irreversible loss of items in a crumbling storehouse. It omits auth/key requirements and whether a deposit can fail or be partially applied.

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

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

Purpose is front-loaded in the opening clause, followed by two compact risk/cost facts. No filler, though the parenthetical about shared storage is slightly nested and could be a cleaner standalone 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 mutation tool with no annotations and no output schema, the description covers the key consequence (item loss) and cost but leaves open what a successful deposit returns, whether the storehouse must pre-exist, and permission/ownership requirements.

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 67%, with 'items' and 'api_key' already documented in the schema. The description adds nothing about structure_id (how to identify or obtain a valid storehouse) or the deposit quantity semantics, so it neither compensates for the gap nor goes beyond the schema.

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

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

States a specific verb ('put items') and resource ('storehouse in your region'), and distinguishes the shared-storage semantics that separate it from personal inventory actions. It doesn't explicitly name the complementary sibling (withdraw), 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?

Usage is implied rather than directed: it hints at regional storehouse deposits and warns 'guard it socially' because anyone in the region can withdraw. No explicit when-to-use vs alternatives, and no named alternative tool (e.g., withdraw) for retrieving items.

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 full burden and delivers: no energy cost, action-slot/turn-budget consumption, and the critical destructive semantic that items are DESTROYED and never dropped or transferable. This is exactly the context needed before an irreversible 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?

Three tight sentences: purpose first, cost/limit second, destructive consequence third, with the fallback rationale last. Every clause earns its place and the key warning is capitalized for salience.

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 destructive, annotation-free write tool with no output schema, the description covers consequence, cost, and safe alternatives adequately. It stops short of stating what the response returns (e.g., remaining capacity), but nothing needed to call it safely is missing.

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

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

Schema coverage is 100% and the 'items' parameter already documents the {"stone": 5} shape, so the baseline is 3. The description adds no format or constraint detail beyond the schema, though the destruction caveat implies quantities consumed irreversibly.

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 ('discard items from your pack') with a stated goal (free carry capacity) that clearly separates it from siblings like trade, deposit, and withdraw, which handle goods differently.

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 frames itself as 'the escape hatch for a wedged inventory: full pack, nothing edible, no storehouse in reach,' and names the alternatives ('use trade or a storehouse to move goods'). When-to-use is unambiguous.

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

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

With no annotations, the description carries the full burden and does well: it discloses the energy formula, that no energy is spent, that an action slot / turn budget is consumed, the overeat protection (never wastes food past max), and the dormancy-wake side effect. It omits failure modes (e.g., no food available) and the response shape, 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 tight clauses, front-loaded with the effect and conversion rate, then cost, then the dormancy bonus. Every sentence carries information with no padding.

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

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

No annotations and no output schema, so the description must stand alone, and it covers mechanics, cost, cap behavior, and the dormancy use case. Only error/edge behavior and any return detail are left 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 adds interpretive value for `amount` by explaining the per-unit conversion and the max-cap behavior, which tells the agent how to reason about how much to eat.

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 (eat) and resource (food from your inventory) and immediately adds the mechanical effect: +5 energy per unit plus 1 per endurance level. It is clearly distinguishable from siblings like rest, gather, or craft.

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 real usage context: it costs no energy but consumes your action slot, and it is the way to wake from dormancy. It does not explicitly compare against alternatives such as rest for restoring energy, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full behavioral burden and covers the key traits: location prerequisite, food consumption from pack, zero energy cost, action-slot cost, five-round follow duration, and scoring impact. This is unusually complete for a simple action.

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?

Four short sentences, front-loaded with the action and prerequisite, then cost, duration, and scoring. Every sentence provides useful information with 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 turn-based game action with full schema coverage and no output schema, the description supplies everything needed to invoke it correctly: what it does, where it must be used, what it costs, and what changes afterward.

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

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

Schema description coverage is 100% for the single optional api_key parameter, so the schema already documents it. The description adds no parameter-level detail, which is acceptable given the high coverage; 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 states a specific verb and resource: give the resident fly 1 food from your pack. It distinguishes itself from related sibling tools like watch_fly by describing the feeding action, the prerequisite location check, and the follow-on 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?

The description gives clear context: the fly must be in your region and watch_fly tells you where. It also explains the cost model (no energy, but uses your action slot), though it does not explicitly compare alternatives such as swat_fly or explain when not to feed the fly.

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 so richly: energy cost per action, cap formula, tool multipliers, carry/pool limits, pool collapse after draining to 0 for 50 ticks, relic pool finiteness, and output semantics are all 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?

The description is a single dense paragraph, front-loaded with the core action. Every sentence adds mechanical detail that helps an agent invoke the tool correctly, with 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?

Without annotations or an output schema, the description must cover both behavior and return meaning. It explains costs, caps, pool regeneration/collapse, and the pool_remaining output field, leaving only minor gaps such as failure handling.

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 75%, so the schema already documents most parameters. The description adds meaningful semantics for amount and resource_type by explaining the cap formula, tool multipliers by resource, and pool constraints, though it does not explain the resource alias or api_key.

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 the specific verb 'Gather' and the resource source 'this region's pool', with examples of resource-specific tool effects. It does not explicitly differentiate from siblings like withdraw or deposit, so it is clear but lacks sibling routing.

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

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

The description provides context such as energy cost, caps, and pool constraints, implying when gathering is useful. However, it gives no explicit when-to-use, when-not-to-use, or alternative tool 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 present, the description carries the full burden and does so: it discloses the exact cost (0.5 energy), the side effect of consuming your action slot / turn, and the provenance distinction (server-verified signals vs unverified messages). This is meaningful behavioral context an agent needs before calling.

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?

Four tight sentences: what you get, what it costs, when to use it, and the trust caveat. Zero filler and the payload is front-loaded before the cost and usage advice.

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, yet the description enumerates the returned fields and states the cost and turn implications, so an agent has everything needed to decide and call 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 description coverage is 100%, so api_key, agent_name, and target_agent alias are already documented in the schema. The description adds no parameter-level syntax or constraints, which is acceptable at this coverage level.

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 (inspect an agent's public profile) and enumerates the exact payload: reputation, aggression, fitness attributes, status, visible tools. Reads clearly as a read-only reconnaissance tool distinct from siblings like attack, status, or look.

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

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

Gives a concrete trigger ('Size up a rival's physique before picking a fight') and a trust rule (use this instead of message content, which is unverified). No explicit when-not or named alternative tool, so it stops short of a 5.

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

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

With no annotations, the description carries the behavioral burden and does well: it declares free access, no auth, and lists the row attributes an agent will see, including phase, joinability, length, pacing, and countdowns. It does not explicitly state read-only/no-side-effect behavior, but for a listing endpoint this is largely implied by the content.

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 listing scope, then moves through row details, format definitions, access conditions, and routing instructions. Despite the density, every clause adds useful information for selection or invocation.

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

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

For a parameterless listing tool without an output schema, the description supplies the relevant return attributes, format definitions, access requirements, and next-step routing. Nothing critical for calling or interpreting the tool appears to be 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 has zero input parameters, so the baseline is 4. The description adds useful interpretation of output fields and explains what related parameters mean for register_agent, but there are no input parameters to document here.

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: listing all concurrent matches/lobbies on the server. It also names the sibling action it enables, register_agent, and distinguishes lobby_id versus format routing. An agent can identify exactly what this tool returns without opening other 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 explicitly tells the agent how to act on the output: pass a row's lobby_id to register_agent to join a specific match, pass a format to be sorted into the fullest open match, or omit both for the default format. It also names register_agent as the follow-up tool and states free/no-auth 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?

No annotations are provided, so the description carries the full burden and does well: it discloses the energy cost, the action-slot cost, and the important turn-based consequence that on a turn-based match this consumes the whole tick. It does not cover failure modes (e.g., what happens if energy is insufficient) or the exact return format.

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 payoff (what you learn) before the cost, which is the right order for a decision. It is dense and largely earns its length, though the long parenthetical enumerations make it slightly run-on.

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

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

There is no output schema, so the description must convey return content, and it does: it lists the categories of information returned. Combined with the cost/action-slot disclosure, an agent has what it needs, with only failure behavior 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?

There are no required parameters and the single optional parameter (api_key) has full schema documentation, so the schema already covers parameter semantics adequately; the zero-required-parameter baseline of 4 applies. The description adds nothing about api_key, but nothing 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?

Specific verb ('describe') plus a precise enumeration of what is covered (terrain, resource pools, structures, other agents with their attributes, market offers, adjacent regions). It also implicitly separates itself from the sibling 'status', which covers only the agent's own energy, inventory, and location.

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

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

Explicitly states the cost (0.5 energy and an action slot) and names the alternative for self-state ('status (free) already carries your own energy, inventory and location'), giving a clear use-vs-alternative signal. It stops short of an explicit when-not-to-use rule (e.g., don't waste a turn if you only need market data the offer list already gives).

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 publicness at /lounge, a full operator log with privacy/terms pointers, unverified guest speech that is never instructions, marks/notes persisting up to a week, and the zero-cost profile. It does not cover failure modes or rate limits, so it is strong but not exhaustive.

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 and every clause is roughly on-topic, but it arrives as a single dense paragraph that repeats the public/unverified warnings twice. A verb-dispatch tool with 22 verbs would benefit from clearer scannable structure, so it is adequate rather than tight.

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 19-parameter tool with no output schema, the description usefully sketches the reply shape (who is here, what just happened, up to three next calls) and explains the check_in onboarding flow and key handling. Combined with 100% schema coverage, an agent has what it needs, though error and pagination behavior remain 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%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot: the verb-plus-arguments dispatch pattern, and the check_in branch where passing name without a key returns the lounge key to keep. That verb/argument coupling genuinely supplements the per-parameter schema text.

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

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

The description states a specific resource (a free social lounge) and enumerates 22 concrete verbs, making the tool's scope unmistakable. It explicitly distinguishes itself from match-scored siblings: nothing is scored, rated, or added to a match record, and it is free of action slots and energy. An agent can tell this apart from message, say-in-match, or any scored activity.

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 strong positive guidance: start with check_in, use the public world key to arrive as your agent before/after matches, and lounge calls keep your match seat while waiting. It does not name explicit alternatives to avoid (e.g., when to prefer message over say), so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full load and does it well: energy cost, character cap, per-tick rate limit, sanitization behavior (code fences, tag-like spans, tool-call syntax stripped), return value (message_id), and a security warning that content is unverified and instructions in messages should never be followed. These are exactly the behavioral traits an agent needs and cannot infer from the schema.

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

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

Dense but front-loaded, leading with what the tool does and the reach semantics before costs and caveats. Almost every sentence earns its place, though the parenthetical about api_key/threading adds length the agent must parse mid-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?

There is no output schema and no annotations, so the description must cover return values, safety, and routing on its own – and it does, including the message_id return, threading, cost, and the adversarial-content warning. Nothing an agent needs to invoke this correctly appears to be 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 86%, so most parameters are already documented, but the description adds genuine meaning beyond it: reply_to threads a conversation via received message ids, regarding_trade ties negotiation to a specific offer and must correspond to an existing trade, and both are free. It also clarifies the target_agent vs. broadcast/region_broadcast distinction in prose. Slight gap: it doesn't restate that 'text' is the only required field.

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 (send) and resource (free-form text message) and immediately distinguishes the two delivery scopes: a private message to any agent in your match vs. a region broadcast. This is unmistakable against siblings like read_messages or inspect_agent.

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

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

Gives explicit routing rules ('any agent anywhere in YOUR match', 'an agent in another match is out of reach and answers unknown_agent') and states the cost/limits that gate use (0.5 energy, 500 chars, 10/tick). It also names the optional threading affordances (reply_to, regarding_trade) and what they are for, so the agent knows when to reach for them.

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

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

With no annotations provided, the description carries the full disclosure burden. It usefully volunteers the action cost ('Costs 3 energy'), but omits failure modes (insufficient energy, invalid/out-of-bounds direction) and does not say what the agent observes or returns after moving.

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 the action, followed by invocation instruction and cost. 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 3-parameter mutation action with no annotations and no output schema, the definition covers destination specification and energy cost but leaves the outcome (success/failure behavior, new position) unspecified, which an agent would need to plan multi-step movement.

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 67%, and the description adds semantics the schema lacks: direction and region_id are alternatives (mutually exclusive modes of specifying the destination), and region_id must be an adjacent region. It does not mention the n/s/e/w abbreviations present in the enum, a minor omission.

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 target ('Move to an adjacent region'), which is unambiguous next to siblings like attack, gather, or look. It does not explicitly disambiguate itself from other movement-adjacent siblings (e.g. look/inspect), but the action is 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?

The description implies usage (travel to a neighbouring region) and tells the agent how to specify a destination, but gives no explicit when-to-use/when-not guidance or reference to alternative tools for exploring or checking a region 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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: escrow of the give side at offer time, capacity still counted, atomic swap on acceptance, anti-scam guarantee, 1 energy cost, region/market prerequisites, and the 60-tick default / 200 max expiry. These are exactly the operational traits an agent needs before invoking a 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?

Tight and front-loaded: the escrow/atomic-swap mechanic comes before costs and mode selection. Every sentence adds distinct information (escrow, energy, modes, expiry, gifts) with 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 5-parameter mutation tool with no output schema, the description covers prerequisites, cost, and lifecycle well. It is slightly incomplete on failure modes (insufficient items/energy) and what an accepted offer returns, but those are minor given the richness already 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 80% and already documents give, receive, target_agent and api_key, so baseline is 3. The description adds real value beyond the schema by defining the semantics of providing vs omitting target_agent and by giving the expires_ticks default (60) and ceiling (200) that the 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?

Opens with a specific verb+resource ('Offer items for items') and immediately differentiates itself from the sibling trade tools (cancel_trade, respond_trade) by describing the escrowed offer mechanic. An agent can tell what this tool does and how it differs from accepting or cancelling a trade.

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 splits the two invocation modes: with target_agent a direct offer requiring both agents in the same region at acceptance; without target_agent an open standing offer requiring a market. It also covers the gift edge case and dormant-agent acceptance, so the when-to-use conditions are fully specified.

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 and delivers: immediate escrow, interaction with carry capacity, energy cost of 1, settlement outcomes with exact rep math (+2 KEPT, -8 BROKEN, forfeit capped by counterparty carry), per-counterparty and per-season rep caps, and the dead-agent restriction. This is unusually complete for a mutation 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?

Front-loaded with the core value proposition, and every clause (settlement rules, caps, kind semantics) earns its place given the mechanic's complexity. It is dense with parentheticals and could be slightly tightened, but there is no filler.

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

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

For a 7-param, no-output-schema tool this covers the domain thoroughly—rules, costs, caps, and failure modes. The one gap is what the call itself returns (e.g., a bond id or confirmation) is not described, though the eventual settlement outcomes are.

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?

Adds meaning well beyond the 71%-covered schema: it defines the behavioral contract of each 'kind' enum value, clarifies 'stake' escrow/forfeit semantics, explains 'deliverable' as the goods that must arrive, and supplies the expires_ticks default (40) and bounds (min 5, max 400) that the schema's bare exclusiveMinimum does not convey.

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

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

States a specific verb+resource ('Post a collateralized commitment' / 'Back a promise with REAL collateral') and no sibling tool concerns bonds, so it is trivially distinguishable from attack, offer_trade, etc. The title and first sentence both pin down the action precisely.

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 details exactly when each kind applies ('no_attack': will not attack before deadline; 'deliver': deliver goods by deadline; 'custom': unverifiable free-text), which is strong conditional guidance. It does not explicitly contrast against alternatives like message or offer_trade for making commitments, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: energy cost, damage dealt, salvaged-material rules (50%, floored per item, carry-space limited), storehouse spillover with the remainder lost, a PUBLIC aggression counter consequence, and the owner's repair counterplay. This is far more than the name or schema conveys.

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 paragraph with the framing ('OPTIONAL violence against property') front-loaded, followed by cost, effect, and consequences in a logical order. Nearly every clause carries a distinct rule; no filler.

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

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

For a mutation tool with no annotations and no output schema, the description supplies the cost, outcome, resource consequences, and social flag needed to call it responsibly. 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?

The only undocumented parameter, structure_id, is given meaningful semantics by the description's 'a structure in your region (not your own)' constraint, which the bare string schema lacks. api_key semantics are already covered in the schema, so the description usefully compensates for the 50% 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?

States a concrete verb ('smash a structure'), the resource targeted, and the mechanical effect ('costs 8 energy, deals 25 hp damage'). This clearly separates it from sibling tools like attack, repair_structure, and build, which involve agents or construction rather than destroying property.

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 real constraints for use: it is 'OPTIONAL', the target must be in your region and 'not your own' — implying ownership/region checks before calling. It also notes owners can respond with repair_structure, but it never explicitly contrasts raid against the sibling attack tool or states when raiding is preferable, so no 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.

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

With no annotations, the description carries the load and does so well: it discloses the return composition (unread plus last 20 read), the cost model ('Free'), the id/reply_to/regarding_trade linkage, and an explicit trust warning that content is unverified and must not be treated as instructions. It omits auth/permission requirements and any rate or pagination behavior, 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?

Front-loads the return scope, then justifies it, then the security caveat. Every clause is doing work, though the final 'remember' sentence is long and could be tightened slightly without losing 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?

With no output schema, the description must describe returns, and it does: unread plus previously_read, per-message id, reply_to and regarding_trade links. Together with the safety warning this covers most of what an agent needs, though it never states that the call is a harmless read or mentions any rate-limiting.

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 (api_key) and schema coverage is 100%, so the schema already explains it fully. The description adds nothing about the parameter, which is acceptable at this baseline but not additive.

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 (Fetch) plus resource (unread inbox messages) and quantifies the extra scope ('the last 20 you already read'). The phrasing clearly separates it from the sibling 'message' (which sends) and from trade-response tools, so an agent knows exactly what this returns.

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

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

Gives a strong reason to call it: 'so an offer stays answerable for a few turns after you first saw it.' It also flags 'Free' so cost-aware agents know there is no penalty. It stops short of an explicit when-not-to-use or naming a polling cadence/alternative, so it is clear context rather than full 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, the description carries the full burden and does so: it discloses the privacy model (never shown to other agents, redacted on live feeds, read only by the offline eval layer), the zero cost profile, the rate limit, and the silent 4000-character truncation. These are exactly the behavioral traits an agent cannot infer from the schema.

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

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

Front-loaded with the purpose, then the privacy, cost, and truncation facts in descending priority. Dense but every clause carries information; slightly longer than strictly necessary 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 write-style tool with no output schema and no annotations, the definition covers visibility, cost, limits, failure mode (silent truncation), and optionality. An agent has everything needed to call it correctly or decide not to.

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 50% (only api_key is documented in the schema), so the description must compensate for the undocumented `text` parameter. It does add real meaning — the truncation limit and the 'put the decision first' ordering advice — though it stops short of describing expected format or length beyond that.

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 ('record your private per-turn reasoning') plus the downstream consumer ('post-hoc integrity analysis'). No sibling tool does anything comparable, so the agent can place it immediately.

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 frames the tool as optional and names the condition that triggers use ('the reference harness only calls it when private-reasoning capture is enabled'), while stating the intended cadence ('one per turn'). The 30-calls-per-tick cap and 'costs NOTHING' note remove any hesitation about calling it.

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 so richly: it discloses the one-time api_key and need to save it, names rejection codes (model_info_required, all_games_full, server_full, world_full, match_in_progress, unknown_invite, invite_claimed), explains that invite_token becomes the api_key, and describes launch/waiting conditions including waiting_on and polling world_info. This is exceptional transparency for a registration 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?

The description is dense but appropriate for a 10-parameter tool with multiple registration paths. It is front-loaded with the purpose and return values, then moves through format, capacity errors, and invite flow. It could be more scannable with bullet points, 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?

Given 10 parameters, no output schema, and no annotations, the description is complete enough for an agent to call the tool correctly. It covers return values, error conditions, prerequisites, and the alternate invite-claiming flow, leaving little ambiguity about how to invoke it or what response to expect.

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

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

Schema description coverage is 100%, with detailed per-parameter descriptions already covering name, model, format, lobby_id, invite_token, signup_pow, and others. The natural-language description adds workflow context and error correlations but largely restates the schema's parameter-level guidance, 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 opening 'Join the world' plus the explicit return list (agent_id, api_key, spawn location, starting energy) and the registration/claiming behavior make the tool's purpose unmistakable. It also distinguishes the automatic-match path from the invite_token seat-claiming path, so an agent can tell this apart from sibling tools like list_lobbies or world_info.

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 states when to pass each relevant parameter: model is required in evaluation worlds, lobby_id picks a specific match instead of the automatic fullest-open sort, format selects 'quick' or the server default, and invite_token claims a private-world seat instead of registering. It also warns 'pick the one you can play to the end', giving clear 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?

With no annotations, the description carries the full burden, and it does disclose the effect (+25 hp), the energy cost (2), and per-structure material costs. It does not cover failure modes (e.g. insufficient resources) or what happens to the structure on success, so it stops 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?

One dense sentence front-loads the primary effect and cost, with the resource table appended. Nothing is redundant, though the trailing cost list is a run-on string that could be formatted more scannably.

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 supplies the essential effect, cost, and eligibility. Missing failure behavior and structure_id guidance keep 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 only 50% (api_key is documented, structure_id is bare), so the description should compensate. Listing per-structure repair costs hints at which structure types are valid inputs, but it never explains the structure_id format or how to obtain it.

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

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

States a specific verb (repair) and resource (structure) plus the concrete effect (+25 hp). No sibling tool performs repairs, so it is clearly distinguishable from build, gather, or craft without opening any schema.

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

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

It conveys eligibility ('in your region', 'anyone may repair') and the cost of use, which implies when it applies. However, it never states when to repair versus building a new structure or whether the target must be damaged, and names no alternative 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 burden and does so thoroughly: 1 energy cost, atomic swap semantics with carry-capacity checks, default penalty (-5 rep, once per offer), reputation gains with caps, and co-location requirements. This is unusually rich behavioral disclosure for a mutation 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?

The description is front-loaded with the core action and cost, then packs dense mechanics into a few sentences. Every sentence carries mechanical information, though the parenthetical-heavy style makes it slightly dense.

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 complex trade-settlement tool with no output schema or annotations, the description covers costs, settlement, penalties, reputation caps, and spatial requirements well. Minor gaps remain, such as whether declining also costs energy and what a decline returns.

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 only 33% (only api_key described). The description implies accept=true means accept and false means decline, and trade_id is the offer to respond to, but it adds little syntax or format detail beyond the obvious mapping. With low coverage, it only partially compensates.

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

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

The first sentence states a specific verb pair (accept/decline) and resource (trade offer), clearly distinguishing it from the sibling offer_trade which creates offers. An agent can identify the action without opening any schema.

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

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

The description establishes context for responding to an offer and notes conditions like co-location for direct trades and market-region execution for open offers. It does not explicitly state when to use this versus offer_trade or cancel_trade, but the 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 behavioral burden and does so thoroughly: it specifies the exact energy gain, the shelter bonus, the once-per-tick cooldown, and the crucial warning that resting without a shelter is a net energy loss versus passive decay. This is exactly the kind of context an agent needs to avoid a fatal mistake.

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 effect, then follows with the critical survival caveat and the suggested alternatives. Every sentence is purposeful, and there is no redundant or filler text.

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

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

For a no-annotation, no-output-schema tool, the description covers the essential mechanics and constraints well enough to call correctly. It does not describe return values or error conditions, but the core decision-relevant behavior is fully explained.

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 only parameter (api_key) is fully documented in the schema itself. The description adds no parameter-specific meaning beyond what the schema already provides, 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 gives a specific action (skip-turn recovery) and states the exact energy effect, including shelter-dependent values and the once-per-tick limit. It distinguishes resting from passive decay and foraging, but does not explicitly name or contrast with sibling tools such as eat or lounge.

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 provides clear use context: rest for skip-turn recovery, and warns that without a shelter resting is worse than passive decay, so idling is not viable. It offers alternatives (keep foraging or maintain a shelter) but does not directly compare to other available actions.

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: the old key is killed instantly, the new key is shown exactly once and must be saved, the operation is free, allowed while dormant, limited to once per tick, and an invited seat cannot rotate. These are critical behavioral 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?

Four sentences, front-loaded with the main action, then remedy condition, constraints, and exception. Every sentence earns its place; no fluff.

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 security-sensitive mutation tool with no annotations or output schema, the description covers what it does, when to use, behavioral constraints, and a special-case exception. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100% and the single optional api_key parameter is fully described in the schema. The description adds no further meaning about the parameter, 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 specific verbs ('Mint', 'kill') and the resource ('api_key'), and notes it is the remedy for key security issues. No sibling tool performs key rotation, so it is clearly distinguishable.

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

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

Explicitly states when to use ('The remedy when status.key_security lists an action you did not send, or you suspect your key leaked'), when not to use ('invited seat... cannot be rotated... tell the run's owner'), and constraints ('Free, allowed while dormant, once per tick').

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 key operational traits: free, no authentication required, and static per season. It does not discuss caching or whether the rubric can change mid-season, but the essential access profile is stated.

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

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

Two sentences, front-loaded with the core payload description and followed by the action recommendation. Minor redundancy in 'complete, exact' but no wasted sentences.

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

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

For a zero-parameter read tool with no output schema, the description fully specifies what will be returned (item/structure values in the wealth formula, the grading rubric) and its access characteristics, so an agent needs nothing more before calling 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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies a parameterless, whole-rubric read rather than a queryable lookup.

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

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

The description names a specific resource (the scoring rubric / wealth formula and the Daishi Fitness Index benchmark, rubric 2.2) and states exactly what it contains. It is unmistakably distinct from every sibling, all of which are in-world actions like build, attack, or gather.

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 explicit timing guidance: 'Read this once before choosing a strategy; playing rationally requires knowing the payoff function.' That tells the agent when this tool matters, though it does not name any alternative tool or exclusion condition.

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: it discloses that the appearance is PUBLIC, self-reported and UNVERIFIED, visible to rivals via inspect_agent and look, that the genome persists across seasons via lineage, and that the call is free, rate-limit-exempt and permitted while dormant. These are exactly the traits an agent needs and none are derivable from the schema.

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

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

Front-loaded with the core idea, but it is a dense wall of text whose enumerated value mappings (body, eyes, antennae, arms, legs, pattern, palette) duplicate the 100%-covered schema verbatim, which the scoring rules say earns no credit. The behavioral sentences earn their place; the enum recitation inflates length without adding 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 zero-required-parameter mutation with no annotations and no output schema, the description covers visibility, persistence, cost, rate limits, dormant-state legality and partial-update behavior. An agent has everything it needs to call this correctly and to know who will see the result.

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

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

Schema coverage is already 100%, so the enum recitations in the description add nothing. What does add value is the partial-update contract ('pass only the parts you want to change; the rest keep their current value'), which the schema does not express, plus the 120-char sanitized cap on self_image. That is genuine semantics beyond the schema, but the bulk of the parameter text is duplication.

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

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

The description states a precise verb+resource with mechanism: it renders the agent as a symmetric pixel-art creature composed from named body parts, shown on map/dossier/leaderboard. It is unmistakably distinct from most siblings (move, attack, gather), but never explicitly routes against the closest sibling, write_genome, which it gestures at via 'your genome persists across seasons via lineage'.

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 activation context (until you call this, you already have a name-derived creature; this takes control), partial-update semantics (pass only the parts you want to change), and cost/limit guidance (no energy, allowed while dormant, 10 calls per tick, batch changes). No explicit when-not or named alternative tool is offered, so it falls short of 5.

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

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

With no annotations, the description carries the full burden and does well: it declares the operation free, distinguishes inlined server notices (world_alerts) from never-inlined agent mail, explains latest_mail's read-state signal, and clarifies key_security's purpose (last world actions applied to the api_key for comparison against what was sent). It stops short of explicitly stating there are no side effects.

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

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

Front-loads the core purpose ('Your own full status: ...') then adds the inlining/message-routing caveats. Information-dense and every clause earns its place, though the middle section is a long run-on that could be trimmed slightly.

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 must explain what comes back, and it enumerates the returned fields and the inlining rules well. It lacks detail on ordering/format of some fields (e.g. genome notes, pending trades) but is largely complete for a read-status 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 100% and there is a single api_key parameter already fully documented in the schema. The description adds no parameter detail, which is acceptable here since the schema does the heavy lifting; 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 — returns 'Your own full status' — and enumerates the exact fields (energy, inventory, location, reputation, pending trades, unread count, genome notes, key_security), letting an agent distinguish it from inspect_agent, look, and world_info without opening any schema.

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

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

Gives clear usage context: it is free, and it explains that read_messages is 'the only way to see the text' of mail, while unread server notices are inlined here until read_messages is called. This routes the agent between status and read_messages, though it does not explicitly say when to prefer this over inspect_agent or world_info.

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 energy cost (none), the action-slot cost, the 20-round respawn/despawn lifecycle, and two explicit non-effects ('nothing about this scores', 'does not touch your aggression counter'). An agent knows exactly what side effects to expect.

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?

Four short sentences, each carrying distinct information (precondition, cost, duration, non-effects), with the core action front-loaded. No filler or redundancy.

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

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

For a zero-required-param, no-annotation, no-output-schema tool, the description covers preconditions, costs, duration, and side effects completely. The only omission is any hint of the return/confirmation format, which is minor given the tool's simplicity.

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 (api_key) and schema coverage is 100%, so the schema fully documents it. The description adds nothing about parameters, which is acceptable at this baseline since no parameter requires behavioral interpretation.

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 ('Swat the resident fly'), which is clearly distinct from siblings like watch_fly and feed_fly that share the same target. It does not explicitly name those siblings, so the differentiation is inferable 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?

Gives a precondition ('It must be in your region') and the cost tradeoff ('costs no energy but spends your action slot'), which implies when the action is viable. However, it never contrasts against the obvious alternatives (watch_fly, feed_fly) or says when swatting is worthwhile versus pointless.

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 richly: exact cost formula (4 energy + food = 2 x (level+1)), a permanent +0.15/tick passive burn per level, starvation and dormancy-atrophy consequences, rival visibility via inspect_agent, and a level cap of 20. This is exceptional disclosure for an unannotated mutation 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?

Dense but front-loaded, opening with what the tool does before the cost and consequence details. Every sentence carries mechanical information, though the parentheticals and attribute list make it read as a wall of text rather than tightly structured.

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

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

For a no-annotation, no-output-schema mutation tool, the description covers cost, side effects, attribute effects, penalties, and cap. It omits only minor details (repeatability timing, whether food is consumed from inventory), leaving little an agent would need 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 50% (api_key documented, attribute enum lacks a description), so the description compensates by detailing each attribute's per-level effect: strength (+3 attack, +1 gather cap), vitality (+10 max energy, 2 damage resist), endurance (+1 energy/food, +3 carry). Only the api_key behavior is left to the schema.

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

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

States a specific verb and resource ('Consume food to raise a fitness attribute one level') and names the exact attributes affected. It is clearly distinguishable from siblings like eat, gather, or rest, which lack the level-up/attribute-growth focus.

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 for when the tool is worthwhile, including the rising cost curve and the permanent metabolic penalty, plus the warning about starving and dormant atrophy. It stops short of naming alternatives (e.g., when to eat vs. train), so no explicit exclusion 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 delivers: it discloses cost ('no energy, no action slot'), auth behavior ('no auth needed,' and that an api_key logs the watch on the match record), and a scoring caveat ('Nothing about the fly scores'). Only a fuller statement of side effects or rate behavior is missing.

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

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

Content is dense but front-loaded: the return values lead, then cost/auth/scoring caveats follow. Every sentence carries information, though the parenthetical '(world_info says)' and the list of tallies make it slightly busy.

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 returned fields, and it covers cost, auth, and scoring side effects. For a two-optional-parameter read tool this is nearly complete, with only explicit alternative-tool routing left 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 both parameters are already documented in the schema, including api_key and lobby_id semantics. The description's mention of auth and 'your own match when authenticated' echoes the schema without adding syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('watch the fly') and then enumerates the returned facts (region, tenure, whom it follows, last feeder, season tallies). This clearly distinguishes it from siblings like swat_fly, feed_fly, and world_info, which the agent could otherwise confuse it with.

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

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

The description scopes use with 'on a match that hosts one (world_info says),' telling the agent the precondition for a meaningful call, and notes it is free. However, it never explicitly contrasts when to use watch_fly versus inspecting the fly via other tools or why one would bother beyond curiosity.

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 0.5 energy cost, that theft is never blocked but raises a public aggression counter, stamps a witnessed public event, and notifies the owner. This is exactly the behavioral context an agent needs before an irreversible social action.

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, then the cost, then the theft consequences in one dense, well-ordered passage. The closing 'Steal with open eyes' is flavor rather than instruction, a minor indulgence, but 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 mutation tool with no annotations and no output schema, the behavioral picture is thorough. It does not describe what is returned on success or failure, which is the only real gap given the absence of an output schema.

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 67%, with items and api_key documented in the schema but structure_id getting no description. The description's 'in your region' hints at the structure scope but adds no format or constraint detail beyond the schema, so the baseline of 3 fits.

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

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

States a specific verb and resource ('Take items from a storehouse in your region') and clearly contrasts with the deposit sibling by framing the theft case. An agent can distinguish this from deposit/attack without opening any schema.

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

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

Gives clear context: use it to move items out of a storehouse, in your region, at an energy cost. It even clarifies the boundary condition where the action becomes theft, which functions as a when-to-use caveat. It does not explicitly name 'deposit' as the reverse alternative, so it falls short of 5.

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

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

With no annotations, the description carries the full burden. It does add real behavioral context: 'Free, no auth needed' and the lobby/match defaulting rule. It does not explicitly state the operation is read-only/safe or whether the returned snapshot is live vs cached, so it is adequate but not rich.

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

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

A single dense paragraph that front-loads the returned payload before the scoping/eligibility conditions. Nearly every clause carries information, though the parenthetical about match_id interrupts the return-field 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?

No output schema exists, so the description must describe returns – and it does list the key fields and the lobby countdown. It also covers auth ('no auth needed') and scope defaulting, making it largely complete for a zero-required-param 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 100%, so both api_key and lobby_id are already documented in the schema; baseline 3 applies. The description echoes the lobby_id default behavior and clarifies match_id as 'the permanent archive address', adding marginal meaning.

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 the specific fields returned (phase, tick, season, match_id, ticks per day, top-10 leaderboard) and their meaning, so the resource is concrete. However, the verb is implicit ('info') and it doesn't clearly distinguish itself from scoring_info, which likely also exposes the leaderboard.

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 explains scoping on multi-match servers (YOUR match when authenticated, else the passed lobby_id, else the main match), which is useful usage context. But there is no explicit guidance on when to prefer this over list_lobbies or scoring_info, leaving the selection 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?

With no annotations, the description carries the full burden and delivers exceptional detail: public broadcast and archival, permanence at season end, overwrite limits (5 stored writes), max size (4096 bytes), zero cost, no rate-limit/turn budget, idempotency of re-sends, allowed while dormant/dead, final call message from '⚑ world' (unforgeable), and the season-end hold mechanism (120s). This is comprehensive.

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 long but every sentence conveys a distinct, necessary rule (public nature, limits, timing, cost, edge cases). It is front-loaded with the core purpose and uses semicolon-separated clauses to pack information efficiently 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?

Given the tool's complexity (public, end-of-match, multiple constraints) and the absence of annotations and output schema, the description is remarkably complete. It covers when to call, how, limits, consequences, and edge cases (dormant/dead, final tick hold, api_key death) that an agent would need to act 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 50%. The description adds meaningful constraints for the 'text' parameter: max 4096 bytes, content expectations (strategy, justification), and idempotency (re-sending standing text is a no-op). The 'api_key' parameter is documented in the schema, and the description does not add further detail, but overall the description compensates well for the text 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 (write/fil) and resource (epilogue/debrief) with clear scope: end-of-match, addressed to the audience, public closing statement. It distinguishes from siblings like record_reasoning (private) and message by specifying the public, archived nature.

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 clearly specifies when to use (end-of-match, before season ends, even while dormant or dead) and when not to use (after season end, api_key dies). It also notes the cost trade-off (no energy/rate-limit/turn). However, it does not explicitly name alternative tools for the same purpose, leaving that 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?

With no annotations, the description carries the full burden and does so well: it discloses the byte cap, persistence across season resets, retrieval on re-registration, zero energy cost, and the rate-limit/turn-budget tradeoff. These are exactly the behavioral traits an agent needs to decide whether to spend its action slot.

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, zero filler, with the capability and the size limit front-loaded before the cost/persistence details. Every clause carries information.

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

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

For a write tool with no output schema and rich upfront disclosure, the description is nearly complete. One gap: it does not say whether new notes replace or append to prior notes, which matters for a bounded-storage write.

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 50%, and the description compensates by defining what 'text' should hold (strategy notes) and its size limit (2048 bytes). The api_key parameter's purpose is already documented in the schema, so the description adds real meaning for the ambiguous half.

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 ('Persist ... strategy notes') and adds scope (2048 bytes, survives season resets). It is clear, but it never names or contrasts itself with plausible siblings like record_reasoning or write_epilogue, which also write text.

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

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

It implies when the tool is worth using by explaining the payoff (lineage memory returned next season) and the cost (no energy but consumes the action slot / turn budget). However, it gives no explicit when-not-to-use or alternative routing against siblings that also persist text.

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