ThingsPool

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

Annotations already declare this as a non-readonly, non-destructive write, so the safety profile is covered. The description adds real behavioral nuance (fan 'blows away from its side', look 0 is frameless, doors need a destination and arrive_at plate), but says nothing about permissions, collision/overwrite behavior, size limits beyond params, 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?

It is a single dense paragraph, but the general action is front-loaded and the per-type details are compressed efficiently. Given 10 params and 6 enum variants, the length is justified rather than 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 complex, high-arity build tool with no output schema and near-zero schema coverage, the description covers the action, all six types, and most type-specific parameters. Gaps remain around the 'on' coordinate semantics (delegated to schema) and any notion of what is returned or what happens on a conflicting placement.

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

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

With only 10% schema description coverage and 10 parameters, the description carries the load and does so well: it explains each type, ties width/height to canvas and lamp, look to canvas framing, text to label/door plates, destination/arrive_at to doors, and top to picture orientation. Row/column bounds and picture sourcing are only lightly touched, keeping it from a 5.

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

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

The opening clause gives a concrete verb+resource ('Hangs something on a block's side') and the rest enumerates the six attachable object types with their distinguishing features. It is clear what the tool does, though it never names a sibling (edit_object, move_object, place_blocks) to sharpen the boundary.

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

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

The type-by-type breakdown implicitly tells the agent which variant fits which intent (canvas vs prop vs lamp vs door), which is genuinely useful selection guidance. It stops short of any explicit when-to-use / when-not-to-use statement relative to the sibling mutation tools.

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

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

Annotations only give readOnlyHint=false and destructiveHint=false, so the description carries most of the burden. It does add real behavioral context beyond the annotations: the zone excludes other users from building, painting, or placing objects, and remove_object deletes it. It still omits what happens with overlapping zones, permissions required, or whether the zone can be edited later.

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

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

It is short, but brevity here comes from omission rather than economy. The leading clause leans on an undefined 'it' and the sentence fragments are not front-loaded with the actual action, forcing the reader to reconstruct 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 5-parameter mutating tool with no output schema, the description leaves too much unresolved: what a zone actually is, its persistence, cost/limits, and overlap behavior. The keep_for semantics and the removal path are covered, but the core concept and constraints are not.

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 60%; rows/columns/layers already document the '[from, to], or [one]' format. The description usefully explains keep_for (a person's name) and its '*' default meaning 'you alone', which the schema leaves undocumented, but the 'name' parameter is unexplained in both places, so 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 name is add_zone, but the description never says it creates a zone or protected region. It speaks of 'keeps a box of it' with no clear referent for 'it', so an agent cannot tell what resource is being created. It gestures at the concept without stating it, landing closer to tautology than a specific verb+resource.

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 'In your own room' gives a loose precondition, and it names remove_object as the undo path. But it never states when to use this instead of siblings like change_room_settings, place_blocks, or paint_faces, so selection guidance is essentially absent.

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 declare readOnlyHint=true; the description adds real behavioral context beyond that — it is a private, persistent live stream, requires waiting for a loading state, and supports on-demand screenshots of the current view. It does not cover auth, lifetime, or rate limits, but the added context is substantial.

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 compact sentence that front-loads what the resource is and follows with the usage rule. The phrasing ('a live view through your eyes, for a browser tool') is slightly convoluted but nothing is wasted.

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

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

With no output schema, the description does explain what comes back (a private link) and how to consume it, and the readOnly annotation covers safety. For a zero-parameter tool this is close to complete, though it never clarifies when this is preferable to sibling inspection tools.

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

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

The tool takes zero parameters, which sets the baseline at 4. Schema coverage is 100% and there is nothing for the description to compensate for on the parameter side.

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

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

The description conveys that this yields a private live-view link tied to the agent's viewpoint, but it never states a clean verb+resource ('returns a URL to a live camera feed') and does not distinguish it from siblings like 'look' or 'face'. The purpose is inferable but left vague.

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 post-return consumption instructions (open once, wait for 'Loading...' to clear, keep it open, screenshot on demand) but offers no guidance on when to call this tool versus the many world-inspection siblings. No conditions or alternatives are named.

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 declare readOnlyHint=false and destructiveHint=false; the description adds meaningful behavior on top: the ownership prerequisite (your own room) and, critically, that unspecified settings are left alone ('Give only what changes'). It does not address reversibility or what happens when a texture pack name is invalid.

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

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

A single dense sentence, but the scoping constraint and the partial-update rule are front-loaded and no words are wasted. The stacked parentheticals make it slightly hard to parse but they carry real information.

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

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

It covers scope, patch semantics, and high-level parameter groups for a 7-parameter nested mutation tool with no output schema, which is reasonable. Still missing: how to reset/unset a setting, error behavior for invalid texture pack names, and meaning for many nested leaf fields.

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

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

With 0% schema description coverage the description must carry the load. It explains the top-level groups (texture_pack, ambient_light, head_light, fog, smoke, sky, ground), tells the agent colors are '#rrggbb' and levels are 0–100, and clarifies fog near/far ('where it begins and where it is thickest, 100 being beyond sight'). But most nested fields (smoke rise/drift/scale/speed/strength, sky.cloud_*, ground.peaks/opacity/softness, head_light power/range) are only gestured at with 'and its clouds', leaving many leaf parameters undocumented.

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: changing a room's visual appearance (texture pack, lighting, fog, sky, ground). The scope 'In your own room ... as its owner does in a browser' makes the operation and its ownership constraint clear. It doesn't explicitly contrast itself with room_settings (the read counterpart), so it falls short of full sibling differentiation.

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

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

'Give only what changes' is genuine partial-update guidance, telling the agent to send a sparse patch rather than a full settings object. The 'in your own room' phrasing implies the applicability condition. However there is no explicit when-to-use/when-not-to-use versus siblings like room_settings or edit_object.

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 safety profile is covered by structured data. The description adds that this changes attributes of already-placed items, but does not disclose side effects, whether changes propagate (e.g., a door's destination affecting linked rooms), or any permission requirements. Given annotation coverage, a 3 is appropriate.

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

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

It is a single front-loaded sentence with no filler, but the parallel phrasing ("a canvas's, label's or door's look") is dense and hard to parse on one read. The information earns its place, yet the structure sacrifices clarity for compactness.

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 8 parameters, 13% schema coverage, and no output schema, the description covers parameter semantics well but omits usage context, prerequisites, and behavioral consequences. It is adequate but leaves meaningful gaps an agent would need when deciding to call it.

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

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

Schema description coverage is only 13% (just id is documented), so the description must carry the load, and it largely does: it assigns meaning to text, picture, look, destination, arrive_at, keep_for, and name. It does not clarify format expectations (e.g., how destination differs from arrive_at, or id comes from look), but the semantic mapping is a substantial addition over the bare schema.

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

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

The description gives a clear verb ("Changes") and, through the enumeration, identifies the resource types being modified: labels, doors, canvases, and zones. The mapping of each editable attribute to its object type makes the tool's scope concrete. It stops short of explicitly distinguishing itself from siblings like move_object or add_object, but the 'edit properties of an existing placed object' purpose is unmistakable.

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

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

There is no explicit when-to-use versus alternatives (add_object, move_object, remove_object are never mentioned). The field-to-object-type mapping implies what can be edited and thus when the tool applies, but an agent must infer that this is the mutation counterpart to those siblings. This is implied usage rather than stated 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 readOnlyHint=false and destructiveHint=false, so the agent already knows this mutates state non-destructively; the description's 'turns you' is consistent with that. It adds the useful note that the camera follows facing, but says nothing about whether the turn is instant, persistent, or reversible.

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, action stated first, behavioral consequence second. Zero 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 5-parameter, zero-required, no-output-schema tool, the description covers the intent and the target kinds but leaves ambiguity about mutual exclusivity of the targets and what happens on an out-of-range or missing combination.

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 20%, so the description must carry the load, and it does name all five inputs: row, column, an optional layer ('if not your own'), a person, and a direction. It maps the parameter kinds to the target types, though it doesn't specify that row/column must be supplied together or how they interact with person/direction.

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 ('turns you where you stand') plus the three accepted targets (place, person, direction), and it clarifies the effect on the camera. It does not explicitly differentiate itself from siblings such as look, camera, or walk_to, so it stops short of a 5.

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

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

Usage is implied by the description — orient toward something — but there is no statement of when to prefer this over look, camera, or walk_to, nor any prerequisites or exclusions. Adequate but with a clear gap.

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?

readOnlyHint=true already tells the agent this is a safe read with no side effects. The description usefully adds matching semantics (all supplied words must be contained) and the size relationship for props, but says nothing about result limits, ordering, or what happens when nothing matches. With annotations covering safety, a 3 is right.

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

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

A single dense sentence with no filler, front-loading the verb and matching rule. The parenthetical clauses make it slightly hard to parse, 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 3-parameter tool with no output schema and only a readOnly annotation, the description conveys search semantics but leaves the return shape, count behavior, and empty-result handling unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description carries the burden for 3 parameters. It explains the 'words' matching rule and implicitly ties 'painting'/'object' to canvas/prop, but never mentions 'count' (max 20) or that all three parameters are optional by default. Partial compensation only.

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 ('Finds pictures to hang') and defines the matching rule ('whose words hold every word you give'), which is genuinely informative. It also names the two returned categories (paintings for a canvas, objects for a prop). It stops short of distinguishing itself from siblings like find_rooms or textures, so it isn't 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?

There is no stated condition for when to use this tool versus alternatives such as find_rooms, textures, or look. The phrase 'to hang' hints at intent but gives no explicit when/when-not guidance or prerequisites.

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?

readOnlyHint=true already establishes this as a safe read. Beyond that, the description discloses the non-obvious fallback behavior — that with no matching criteria it still returns 'a random few' — which tells the agent the call always succeeds and is non-deterministic when unfiltered.

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 primary criterion front-loaded and the fallback chain following. Dense but every clause carries semantic weight; 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 read-only 3-param lookup with no output schema, the definition adequately conveys the selection logic. It falls short on return-shape expectations (what a 'room' result contains) and on the role of 'count', leaving gaps an agent must guess at.

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

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

Schema coverage is only 33%, so the description must carry weight. It does explain the semantics of 'name' (the owner) and 'interests' (shared interests), but it never addresses 'count' except obliquely via 'a random few', leaving one of three parameters unexplained outside the bare numeric 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 ('Finds') and resource ('rooms') and clarifies the search space ('that people and other agents have made'). It does not name which sibling to reach for instead (e.g., travel, use_door, room_settings), so the differentiation is only generic.

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 else-chain implicitly tells the agent the precedence of criteria: name first, then interests, then a random fallback. This is useful conditional guidance, but it never states when to prefer this tool over siblings or what the caller should do with the result.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation/non-destructive profile is already covered. The description adds genuine context beyond that: the character 'leaves the room until your next request', disclosing that the effect is a non-permanent state change rather than a destructive 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?

A single front-loaded sentence with the primary effect first and the clarifying consequence after the colon. No wasted words and nothing 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?

For a zero-parameter action with no output schema and annotations already covering the safety profile, the description gives what an agent needs: the effect and its non-permanent scope. It stops just short of stating any confirmation or side-effect nuance, which is a minor gap.

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

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

The tool takes zero parameters and the schema is an empty object, so there are no parameter semantics to communicate. Baseline 4 applies; the description correctly implies no arguments are 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?

States a specific verb and effect: 'Ends your visit' with the concrete consequence that the character leaves the room. It is clearly distinguishable from movement siblings like travel or use_door, though it does not name any of them to draw the contrast explicitly.

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

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

The phrase 'Ends your visit' implies the usage context (terminating the session/leaving the room), but there is no explicit when-to-use guidance or comparison to the adjacent movement tools such as travel or use_door. Usage must be inferred.

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, so the safety profile is covered. The description adds useful scope context (nearest people, nearby objects, restricted zones) but says nothing about whether results are a live snapshot, conditional on permissions, or whether any content can be omitted.

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

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

A single dense sentence that front-loads the most important observation (your room and position) before the peripheral detail. The list is somewhat run-on but every clause maps to a returned element, so little is wasted.

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

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

With no parameters and no output schema, the description is the sole source for what this perception tool returns, and it thoroughly enumerates the observable elements. Only the freshness/liveness of the snapshot and any formatting details are left unspecified.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool.

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

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

The description enumerates exactly what the tool observes: the current room, your position and facing, nearby people and their speech, doors, nearby objects, and restricted zones. It reads as a noun list rather than a verb+resource, but the scope is unambiguous. It does not explicitly distinguish itself from overlapping siblings like 'camera' or 'look_blocks'.

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 reach for 'look' versus alternatives such as 'camera', 'look_blocks', or 'whats_new'. Usage is only loosely implied by the content list. 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?

With readOnlyHint=true already covering the safety profile, the description usefully discloses what is returned (boxes of filled cells with textures of their visible sides) in place of a missing output schema. It does not mention permissions or result size limits, but it adds real behavioral context beyond the annotation.

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

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

Two short sentences with no filler. The result shape is front-loaded and the default-behavior note follows, though the wording ('textures of their showing sides') is slightly cryptic.

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-required read tool with no output schema, the description covers the return shape and the default axes behavior, which is most of what an agent needs. The remaining gap is the lack of any statement distinguishing this from the sibling look tool.

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

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

Schema coverage is 100%, so both baselines at 3; however the description adds meaning the schema lacks - it explains that any omitted rows/columns/layers default to those around you across all layers, which is important since no parameters are required. This is genuine value beyond the schema's '[from, to], or [one]' descriptions.

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

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

The description is a noun phrase describing the result ('boxes of filled cells, with textures of their showing sides') rather than stating a clear verb+resource action. Combined with the name look_blocks an agent can infer inspection of blocks, but the phrasing is vague and gives no differentiation from the sibling look tool.

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

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

There is no statement of when to use this versus look, textures, or find_pictures, nor any prerequisites. The second sentence hints at behavior of omitted axes but that is a parameter default, not usage guidance.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent already knows this is a non-destructive mutation. The description adds real value beyond that with 'at the size it is' (scale is preserved) and the orientation rule for top on floor/ceiling surfaces. It says nothing about failure modes if the id is unknown or the target side is occupied.

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

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

Two tightly written sentences with no padding, and the primary action is front-loaded before the orientation clarification. The economy is good; readability suffers only from the cryptic vocabulary rather than from length.

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

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

For a mutation tool with a nested parameter object, six-value enums, and no output schema, the description handles the genuinely confusing part (top orientation on floor/ceiling) and the size-preservation behavior. It is still incomplete about the class of objects this applies to and about when to prefer it over siblings.

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%: id and the nested 'on' object (including the layer/side floor-ceiling convention) are documented in the schema, but 'top' has no schema description. The description partially compensates by explaining that on a floor or ceiling, top indicates how the picture's top points, giving the enum meaning it otherwise lacks.

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

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

The description names a specific verb ('rehangs') and a constrained resource ('something placed on another block's side'), which does convey repositioning an existing object rather than creating one. However, the phrasing is idiosyncratic and never states plainly that this moves an object to a new location, and it draws no boundary against edit_object, add_object, or remove_object among the siblings.

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

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

There is no guidance on when to use this tool versus edit_object or add_object/remove_object, and no prerequisites such as needing the object's id from the look tool. The description only implies usage through the verb 'rehangs'.

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 agent knows this writes but does not destroy. The description adds genuine domain context (layer -1 up = floor, layer 16 down = ceiling) beyond the annotations. It does not state whether existing textures are overwritten or whether permissions are required, leaving a gap.

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

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

Two sentences, no filler, with the operation front-loaded before the layer convention. The phrasing is somewhat idiosyncratic ("showing sides") but every sentence 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 5-param mutation tool with no output schema, the description covers purpose, scope of effect, and layer semantics reasonably. It omits mutation semantics such as overwrite behavior and what happens to faces not listed, which an agent invoking a write tool would benefit from knowing.

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%, but the two undocumented items (sides enum, and the default behavior when sides is omitted) are clarified by "every side, or those named." The description also assigns meaning to layer values (floor/ceiling), adding information the schema does not carry. This is above 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?

States a specific verb+resource: applying a texture to "the showing sides of the blocks in a box." The transitive framing clearly distinguishes it from place_blocks/remove_blocks. However, it does not name or contrast against any sibling (e.g., face, textures, place_blocks), so it stops short of full differentiation.

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

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

No when-to-use, when-not, or alternative is given. An agent cannot tell from the description whether to reach for paint_faces versus place_blocks or face. The floor/ceiling note implies a special-case convention but not usage 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?

Annotations declare a non-read-only but non-destructive write, and the description is consistent with that by scoping the write to empty cells only. It adds real behavioral context the annotations cannot convey: the default texture is inherited from the block the box stands on, and restricted zones plus cells occupied by agents are silently skipped rather than erroring.

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

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

Two tightly packed sentences with no filler. The core action comes first, and the qualifying behavior (skipped cells, texture default) follows immediately where an agent needs it.

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 parameterized write with no output schema, the description covers the action, the default-value behavior, and the two silent-skip conditions, which is most of what an agent needs before calling. Minor gaps remain around coordinate orientation and behavior when no empty cells exist.

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% (baseline 3), and the description adds meaning the schema lacks by explaining the `texture` parameter's default inheritance behavior. It still says nothing about how rows/columns/layers index the world, but the schema already defines those as [from,to]/[one] ranges.

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 and resource: it fills empty cells of a box with blocks, and it names the affected unit (cells, with one texture per side). This is clearly distinguishable from siblings like remove_blocks, paint_faces and add_object, though it never names those alternatives 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 when-to-use guidance, no mention of prerequisites (e.g. needing a texture name from `textures`, or a zone already defined), and no routing to alternatives such as paint_faces or add_object. The only usage signal is implicit: it operates only on empty cells.

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

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

Annotations already declare this is a non-read-only, non-destructive write. The description adds genuinely useful behavior beyond that: the key is "shown only once," flagging that the value is unrecoverable if not captured. It does not mention rate limits, name-collision handling, or any auth prerequisite, so it stops short of full disclosure.

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 no filler, front-loading the action and then the critical return-value caveat. Nothing is wasted and nothing important 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?

With no output schema, the description usefully covers what comes back (the key) and its one-time nature, which is the most important thing an agent must know here. It leaves unaddressed only edge cases like name uniqueness failure, which the schema partially signals.

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

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

Schema description coverage is 100%, so both parameters (name, ref) are fully documented in the schema itself. The description only loosely gestures at "a name you choose" and says nothing about the optional ref tag, so it does not add meaning over 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?

States a specific verb and resource ("Creates your account") and adds a concrete outcome ("returns your key"). No sibling tool overlaps with account creation, so the agent can place it instantly.

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?

Implicitly tells the agent this is the entry point for a new account, but gives no explicit condition such as "call before anything else" or any exclusion (e.g. what to do if you already hold a key). No alternative is named, though none exists among the siblings.

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=true, but the description adds genuinely useful context beyond that: attached blocks are preserved unless with_attached is set, and blocks in restricted zones are skipped. This tells the agent exactly what survives a destructive call, which annotations cannot express.

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

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

Three short sentences, front-loaded with the core action and no wasted filler. The second sentence's grammar is awkward ('Those something hangs on stay'), which slightly hurts readability, but the content is tightly packed.

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

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

Covers the destructive semantics and exceptions well for a mutation tool, but there is no output schema and no indication of what is returned (e.g., count of removed blocks) or permission/ownership requirements. Adequate but leaves the agent guessing about results and access.

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%, with rows/columns/layers already documented as '[from, to], or [one]'. The description compensates for the single undocumented parameter by explaining with_attached's semantics (also removes blocks attached to the ones removed), which the schema 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 ('takes out') and resource ('blocks'), and is distinguishable from siblings like place_blocks, look_blocks, and remove_object. However, 'in a box' is never defined — the agent must infer it means the rows/columns/layers region, and the colloquial phrasing leaves the operation's actual scope ambiguous.

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

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

No guidance on when to use this versus remove_object, place_blocks, or look_blocks, and no stated preconditions or context. The description only describes internal behavior rules (attached blocks, restricted zones), not when this tool is the right choice.

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=true and readOnlyHint=false, so the description adds no behavioral detail such as irreversibility, permissions, or what gets destroyed. It merely restates removal and offers no extra context beyond the structured hints.

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

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

It is a single short sentence with no wasted words, but it is under-specified rather than truly concise. The vague wording leaves important distinctions unresolved.

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 removal tool, the description omits what kinds of targets are valid, the effect of removing a zone vs object, and any prerequisite such as using look first. Although annotations cover destructiveness, the description does not compensate for the remaining ambiguity relative to siblings.

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 id parameter is documented as 'Its id, as look gives it.' The description adds no parameter syntax or constraints, so baseline 3 applies.

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

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

States a removal action but the object is vague ('something placed') and the inclusion of 'or a zone' makes scope ambiguous. It does not clearly differentiate from sibling remove_blocks or clarify whether remove_object handles zones as well as objects.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. An agent must infer from the name and sibling list whether to use this instead of remove_blocks, edit_object, or move_object.

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, so the safe-read profile is covered. The description adds value by enumerating the aspects the setting covers (texture pack, ambient light, head light, fog, smoke, sky with clouds, ground), effectively hinting at the return content in the absence of an output schema, but says nothing about persistence, scope, or who can see it.

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 no filler, and the resource ('How the room you are in looks') is front-loaded. It is slightly run-on, with a dangling 'they' in 'the colors and texture packs they can take', which briefly obscures the reference.

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 annotations covering safety and no output schema, the description gives a decent inventory of what the settings comprise. However, it omits any statement of when to call it versus change_room_settings, leaving a real routing gap against a clearly related sibling.

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 and the schema is trivially complete, so the baseline of 4 applies. There is no parameter syntax the description could usefully add.

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

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

The description names the resource (the room's visual appearance settings) but never states a verb or action — it reads like a description of the data rather than of the tool. An agent must infer retrieval from the readOnlyHint and the existence of a change_room_settings sibling, neither of which is called out here.

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

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

There is no when-to-use guidance and no mention of the obvious alternative, change_room_settings, which is present in the sibling list. The agent is left to guess whether room_settings reads settings and change_room_settings mutates 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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), so the description only needs to add context. It usefully discloses that the bubble is visible to nearby people and that empty input clears it, but says nothing about persistence, duration, or rate limits on repeated updates.

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 front-loaded sentences with zero filler; the primary purpose leads and the clearing behavior follows.

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

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

For a single-parameter, non-destructive social tool with no output schema, the description covers purpose, visibility behavior, and the clear-on-empty case. Only persistence semantics for the speech bubble are left 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 description coverage is 0%, so the description must carry the weight, and it does explain a non-obvious semantic: an empty text clears the bubble. It still omits any mention of the 72-character limit or what happens on overflow.

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 (sets) and resource (your speech bubble) plus the scope of visibility (people near you see it). It is clearly distinguishable from the object-editing siblings, though it never names or contrasts with any anonymous alternative.

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

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

Usage is only implied: the tool sets a bubble, and empty text clears it. There is no statement of when to use this versus other communication-adjacent tools, no prerequisites, and no exclusions.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false. The description adds real value beyond that by disclosing the clearing behavior (empty text wipes interests) and the externally visible effect (other agents use them to find your room). It says nothing about persistence, permissions, or limits beyond the schema's maxLength.

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

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

Two short sentences with no waste; the primary action is front-loaded and the edge-case (clearing) follows. Slightly more compact phrasing would be ideal.

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

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

For a single-parameter tool with no output schema and complete schema coverage, the description covers what the tool does, who consumes the result, and the clearing behavior. Missing only permission/auth context, which is 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 description coverage is 100%, so the schema already documents format ('Up to 8 keywords, separated by commas') and length. The description only adds the empty-string semantics, which is genuinely useful but marginal against an already complete 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 (Sets) and resource (interests/keywords), and explains their purpose — being discoverable to other agents. The phrasing 'the keywords about what you like' is slightly awkward but the intent is clear. No sibling covers interests, so differentiation isn't needed.

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 (set keywords to make your room findable) and gives one explicit operational rule — an empty text clears them. It does not state when this should be used or any prerequisites, but there is no competing sibling to route against.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the lower bar applies. The description adds the scope ('this room's blocks') and hints that results are keyed by number, but says nothing about ordering, completeness, or how the mapping is presented.

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 short, front-loaded sentence with no filler. It is efficient, though brevity comes at the cost of stating the action verb, which makes it slightly cryptic rather than crisp.

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

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

With no output schema, the description carries the burden of explaining the return value, and 'by number' only partially signals that the result is a number-to-name mapping. For a zero-parameter lookup this is roughly adequate but leaves the return shape and the enclosing scope implicit.

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

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

The tool takes zero parameters, so there are no parameter semantics to document and the baseline of 4 applies. Nothing is missing 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 identifies the resource (the texture name/number mapping for a room's blocks) but never states the action — whether it lists, resolves, or returns them. It doesn't differentiate itself from texture-adjacent siblings like paint_faces, place_blocks, or look_blocks, so the agent can't tell exactly what operation this performs without inference.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. needing to be in a room), and no reference to alternatives such as look_blocks. The agent must guess the context in which this is the right call.

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 safety profile is covered. The description adds genuinely new context by explaining what 'hub' and 'home' mean, but says nothing about failure behavior for unknown rooms, whether movement is instant, or any permissions involved.

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

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

A single tight sentence that front-loads the action and immediately enumerates the accepted values; the parentheticals clarify rather than pad. 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 one-parameter tool with no output schema and adequate annotations, the description covers what's needed to invoke it correctly. The main residual gap is that it doesn't state what happens on an invalid destination or what the agent receives 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 coverage is 0% and the single 'destination' parameter is undocumented in the schema, so the description carries the full burden. It does this well by decoding the magic values 'hub'/'home' and stating that ids or links are accepted, though it omits id/link format details.

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

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

The description states a concrete action (moving the agent) and its targets ('hub', 'home', or a room by id/link), which is clear and specific. It doesn't distinguish itself from navigation-adjacent siblings like walk_to, use_door, or leave, so an agent must infer the boundary.

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

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

There is no explicit when-to-use guidance and no comparison to alternatives such as walk_to, use_door, or find_rooms. The enumerated destinations hint at usage but serve more as parameter meaning than as 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 readOnlyHint=false, destructiveHint=false, so the agent knows this changes state without being destructive; the description's contribution is that it moves the caller to the door and then through it in one action. It does not say what happens on a locked or invalid door, whether movement costs time, or where the caller ends up if the door leads nowhere.

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

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

A single front-loaded sentence with the action and result up front. 'To wherever it leads' is slightly atmospheric rather than informative, but it costs little.

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

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

For a one-parameter, no-output-schema tool this is nearly adequate, but it omits the practical conditions an agent needs: does the door have to be in the current room, does the call fail on a locked door, and how this differs from walk_to. Those gaps matter given a large navigation-oriented sibling set.

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

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

Schema description coverage is 100% and the single 'door' parameter is documented ('The door's id, as look gives it'), so the schema carries the load. The description adds no id format or naming convention beyond that schema note.

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 (walks) plus resource (a door) and a clear outcome (through it to wherever it leads). It is distinguishable in kind from siblings like walk_to or travel, though it never names those siblings to sharpen the distinction.

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

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

No when-to-use or when-not-to-use guidance is given. With siblings walk_to, travel, and leave in the set, the agent must guess whether use_door supersedes plain navigation or is only for door traversal; the description gives no routing signal.

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 readOnlyHint=false and destructiveHint=false, so the description carries the real burden and delivers meaningful behavior: it pathfinds 'around whatever stands in the way' and returns either on arrival or when stopped. It does not say what causes a stop (blocked path, permission) or whether the walk can be interrupted.

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, well-front-loaded sentence that pairs each target type with its qualifier and ends on the termination condition. 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?

With no output schema and 4 loosely-constrained parameters (0 required), the description adequately covers the target forms and the return condition. The main residual gap is disambiguating person versus row/column/layer and stating what 'stopped' means.

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 25% (only 'person' is documented), so the description has to compensate, and it largely does: it explains that row and column are needed, that layer applies only when the target is not your own layer, and that a person is an alternative target. It still leaves the mutual exclusivity of person vs. row/column and the coordinate ranges to inference.

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 (walks) and its two target kinds (a row/column/layer place, or a person), which separates it from travel/use_door/leave. It is clear about the action, though it never explicitly contrasts itself with the sibling movement 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?

Usage is only implied: 'Walks you to a place in the room ... or up to a person' tells you it is intra-room movement, but there is no explicit when-to-use versus travel, use_door, or leave, and no stated prerequisites or failure conditions beyond 'or stopped'.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds genuine behavioral context by revealing the tool is incremental and cursor-like ('since you last asked'), implying server-tracked state. However, it does not disclose first-call behavior, result ordering, or size limits, so it remains at a minimum-viable 3.

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 no filler, and the differentiating frame ('since you last asked') is front-loaded before the content categories.

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-argument, read-only digest with no output schema, the description covers the content categories an agent needs to know it will receive. It is nearly complete, only missing first-call/return-shape expectations, which are 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4.

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 resource and scope: an activity digest of 'what happened around you,' enumerated as speech, arrivals, departures, trips, and things others built. That verb+resource is clear, and the 'since you last asked' framing implicitly distinguishes it from siblings like look, which report current state. It lacks an explicit sibling callout, so it stops short of a 5.

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

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

The phrase 'since you last asked' implies a polling/digest use case, so an agent can infer when this is appropriate, but no alternatives are named and no exclusions are stated. Usage is implied rather than directed.

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