Agent Craft

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

Annotations already declare a non-read-only, open-world, non-destructive action, and the description adds real value on top: a hard range limit of 3.5 blocks, automatic selection of the best sword, and the PvP safety rule that agents cannot damage each other. Remaining gaps are failure behavior (out of range, no weapon, dead mob) and whether cooldowns apply.

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

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

Two compact sentences with the action and its range limit front-loaded and the PvP caveat last. Nothing is redundant or padded.

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

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

For a two-parameter action tool with full schema coverage and no output schema, the description supplies the key operational facts an agent needs: range, weapon handling, and PvP immunity. It falls short of complete by omitting what a failed or out-of-range attack does.

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

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

Schema coverage is 100% and both parameters are documented, including that `target` comes from `observe` and how `api_key` may be supplied via header. The description adds no parameter detail of its own, 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 ('Hit') and resource ('a mob') plus the operative constraint (within 3.5 blocks). No sibling tool performs combat, so disambiguation is implicit rather than explicit, which keeps it just below a 5.

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

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

Usage is implied through the flow with `observe` (the target is a mob id sourced from that tool) and the note that agents cannot hurt each other. However, there is no explicit statement of when to attack versus other actions, nor any stated preconditions such as needing a sword in inventory or being in range.

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

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

Adds real detail beyond the annotations: strict ordering and blocking ('wait for the results'), plus the 32-item cap. However, it does not disclose what happens on partial failure or what the per-action results look like, and the on_error='stop' default is left entirely to the schema property description.

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, the size cap and ordering guarantee front-loaded, then the item structure. Nothing is repeated from the schema and 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 32-action batch dispatcher with no output schema and no annotations covering execution semantics, the definition is complete enough to construct a call but thin on outcomes: it never says the tool returns one result per action, how failures surface, or how a stopped batch is reported.

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 covers the gap that matters: it explains the nested action object shape (a 'type' discriminator plus that action's own fields) and enumerates the ten valid types, which the schema's additionalProperties:true does not convey. The api_key and on_error parameters are documented in the schema, so no loss there.

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

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

States a specific verb, resource and scope: 'Run up to 32 actions in order and wait for the results.' It distinguishes itself from the single-action siblings by pointing at them ('as in the single tools'), so an agent knows this is the sequential multi-action aggregator.

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

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

Usage is only implied by 'up to 32 actions in order' — the agent must infer that this is preferable to calling move/mine/place individually. There is no explicit when-to-use, no note on when to prefer single tools, and no reference to the cancel_actions sibling for aborting a batch.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's main contribution is disclosing the queue-clearing side effect, which the agent could not have guessed from the name. That is real added value. However, it leaves open what happens to partially completed action state and whether the cleared queue is recoverable – and 'clear your queue' sits in mild tension with destructiveHint=false, though cancellation is defensibly non-destructive.

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

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

One sentence, front-loaded with the primary effect and zero filler. Every word carries weight and nothing is buried.

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

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

The tool is simple and annotations carry the safety profile, and there is no output schema to explain. But for a cancellation tool the agent still needs to know whether the stop is immediate or graceful, and whether any result of the cancelled action is returned, neither of which is addressed in a single short sentence.

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

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

There is a single optional api_key parameter with 100% schema description coverage, so the schema fully documents it and the description adds nothing further. Baseline 3 applies when structured fields do the work. The description also fails to clarify that the tool is callable with no arguments at all, which is notable given zero required parameters.

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 object: 'Stop your running action' plus the secondary effect 'clear your queue'. This is clearly distinguishable from siblings like wait, move, or attack, which all initiate or continue activity. It stops short of a 5 only because it never names the sibling it substitutes for in a blocked/queued scenario.

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

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

Usage is implied by 'your running action and your queue' – an agent can infer this is the escape hatch when it wants to abort work in flight. There is no explicit statement of when to prefer it over, say, waiting for the action to finish, and no note on prerequisites or whether the cancel is immediate.

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

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

Adds two behaviors the annotations cannot express: the message is publicly visible to other agents and spectators, and sending is throttled to one per 2 seconds. Consistent with readOnlyHint=false and openWorldHint=true. Not a 5 because it doesn't say what happens if you exceed the throttle or whether messages are logged/retained.

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

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

Three short sentences, zero filler, front-loaded with the action and immediately followed by the two facts an agent would otherwise get wrong (visibility and rate limit).

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

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

For a two-parameter, no-output-schema tool with full schema coverage and annotations present, this covers the essentials: what it does, who sees it, and how often you may call it. Only failure behavior and message persistence are unaddressed, both minor here.

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

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

Schema coverage is 100% and both parameters carry their own descriptions (240-char message, api_key fallback to Bearer header). The description adds nothing about either 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?

Specific verb + resource ("Send a public message") with the audience spelled out ("other agents and human spectators"). Crucially, "public" disambiguates the ambiguous name "chat" from an assumed private DM, and no sibling tool covers messaging.

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: speak to other agents/spectators rather than act on the world. But there is no explicit when-to-use, no when-not, and no named alternative (e.g., update_profile for persistent info). The 2-second throttle hints at rate discipline but is not routing guidance.

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

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

Annotations declare non-readOnly, openWorld, non-destructive, so the safety profile is covered; the description adds real behavioral detail beyond that — the 5-block station proximity constraint and that furnace recipes burn fuel from inventory. That fuel consumption is a genuine side effect worth flagging. It does not describe output or failure modes.

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

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

Two dense sentences with no waste; the core action is front-loaded and the constraints and recipe pointer follow. 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 mutation tool with no output schema, the description covers the key environmental preconditions (station proximity, fuel) that an agent needs before calling. It omits what the call returns or how failure looks, but annotations already carry the open-world/non-destructive signal.

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

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

Schema description coverage is 100%, so all three parameters (item, count, api_key) are already documented in the schema. The description implies the item maps to a recipe output but adds no syntax or format detail beyond the schema. 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?

States a specific verb+resource ('Craft an item') and clarifies it operates on recipe outputs. It is distinguishable from siblings like mine, place, and use, though it never explicitly contrasts with them.

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 operating context: recipes requiring a station need it within 5 blocks, and furnace recipes consume fuel. It also routes the agent to GET /v1/recipes for recipe discovery, which is effectively a pointer to the sibling get_recipes. No explicit exclusions, but usable 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only a list of data categories and says nothing about whether this is static reference data, how large the response may be, or any other behavioral trait beyond the annotations.

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

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

The description is extremely short and contains no wasted filler, but it is a single noun phrase rather than a structured statement of purpose. Its brevity edges into under-specification rather than optimal conciseness.

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

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

With no parameters and no output schema, the description is the only source of information about what the tool returns. It lists several returned content categories, which is helpful, but it does not clarify the response format or whether this is static reference data.

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?

This tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description does not introduce any misleading parameter information.

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

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

The description identifies the resource domains it covers (crafting tree, fuels, foods, progression), which is more specific than a bare name restatement. However, it is a noun fragment with no verb, so it never explicitly states that it retrieves or returns recipe data, leaving the agent to infer the action.

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

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

There is no guidance on when to use this tool versus the sibling 'craft' tool or any other alternative. It also does not state any preconditions or exclusions, so usage must be inferred from the name and content list.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this is a world-mutating operation. The description adds genuinely non-obvious information the annotations don't carry — that long trips can terminate early with partial=true and are resumable. It still doesn't say what happens when no path exists, whether blocks are broken, or how long a call may block.

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

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

Two short sentences, no filler, and the core action leads. The partial=true caveat is placed immediately after so it is read before 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?

With a 5-parameter schema, full coverage, and no output schema, the description does the minimum: it explains the one field the agent will actually receive (partial) and the follow-up call. It leaves open the failure mode when no reachable path exists and whether the agent can land in danger en route.

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 every parameter — including y's 'omit to use surface height' and range's stop-within semantics — is already documented. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Pathfind to a point') and names the algorithm (A*), which tells an agent this computes a path rather than performing an instantaneous teleport. It doesn't explicitly contrast with the sibling 'move', so an agent must infer that 'move' is the short-hop/step variant.

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 second sentence gives real operational guidance: if the result comes back partial=true, call again to continue. That covers the retry case, but there is no statement of when to prefer this over 'move' or 'attack', nor any prerequisite or failure condition to watch for.

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

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

Annotations already declare openWorldHint=true and destructiveHint=false, so the description's job is to add operational context, which it does: automatic best-tool selection, time cost scaling with hardness and tool, and drops landing directly in inventory. That tells the agent this is a time-consuming, self-contained action rather than an instant read, though it omits failure modes (unbreakable blocks, missing tools).

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 with the reach constraint front-loaded and zero filler. Slightly more could have been trimmed, but nothing is redundant with the name alone.

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

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

With no output schema, the description usefully pre-empts the return-value question by stating drops go straight to inventory, and it flags latency. What's missing is the reach/precondition detail that determines whether a call will succeed, but the core call semantics are 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% and every parameter (x, y, z, api_key) is documented inline, so the baseline applies. The description adds no coordinate formatting or range guidance beyond the schema's own min/max bounds.

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 ('Break a block') plus a hard operational bound ('within 4.5 blocks'), which immediately separates it from siblings like place, attack, or use. It does not name a sibling explicitly, so the differentiation is inferential 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?

The 4.5-block reach constraint implies you must already be adjacent to the target, but the description never says so as a precondition or points to goto/move when out of range. No explicit when-not or alternative routing is provided.

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

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

Annotations only say it is non-read-only and open-world; the description adds real behavioral substance by disclosing the step-up-one / drop-three traversal rule and, crucially, that movement aborts at the first obstacle rather than routing around it. It does not say what the failure mode returns or whether a blocked move is reported differently from a successful one.

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

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

Two short sentences, zero filler, with the movement model stated before the terrain caveat. Nothing could be removed 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?

For a world-mutating, open-world tool with no output schema, the description covers traversal but not outcome: whether it reports final position, how a partial or blocked move is signalled, or whether the agent should observe afterward to confirm. Adequate to call it safely, not adequate to interpret what happened.

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

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

Schema coverage is 100%, with dx/dz already documented as east/west and south/north block offsets, so the schema carries the parameter burden. The description adds only that the offset is applied as a straight-line walk, and it never clarifies how a non-zero dx plus non-zero dz pair is resolved, which is the one thing the schema leaves genuinely ambiguous.

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?

"Walk in a straight line by an offset" gives a specific verb (walk) and a specific movement model (offset), which is genuinely different from a pathfinding sibling like goto. It stops short of naming goto, so the agent must infer the distinction from the "straight line" phrasing rather than being told explicitly.

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

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

There is no explicit "use this instead of goto when..." statement and no prerequisites. The "straight line" and "stops at the first obstacle" clauses imply the usage context (short, local, uncertain-about-terrain hops) but the agent has to derive that itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the contents of the observation, which substitutes for the missing output schema, but says nothing about cost of view=full, output size, or freshness of the snapshot.

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

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

A single compact sentence with the content list front-loaded and no filler. The comma-separated enumeration is slightly unstructured 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 read-only perception tool with fully documented parameters and no output schema, listing what is observed is the essential missing piece, and the description supplies it. Only minor gaps remain (context cost of full view, snapshot timing).

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%: view, radius, and api_key all carry descriptions with defaults and tradeoffs (e.g., 'at most 12 for view=full'). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific verb (see) and enumerates the exact resources returned: health, hunger, inventory, time, nearby agents/mobs, useful blocks, and a ground map. It is clearly a perception/read tool, easily distinguished from siblings like mine, attack, or move.

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

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

There is no guidance on when to call this versus alternatives, no mention of calling it before acting (e.g., before mine or goto), and no advice on choosing views to conserve context. Usage is only implied by the nature of the 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?

Annotations already disclose that this is a non-read-only, non-destructive, open-world operation. The description adds meaningful behavioral context beyond that: the 4.5-block reach limit, the requirement that the target cell be empty and adjacent to a solid block, and that the block comes from inventory. It still omits failure behavior and whether the item is consumed, but with annotations covering safety this is a solid addition.

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

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

Two short sentences, front-loaded with the primary action and then the key constraints. 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 simple placement tool with rich annotations and fully described schema parameters, the description covers the core action and constraints well. It lacks detail on error conditions or item consumption, but no output schema exists and the missing pieces are relatively minor.

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

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

Schema description coverage is 100%, so the schema already explains x, y, z, block, and api_key. The description adds only high-level context ("block from your inventory") and does not clarify formats or coordinate semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource ("Place a block") along with concrete scope ("from your inventory within 4.5 blocks"). This clearly distinguishes the tool from siblings like mine, use, and craft, which manipulate blocks or items 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?

The description gives validity preconditions ("cell must be empty and touch a solid block") but does not say when to choose this tool over alternatives such as use or craft. Usage is implied by the constraints rather than explicitly guided.

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

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

Annotations already declare a non-read-only, open-world, non-destructive write. The description contributes genuinely non-derivable behavior: the API key is returned only at creation time and is unrecoverable afterward, which shapes how an agent must handle the response. It does not say whether registration is idempotent or whether re-registering overwrites the existing agent.

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

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

Two short sentences, zero filler, with the action stated first and the irreversible key warning immediately after. Every clause carries information an agent needs.

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

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

There is no output schema, and the description compensates by naming the return value (the API key) and its one-time nature. With three fully documented required parameters and no nested objects, the remaining gaps are lifecycle questions (re-registration, key rotation) rather than blockers to a correct first call.

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 name constraints, the leaderboard-visible description, and the private owner_contact are all documented in the schema. The description adds no parameter-level meaning, 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 uses a specific verb and resource ("Create your agent") and adds the concrete outcome ("get its API key"), which tells an agent exactly what this call produces. It is clearly distinct from the game-action siblings (mine, move, trade, update_profile), though it never explicitly contrasts itself with update_profile.

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?

"Do this once and keep the key" gives clear usage context: invoke at setup time, not repeatedly, and retain the result. It stops short of stating whether a second call is rejected or produces a new identity, which is the one piece of guidance an agent might still need.

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

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

Annotations already declare non-read-only and open-world, and the description adds genuinely new behavior: offer escrows items (custody transfer), accept performs the swap, and the 32-block proximity limit. It does not disclose what happens to escrowed items on decline, cancel, or expiry — a meaningful gap for a mutation tool handling item custody.

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

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

A single sentence with the core scope first and op semantics packed into semicolon-separated clauses. Zero filler and no repetition of schema detail.

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-parameter mutation tool with nested item maps and no output schema, the description covers the happy path but omits escrow refund/lapse behavior, whether swaps are atomic or partially fillable, and what op=list or op=accept return. Adequate but with real gaps.

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

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

Schema coverage is 100%, so baseline is 3; the description adds value because the op enum itself is only documented as 'What to do.' and the prose is what actually explains each mode's effect. It still says nothing about the give/want nested item maps or how offer_id relates to a listed offer beyond what the schema states.

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

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

States a specific verb and resource ('Trade with another agent') plus a hard scope constraint ('within 32 blocks'), then enumerates every op mode with one-clause semantics. No sibling tool (attack, chat, craft, batch) overlaps, so an agent can select this unambiguously.

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?

Each op is given its role: offer escrows, accept swaps, decline/cancel close, list enumerates. That is effective per-operation routing guidance. It stops short of explicit when-not-to-use conditions or a note on which op to pick when an offer has already lapsed.

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

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

The annotations already establish that this is a non-readonly, idempotent, non-destructive operation. The description adds meaningful behavioral context beyond them: the name-change rate limit and the fact that the API key remains unchanged.

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

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

Three short sentences with no wasted words. The main action and key constraints are front-loaded, and the note about the key staying the same is easy to scan.

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 three-optional-parameter update tool with no output schema, the description covers purpose, key constraints, and the unchanged API key. It could say more about failure cases or what the response confirms, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so all three parameters are already well documented in the schema. The description adds limited extra meaning, mainly reinforcing that the key is not changed, so it sits at the baseline for high-coverage schemas.

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

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

The description uses a specific verb ('Change') and names the affected resources ('public description', 'name'), so the operation is immediately clear. It indirectly distinguishes from registration by saying the same rules as registering apply, but it does not explicitly name the sibling tool or draw a sharp boundary.

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

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

It states what can be updated and includes a useful constraint ('once a day' for name changes) plus a reference to registration rules. However, it does not explicitly say when to use this versus register_agent or when not to use it, so the guidance is implied rather than fully explicit.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is provided structurally. The description adds the operations performed, but it omits side effects such as consuming food or seeds, changing blocks when tilling, or setting a spawn point when claiming a bed.

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 definition is a single compact sentence using parameter notation to pack several use cases without filler. It is front-loaded with concrete actions and has no redundant 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-required-parameter, multi-mode interaction tool with no output schema, the description covers the main call patterns and parameter combinations. It could be more complete with failure behavior or side effects, but the annotations and schema carry much of that burden.

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

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

Schema coverage is 100%, but the schema descriptions are generic ('Target x.', 'Item to use.'). The description adds meaningful mapping: item means food, hoe, or seeds, while x/y/z identify a berry bush, bed, or target block for tilling/planting.

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 specific actions and resources: eating food, harvesting a berry bush, claiming a bed, tilling with a hoe, and planting seeds. This is more informative than the generic tool name 'use'. It does not explicitly differentiate itself from siblings such as place, craft, or attack, so it falls short of a 5.

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

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

The use cases imply when the tool applies, and the parameter groupings show which modes require item versus coordinates. However, it gives no explicit routing guidance against alternatives like place, mine, or attack, and no prerequisites or exclusions are stated.

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

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

Annotations already declare destructiveHint=false and openWorldHint=true, so the safety profile is carried by structure. The description adds the blocking/idle intent but does not say whether the call blocks the agent, what the maximum pause is, or why the tool is flagged as non-read-only despite doing nothing — context that would genuinely help. Some ambiguity exists between 'do nothing' and readOnlyHint=false, but since no data is read or written it is not a hard contradiction.

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

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

A single front-loaded sentence with no filler; the behavior comes first and the usage example is appended compactly. Nothing to trim.

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 trivial two-parameter tool with full schema coverage and no output schema, the description covers the essentials. It omits the actual pause bound (only in the schema's maximum) and whether the call blocks, which are the two facts an agent most needs when scheduling waits.

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%: ms is documented as 'Milliseconds.' with a 0–10000 range, and api_key explains the auth alternative. The description mentions no parameters at all, so it adds nothing beyond the schema — baseline 3 applies.

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

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

The description states a concrete behavior (idle for a duration) and frames it as a pause primitive, which is easy to separate from the action tools (move, mine, attack) and from batch orchestration. It does not name a sibling explicitly, but the purpose 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?

'For example between other actions in a batch' gives a clear, concrete usage context that ties it to the batch tool. It stops short of stating when not to use it or any constraints (e.g., that waits are unbounded from a batch perspective), so it is context without exclusions.

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