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

The annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: that linked partners may be deleted as a side effect via editor rules. It says nothing, however, about batch size limits, partial failure, or what happens when the expected revision mismatches.

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

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

Two short sentences with no filler, and the primary action is front-loaded. The second sentence is dense but earns its place by disclosing the cascade side effect.

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 batch mutation with four required, wholly undocumented parameters and no output schema, the description leaves out too much: revision-conflict behavior, atomicity, and the practical size limit. Only the cascade-to-partners warning is supplied.

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% across four required parameters, so the description carries the full burden and covers none of them. The critical expected_revision optimistic-concurrency parameter and the 256-item cap on actor_ids go entirely unexplained.

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 ('Delete ordinary actors'), which clearly separates it from siblings like place_actor, move_actors, and list_actors. The phrase 'ordinary actors' versus 'linked partners' is not defined anywhere, so the scope boundary is only partially clear.

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

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

There is no guidance on when to choose this tool over alternatives, no mention of prerequisites, and no mention of undo/redo as a recovery path even though both are sibling tools. The agent must infer all usage context from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and non-destructive, so the safety profile is covered. The description usefully enumerates the state fields returned, but does not describe their shape or how 'combined history' is composed, which matters since there is no output schema.

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

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

A single front-loaded sentence with no filler, leading with the verb and then the payload. The field list is dense but every term earns its place.

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 single-parameter read with no output schema, the description is close to sufficient because it enumerates the returned state components. The gap is the unexplained session parameter and the ambiguous 'combined history' field.

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

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

There is one required parameter, browser_session_id, with 0% schema description coverage, and the description never mentions it or explains what a session id scopes the read to. With low coverage the description should compensate, and it does not.

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

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

The description gives a specific verb ('Read') plus an enumerated set of returned fields (map, revision, grid, selection, editability, dirty, combined history), which makes it clearly a state-inspection tool. It is implicitly distinct from mutating siblings like place_actor or delete_actors, but no sibling is named.

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: reading current state before/after edits. There is no explicit statement of when to call this versus list_items, list_actors, or select_actors, and no stated prerequisites beyond the required session id.

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 cover read-only, idempotent, non-destructive behavior, and the description adds a meaningful pagination-consistency note. It still does not explain what 'live actors' means, what is returned, or what happens when session/revision are not pinned.

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 two short sentences with the primary purpose front-loaded and little wasted text. The reference to 'editor_id' is a minor structural weakness because it does not map to any schema field.

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 seven-parameter list tool with no output schema and no parameter descriptions, the description is too sparse. It provides pagination guidance but does not explain filtering, selection, map/session scoping, or the shape of returned actor 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?

With 0% schema description coverage across seven parameters, the description must do more work, but it only vaguely references 'session and revision' and mentions an 'editor_id' that is not a parameter. It leaves limit, offset, item_id, selected_only, map_session_id, and browser_session_id unexplained.

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

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

The description states a clear verb/resource pair: paging live actors. It distinguishes itself from list_items and list_sessions by naming actors specifically, though the reference to 'editor_id' is confusing because no such parameter exists in the schema.

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

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

It gives useful pagination advice to pin session and revision for consistent pagination. However, it does not explicitly say when to use this tool versus list_items or get_state, so usage is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the catalog is static ('baked') and includes entries that are queryable but not placeable, warning the agent about a downstream failure mode. It says nothing about result ordering, default result set size (limit defaults to 100), or whether the catalog is scoped to the browser session.

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 the resource statement front-loaded and no filler. It is efficient, though the brevity is part of why parameter and usage details are missing rather than a sign of disciplined editing.

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?

Four parameters, no output schema, and no parameter descriptions mean the agent gets almost no information about what comes back or how to use the results. Critically, the description does not say whether returned items carry the identifiers needed by place_actor, which is the natural next step in this workflow.

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

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

Schema description coverage is 0% across all four parameters, so the description carries the full burden and does not meet it. It never explains what 'query' matches against (name, tag, type), how 'limit'/'offset' interact, or why 'browser_session_id' is required for a read-only catalog lookup.

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

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

States a specific verb and resource ("Search the editor's baked item catalog"), which is enough to distinguish it from the actor-oriented siblings (list_actors, place_actor). The verb "Search" versus the tool name "list_items" creates mild ambiguity about whether results are filtered or enumerated, but the resource 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?

The clause "Some items are queryable but not placeable" implies a downstream constraint that matters when choosing between this tool and place_actor, but it never states when to call this instead of get_state or list_actors. There is no guidance on pagination strategy or the required browser_session_id.

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 as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful workflow guidance about explicitly choosing a browser_session_id for other tools, but does not describe the return shape, empty results, or whether multiple sessions may be listed.

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 action and resource. Every sentence adds usable information, with no filler or redundant restatement.

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 list tool with rich read-only annotations and no output schema, the description is nearly complete. It identifies the resource and explains how the result is used, though it could clarify the return shape more explicitly.

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

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

The tool has zero parameters and full schema coverage, so there are no parameter semantics to explain. The description appropriately focuses on the tool’s purpose and prerequisite usage rather than redundant parameter 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?

States a specific verb and resource: "List paired browser tabs." This clearly identifies the tool’s function and distinguishes it from the mutation-oriented siblings, though it uses "browser tabs" rather than explicitly saying "sessions."

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?

Adds clear workflow context by saying to choose a browser_session_id for other tools, which implies this tool is the prerequisite for session-scoped operations. It does not state exclusions or alternatives, but none are obviously needed for a zero-parameter list 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 declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely useful behavior — that returned positions may differ from the requested delta and should be inspected — which is valuable given there is no output schema. It still omits concurrency semantics (expected_revision conflicts), whether a move is all-or-nothing across actor_ids, and what happens on collision.

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

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

A single tight sentence with the operation front-loaded and no filler. The second clause is slightly cryptic ('inspect actual returned positions') but it earns its place by flagging a non-obvious behavior.

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, non-idempotent, five-required-parameter mutation with no output schema and no schema documentation, the description is too thin. An agent cannot tell from it how to handle a revision mismatch, partial application, or invalid coordinate targets.

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 load for five required parameters. It explains only that movement is in integer grid cells (clarifying delta's semantics) and implies actor_ids is a list; it says nothing about expected_revision acting as an optimistic-concurrency token, nor the roles of browser_session_id and map_session_id.

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

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

States a specific verb and resource ('Move ordinary actors') plus the unit of movement ('integer grid cells'), which distinguishes it from placement (place_actor) and selection (select_actors). The qualifier 'ordinary' hints at an actor-type restriction but never names the alternative or what non-ordinary actors would use.

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 place_actor/select_actors/undo, and no mention of prerequisites such as needing a prior select or a fresh revision. The only implicit guidance is the word 'ordinary', which suggests some actors are excluded but leaves the agent to guess.

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, idempotentHint=false and readOnlyHint=false, so the danger profile is covered. The description adds genuine value with the single-item limit and the empty-cell precondition, but omits what the destructive operation affects, how expected_revision conflicts are handled, and whether sessions must be pre-attached.

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 action and followed by the one non-obvious format rule. There is no filler, though the brevity is arguably under-specification rather than tight editing on a 7-parameter mutation tool.

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

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

For a destructive, non-idempotent mutation with 5 required parameters, 0% schema coverage, and no output schema, the description is far too thin. Nothing explains the revision-check contract, the two session identifiers, or the failure modes an agent must anticipate before calling it.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and largely fails: expected_revision (optimistic-concurrency token), rotation_index, browser_session_id, map_session_id, and item_id are never explained. Only color_linear_rgb gets meaning beyond the schema, via the 'linear RGB, not sRGB' note, and 'cell' is only implied by 'empty grid cell'.

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 ('Place one ordinary item') plus a placement constraint ('empty grid cell'), which is enough to tell it apart from move_actors and delete_actors. However, the tool is named place_actor while the description says 'item', leaving a naming ambiguity an agent must resolve on its own.

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

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

The description gives no when-to-use/when-not guidance and never names the obvious alternatives (move_actors for existing actors, select_actors, undo). The 'empty grid cell' phrase implies a precondition but does not say what happens if the cell is occupied or when an agent should prefer a different sibling.

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 idempotentHint=false, so the safety profile is covered, but the description adds nothing about what gets discarded, whether the call fails or no-ops when nothing is available to redo, or what expected_revision guards against. For a state-mutating history operation this is thin.

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

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

One front-loaded sentence with no filler or repetition. It is efficient, though its brevity is part of the under-specification problem rather than a virtue here.

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 three-required-parameter mutation tool with no output schema and no parameter documentation, the description leaves the agent without the revision-guard contract, session scoping, or failure behavior. Terms like 'combined history entry' are unexplained jargon.

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% across three required parameters, and the description never references any of them. Critically, 'expected_revision' is clearly an optimistic-concurrency token and 'browser_session_id' versus 'map_session_id' are two distinct session scopes, none of which is explained anywhere.

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 (redo) and a specific target (the editor's latest combined history entry), which is enough to distinguish it from the read/list siblings. It stops short of naming its counter-operation 'undo', so the pairing must be inferred from the tool name alone.

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

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

There is no statement of when to call this versus undo, no prerequisite such as 'only valid immediately after an undo', and no mention of what to do when the redo stack is empty. The agent must guess the ordering semantics.

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, readOnlyHint=false, and non-idempotency; the description adds real value by explaining that an empty replace-mode call clears the selection, which justifies the destructive flag. However, it never explains what add or toggle do, nor the concurrency role of expected_revision, so the mutation behavior remains partly opaque.

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 no filler. It is efficiently written, though the brevity comes at the cost of coverage rather than being a virtue in itself.

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

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

This is a 5-parameter, 4-required mutation tool with no output schema and no annotation-level detail about revision semantics or mode behavior; the description covers only a fraction of that burden. An agent could not reliably invoke add/toggle modes or satisfy expected_revision from this text.

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 parameter meaning and largely doesn't. It mentions the 256 cap (already encoded as maxItems) and one mode edge case, but leaves mode's add/toggle values, expected_revision, browser_session_id, and map_session_id entirely unexplained.

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 ("Select") and states a capacity limit, but it refers to "editor IDs" rather than actors, leaving the agent to infer that the resource is actors in the map editor. It also doesn't distinguish selection-state mutation from siblings like list_actors or place_actor.

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 versus list_actors, place_actor, or move_actors. The only usage-adjacent statement is "An empty replace clears selection," which explains one edge case but not the decision context.

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, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description does add real value by disclosing that it can revert a human edit and only the latest combined entry, but it omits what happens on revision mismatch, whether the undo is reversible, and any concurrency/permission expectations for a destructive operation.

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

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

A single front-loaded sentence with no filler; the verb and scope come first. It is slightly under-specified rather than bloated, but there is no wasted wording.

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, non-idempotent mutation with three fully undocumented required parameters and no output schema, the description is too thin. It leaves the agent without the meaning of `expected_revision`, the granularity of a 'combined history entry', or the outcome of a failed undo.

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% across three required parameters, so the description must compensate and largely does not. It never mentions `browser_session_id`, `map_session_id`, or `expected_revision` — the last of which is clearly a concurrency guard the agent needs to understand. 'Latest' vaguely gestures at revision semantics but gives no syntax or failure behavior.

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: undoes the editor's latest combined history entry. It is distinguishable from the sibling `redo`, but the phrase 'combined history entry' is jargon that leaves the exact unit of reversal ambiguous. The clarifying clause 'including a human edit' hints at scope without fully defining it.

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

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

Implied usage (revert the most recent edit) is apparent, but there is no explicit when-to-use/when-not guidance and no mention of the obvious alternative `redo`. Nothing tells the agent how this behaves relative to state-reading siblings like `get_state`.

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