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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says a copy occurs but does not state whether existing files are overwritten, whether the game must be closed, what permissions are required, or what happens on conflict. For a mutation tool with no annotations, this is a significant 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?

It is a single efficient sentence with the source and destination front-loaded and no wasted words. However, its brevity contributes to the behavioral and parameter gaps rather than being optimally balanced.

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?

An output schema exists, so return values need not be explained. But for a file-copy mutation tool with no annotations and an undocumented required parameter, the description lacks critical context about overwrite behavior, prerequisites, and parameter format.

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

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

Schema description coverage is 0%, and the sole required parameter `project` has no description in the schema. The description only weakly implies that `project` refers to a mod project, without explaining its format, accepted values, or path conventions.

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 (copy), a specific source (`src/reframework/**`), and a specific destination (`the game's reframework folder`). It is clearly distinguishable from the sibling tools, which mostly control the game or inspect data, but it does not explicitly contrast itself with them.

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

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

The description implies deployment but gives no explicit when-to-use guidance, no prerequisites (e.g., game closed, project selected), and no alternatives. An agent must infer that this is the step for installing a mod project's files.

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

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

With no annotations, the description carries the full burden. It usefully discloses the output ordering ('sorted by value'), but does not state that this is a read-only query, what happens with an invalid type name, or whether enum types must be fully qualified beyond what the examples suggest.

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 zero waste; the core behavior and illustrative examples are packed efficiently.

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?

An output schema exists, so return values need not be explained, and the single-parameter surface is simple. However, the description omits the discovery path for valid enum type names and error behavior, which are the main remaining 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 must compensate for the undocumented 'type_name' parameter. The examples ('app.Character.JobEnum', 'app.WeaponID') do show the expected fully-qualified format, which is valuable, but they do not explain how to discover valid type names.

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

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

The description states a specific resource (named values of an enum type) and includes concrete example type names, so an agent knows it enumerates members of a single enum. It does not distinguish itself from the sibling dd2_types, which likely lists available types, leaving a small ambiguity.

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, no mention of prerequisites (e.g. that the type name must come from dd2_types), and no comparison with alternatives like dd2_types or dd2_job. Usage is only implied by the examples.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that print() output and returned values come back, and that state changes require phase='update', but it does not mention risks of arbitrary code execution, timeout behavior, error handling, or whether the call can destabilize the game.

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

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

Two tight sentences with no waste. The primary action is front-loaded, and the critical phase='update' condition follows immediately.

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?

An output schema exists, so return-value explanation is not required, and the description covers the core purpose and update-phase requirement. However, for an arbitrary-code-execution tool with no annotations and 0% schema descriptions, the missing timeout semantics, default frame phase, and safety context leave meaningful 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 must compensate. It explains 'code' as a Lua chunk and partially explains 'phase' by noting phase='update' for state changes, but it never explains the default phase='frame', nor does it describe the 'timeout' parameter or its units/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?

The description uses a specific verb and resource: 'Run a Lua chunk in the running game.' It clearly distinguishes the tool as a general Lua execution mechanism, though it does not explicitly contrast itself with the many dd2_* sibling tools that expose specific game functionality.

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

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

It provides a concrete usage rule: phase='update' runs inside UpdateBehavior and is 'required for state changes.' This tells the agent when to choose the update phase, but it does not say when to use dd2_eval at all versus the domain-specific sibling tools such as dd2_give_item or dd2_job.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the mutation effect and the return shape ("report the before/after count in the player's storage"), plus the update-phase timing and a verified edge case, but says nothing about permissions, additive stacking behavior, or what happens on failure.

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

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

Two tight sentences, with the core action front-loaded ahead of edge-case scope. The verification anecdote ("Torn Letter 376, 2026-10-26") is somewhat noisy for an agent but does convey tested coverage.

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?

Output schema exists, so return format needn't be spelled out, and the description does mention before/after counts. But for a two-param mutation tool with no annotations and zero schema descriptions, it should at minimum tell the agent where item_id comes from and whether count is additive.

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

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

Schema description coverage is 0% and neither parameter is mentioned in the description — not item_id (an integer with no stated source such as dd2_items), nor count (defaulted to 1, with no statement of whether it adds to the existing stack). This is the definition's largest gap.

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

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

Names a specific verb and resource ("Give the player an item") and adds scope via "(update phase)", which distinguishes it from read-only siblings like dd2_items or dd2_recent_items. It stops short of naming a sibling explicitly, so it is clear but not fully differentiated.

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

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

The scope note "Works for every category incl. quest letters" tells the agent this is a general-purpose item granter rather than a category-specific one, which is useful selection guidance. However there is no explicit when-not or pointer to an alternative tool for inspecting item IDs or inventory, so 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?

No annotations are provided, so the description carries the full burden. It does disclose the important non-obvious trait that a non-zero delta turns this into a mutation, which is valuable. However, it omits whether Rift Crystals are also modified, what happens if the delta exceeds the current balance, clamping/negative behavior, and whether changes persist to the save.

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 read purpose front-loaded and the mutation caveat appended. Slight loss of clarity from the ambiguous 'gold first' phrasing, but no wasted words.

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

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

An output schema exists, so return values need no explanation. But for a tool that can mutate save data, the description is thin on limits, clamping, and whether Rift Crystals are writable — gaps an agent needs before calling with a delta.

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?

One parameter with 0% schema description coverage, so the description must compensate. It explains that delta adds or deducts gold, but the phrase 'gold first' is cryptic and leaves unresolved whether Rift Crystals are affected by the same delta or whether a second call is needed.

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

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

The description names a specific verb (read) and specific resources (gold and Rift Crystals), and flags the secondary write path via delta. It is clear what the tool does, though it doesn't explicitly contrast itself with siblings like dd2_give_item or dd2_status.

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

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

Usage is only implied: read gold/RC, or pass a delta to modify. There is no explicit guidance on when to prefer this over dd2_give_item or dd2_items, and no stated preconditions (e.g., needing dd2_status or a loaded save first).

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

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

No annotations are provided, so the description carries the full burden. It does disclose one important side effect, 'the game pauses itself', which an agent could not infer from the empty schema, but it omits preconditions and failure behavior for a tool that manipulates window/control state.

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 action front-loaded and the state side-effect appended; every clause 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?

An output schema exists, so return details are covered elsewhere, and the empty schema needs no explanation. The description supplies the paired-tool relationship and the pause behavior, leaving only edge-case preconditions 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?

The tool takes zero parameters, and the description correctly introduces none. Baseline of 4 applies since there is nothing further to document.

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

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

States a specific action (return the screen) and names the exact source of the target window (the one saved by dd2_take_control), which cleanly positions it as the inverse of that sibling. It falls short of 5 only because 'return the screen' is slightly abstract about what is being restored.

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?

Referencing dd2_take_control gives the agent clear context for when to invoke this tool: after control has been taken. No exclusions or error conditions (e.g. what happens if take_control was never called) are described.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this writes/updates a script and that reload=True re-runs it in the running game, including the bridge 0.5.0+ in-memory requirement. However, it does not state overwrite behavior, whether the game must already be running for reload, or what happens on failure.

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

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

The description is a single efficient sentence with the core action front-loaded and the reload behavior appended as useful qualification. There is no redundant or filler text.

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

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

For a one-parameter install/update tool with an output schema and no annotations, the description covers the essential behavior and version constraint. Minor gaps remain around reload prerequisites and failure/overwrite semantics, but nothing critical for calling the tool is missing.

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

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

Schema description coverage is 0%, so the description must explain the single reload parameter, and it does: reload=True re-runs the bridge in the running game so changes need no restart. It does not explicitly explain reload=False, but the contrast is strongly implied by the install/update-only baseline.

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

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

The description names a specific verb pair (install/update), the exact resource (dd2mcp eval bridge script), and its target location (reframework/autorun). This clearly distinguishes it from the many dd2_* query/eval tools, none of which concern bridge installation.

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

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

It gives clear usage context: install or update the bridge, and use reload=True to re-run it in the running game so bridge changes need no restart. It does not explicitly name when-not-to-use cases or alternatives, but the unique bridge-management purpose makes the intended context clear.

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

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

With no annotations, the description carries the burden, and it does disclose the key behavioral trait: matching is by substring on the display name, not exact id. It leaves out case sensitivity, whether multiple matches are returned, and what an empty result means.

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

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

One sentence, front-loaded with the verb and outcome, with a parenthetical example that earns its place. Nothing redundant.

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

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

The tool is simple, has one parameter, and ships an output schema, so return values need no explanation here. Adding match-case behavior and multi-match expectations would close the remaining gap.

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

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

Schema coverage is 0% and the single 'name' property has no description, so the description must compensate — and it does, explaining that the value is a display-name substring and giving a concrete example ('ferrystone'). It does not clarify whether the id itself is also matchable.

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 ('Find') and resource ('item ids') plus the matching rule ('display-name substring'), which is far more informative than the bare name dd2_items. It implicitly separates itself from write-path siblings like dd2_give_item, but never names an alternative explicitly.

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

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

There is no statement of when to use this versus dd2_recent_items, dd2_give_item, or dd2_types, and no prerequisites or exclusions. The only hint of usage is the implied lookup-for-an-id workflow, which the agent must infer.

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

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

With no annotations, the description carries the full behavioral burden and does disclose important risk: jobs above 10 have crashed the game, force=True is required, and the operation should only target a test character with save guard armed. It does not cover every operational detail such as persistence or permissions, but the destructive risk disclosure is strong.

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

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

The description is compact and front-loads the read behavior before the critical set_job warning. The crash timestamp and exception code are detailed but earn their place by making the risk credible; the text could be slightly more structured but is not bloated.

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

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

For a tool with three parameters, no annotations, 0% schema description coverage, and an output schema, the description is mostly complete: it explains read behavior, write behavior, dangerous values, force, and target restrictions. Return values need not be explained because an output schema exists.

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

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

Schema description coverage is 0%, so the description must compensate. It documents who (player or pawn1..pawn3), set_job as the vocation change, and force as required for dangerous jobs above 10; this meaningfully explains all three parameters despite the empty schema descriptions.

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

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

The description clearly states the tool reads vocation state for player or pawn1..pawn3, listing current job, JobIndex, exp, and job bits, and explains that set_job changes vocation. It is specific about the resource and operation, though it does not explicitly contrast with sibling tools, which is reasonable because no sibling appears to cover jobs.

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

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

It gives explicit usage conditions: set_job is for changing vocation during the update phase, jobs above 10 crashed the game and require force=True, and such changes belong only on a test character with the save guard armed. These are clear when-to-use, when-not-to-use, and precondition guidelines.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose two real traits: a single discrete press (not a hold or repeat) and automatic focusing/raising of the game window. It does not disclose timing, whether the press is synchronous, how failures surface, or what permissions/focus constraints are required.

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 that front-loads the action, then supplies the one decoded parameter inline, then the behavioral caveat. No filler, no repetition of the title.

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?

Output schema exists, so return values need no explanation. For a 2-parameter input tool the description covers both parameters and the one surprising behavior (auto-focus). Remaining gaps are edge-case behaviors (game not running, key not delivered), which are modest for this tool's complexity.

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

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

Schema description coverage is 0% and the schema provides only bare names 'scan' and 'focus'. The description compensates well: it defines scan as a hardware scan code and supplies four example codes, and it explains that focus controls whether the game is brought forward before the key is sent. Minor gap: it does not state the default (Esc 0x01 / true) as a default.

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: 'Send one key press ... to the game'. The parenthetical pins down exactly what a key press means here (hardware scan code) and gives concrete examples, so scope is unambiguous. No sibling sends input, so no disambiguation is strictly needed, which keeps it at 4 rather than 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?

'focusing it first unless focus=False' implies the game may not be in the foreground, which is useful situational context, but the description never says when to use this versus related tools (dd2_take_control, dd2_pause_state) or what preconditions exist (e.g. game must be running). Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses idempotency-like behavior ('no-op if it is running') and the save-loading limitation. It does not state whether the call blocks until the game is ready, what happens if Steam is unavailable, or other failure behavior, leaving meaningful gaps for a launch action.

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

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

Two short sentences with no waste. The main action and the key no-op condition are front-loaded, and the save-loading caveat is placed after the core 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 zero-parameter launch tool with an output schema, the description covers the essential action and the important no-op case. It is nearly complete, though it could mention failure modes or whether the call waits for the game to finish loading.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. The schema is empty and fully described, and the description does not need to compensate for missing 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: 'Start DD2 through Steam.' The parenthetical 'no-op if it is running' further sharpens the action, and the final sentence clarifies the boundary that loading a save still requires the player. This is easily distinguishable from siblings such as dd2_status, dd2_quit, and dd2_take_control.

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

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

The description gives clear usage context: this launches DD2 and is safe to call if the game is already running. The caveat about loading saves needing the player is useful. However, it does not explicitly name alternatives or exclusion conditions, such as checking dd2_status first or using dd2_take_control afterward.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It identifies the scope as the current game run, but does not state whether the operation is read-only, whether results are truncated, how many lines are returned by default, or any permission or rate-limit considerations.

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

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

The description is a single well-formed sentence with no wasted wording. The core purpose is front-loaded, and the optional filter is described immediately afterward.

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

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

The tool is simple and an output schema exists, but the description still omits important details about the undocumented lines parameter, default behavior, and whether the log is truncated. For a two-parameter tool with no schema descriptions or annotations, more context is needed.

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 explain both parameters. It adds useful meaning for the pattern parameter by describing substring filtering and giving examples, but it does not explain the lines parameter at all.

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

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

The description clearly states that this tool retrieves the REFramework log for the current game run and supports optional substring filtering. It is specific about the resource and operation, though it does not explicitly distinguish itself from sibling tools such as dd2_status or dd2_recent_items.

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

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

The only usage guidance is that filtering is optional, with example substrings. There is no explicit statement of when to use this tool versus alternatives, nor any exclusions 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?

With no annotations, the description carries the full burden; it implies a read-only state probe but never states that it is non-mutating or side-effect free. It does add useful behavioral context by decoding PauseType values, but omits what happens when the game is not paused or which apps can appear as pausers.

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 and front-loads the core question, but the text is malformed: a missing space runs 'app.PauseManager.PauseType' together into an ambiguous token, and the parenthetical enum note is appended without a clear connection to the reported values.

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 an output schema, the description covers what is reported and how to interpret a key enum value. Minor gaps remain, such as the meaning of 'by which app' when multiple pause sources exist, but the output schema carries the return shape.

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 parameterless tool applies. No parameter text is needed or missing.

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

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

The description names a specific resource and question: whether the game is paused and which app caused the pause. It is clearly a state-query tool, distinguishable from siblings like dd2_status or dd2_key by domain, though it never names a sibling explicitly.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. The only usage-adjacent help is the interpretation hint that PauseType 5 means the InGame pause menu, which is semantic decoding rather than invocation guidance.

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

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

No annotations are provided, so the description carries the full load, and it does substantial work: it discloses that this is a hard kill with no clean exit path, and that data loss is avoided only if the save guard is armed. What it does not state is what happens if the guard is not armed, or whether it fails gracefully when the game isn't running.

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 action and its kill semantics are front-loaded in the first clause, ahead of the safety caveat. Two sentences is the right size, though the stacked parentheticals and the unresolved question mark in 'test units only?' add noise an agent must interpret.

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?

An output schema exists, so return values need not be described, and the description still flags that a saves report comes back. For a destructive one-parameter tool with no annotations, it covers the essential risk and prerequisite; only the unarmed-guard failure mode is left unspecified.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it gives the exact accepted format 'YYYY-MM-DD HH:MM[:SS]' and explains that the parameter triggers a report of saves written since that time. The trailing 'test units only?' hedges the scope of the parameter rather than clarifying it.

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

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

States a specific verb and resource: 'Close DD2', immediately qualified as a 'hard kill' because there is no scripted clean exit. That combination tells an agent exactly what the tool does and distinguishes it from dd2_launch. It falls short of 5 only because the trailing 'since' sentence muddies the main action with a secondary reporting behavior.

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

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

Gives a clear trigger condition, 'as soon as in-game testing ends', which implicitly excludes using it during active testing. It also surfaces a prerequisite by noting that with the save guard armed nothing is lost, pointing an agent at dd2_saveguard before invoking, though the sibling is never named explicitly.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses sort order (StorageData._UpdateIndex, newest first), the exact fields surfaced, and the key-item tab behavior. It never explicitly states this is a read-only log requiring a running game/bridge, which is the main omission.

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

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

A single front-loaded sentence that leads with 'Item log' and the scope, then layers parenthetical detail. Dense with parentheticals but each clause adds information rather than restating the name.

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

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

An output schema exists and the description still enumerates returned fields, so return values are well covered. However, for a two-parameter tool with no annotations, leaving the filter semantics of `name` undefined is a substantial hole.

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

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

Schema description coverage is 0% and both parameters are undocumented. `limit` is never mentioned, and `name` is entirely unexplained — the description does not say whether it filters by item name or owner, or how it interacts with the 'recent items' scope.

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: the most recently changed inventory entries across player, pawn and stash storages, newest first. The 'recently changed' scope implicitly distinguishes it from the full-inventory sibling dd2_items, but that sibling is never named, so the differentiation must be inferred.

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

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

No explicit when-to-use or alternative routing, but the parenthetical 'DD2 keeps no pickup history' functions as a when-not caveat that prevents a common misuse. An agent still has to guess whether to reach for this or dd2_items for a full snapshot.

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

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

With no annotations, the description must carry the full behavioral burden, and it does disclose several useful traits: the index is offline, may be stale versus game patches, and matching is case-insensitive regex. It does not disclose what action='download' actually does on disk (overwrite? network fetch? permissions? size/time cost), which is a meaningful gap for a tool that can mutate local state.

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

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

Four compact sentences with no filler; the core purpose leads the text. The opening sentence is overloaded with parenthetical provenance, but nothing is redundant and each remaining sentence adds a distinct fact.

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?

An output schema exists, so return shape need not be described. However, for a 4-parameter tool at 0% schema coverage with no annotations, leaving 'limit' and the action enum undocumented leaves an agent guessing about pagination and valid mode values.

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

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

Schema coverage is 0%, so the description must compensate, and it only partly does: it explains that 'pattern' is a case-insensitive regex over type names and expands to field names/types when fields=True, and that action='download' refreshes the dump. It never mentions 'limit' (default 200) or enumerates valid action values besides 'download' (search is the default).

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 and resource ('Offline type dump search') and identifies the backing data source (alphaZomega RE_RSZ rszdd2.json, all serializable types + fields), so an agent knows exactly what it queries. It also distinguishes itself from the live sibling dd2_types, though the distinction is buried at the end rather than stated up front.

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

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

It gives a clear use condition ('no game needed' / offline browsing) and points to the alternative when freshness matters ('The dump can lag game patches: confirm live with dd2_types'). It does not say when not to use it beyond the staleness caveat, but the routing signal to the live sibling is explicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses that arm refuses saves outside test units, that Auto/AddAuto slots are blocked unless autosave=True, that the game saves slot 0 on load, and that the guard resets on restart. It omits what a refusal looks like (silent block vs. error) and whether disarm is immediate, leaving some behavioral gaps.

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 and front-loads arm behavior, but the sentence structure is awkward: a title fragment, then quoted action names in a list ('disarm', 'status'), then workflow and reset notes. The information density is fine but the formatting costs clarity for an agent parsing 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?

An output schema exists, so return values need not be explained. For a three-parameter tool with 0% schema descriptions, the description covers the actions, units, and autosave meaning adequately, though it could say what happens when a save is refused and whether that surfaces as a tool error.

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

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

Schema coverage is 0%, so the description must compensate and largely does: it explains units as test units, the effect of autosave=True, and enumerates the action values arm/disarm/status that the schema does not. The stated '(default [0])' conflicts with the schema default of null, which slightly muddies the units semantics.

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

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

It states a specific function: a save guard with 'arm'/'disarm'/'status' actions that block saves outside test units. The verb-and-resource are clear enough to distinguish it from dd2_saves, though the opening fragment 'Bridge save guard' is jargon an agent must decode from the rest.

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

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

It gives a concrete when-to-use rule: arm before loading a scenario so the load-time autosave cannot overwrite it. It does not explicitly say when to prefer status or disarm beyond naming the actions, and names no alternative sibling, so it stops short of a 5.

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

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

With no annotations, the description carries the full disclosure burden; it does deliver the key operational constraint that restore requires the game to be closed. It does not say whether restore overwrites existing save files or whether a backup replaces an existing snapshot of the same label, which are significant omissions for a mutating tool.

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

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

Very compact — every clause carries information about a distinct action, and the resource statement is front-loaded. The formatting is a slightly awkward run-on with nested quoting, but there is no filler.

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

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

An output schema exists, so return values need not be described, and the action/name matrix is covered. The remaining gap is the destructive semantics of restore and where snapshots are stored, which matters for a save-mutating 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 0%, so the description must compensate, and it largely does: it defines what 'name' means for each action and gives the exact timestamp format for 'touched'. It does not state that 'list' ignores name or that the default action is 'list'.

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

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

States the resource (save snapshots) and enumerates the four operations, so an agent knows exactly what the tool manipulates. It does not differentiate from the sibling dd2_saveguard, which sounds closely related, so it falls short of a 5.

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

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

Per-action semantics are spelled out ('backup' = label, 'restore' = snapshot folder, 'touched' = timestamp), and one important precondition (game must be closed for restore) is given. However, there is no guidance on when to pick this tool over dd2_saveguard or when each action is appropriate.

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

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

With no annotations, the description carries the full burden and does well: it discloses that shelve archives a live slot, that load quits the game when restart=true, arms the save guard and verifies play time, and that the game steals focus during boot. What's missing is the risk side of 'load' – whether it overwrites the current save/progress before unshelving.

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

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

Front-loaded with the entity and scope, then action-by-action detail, then slot types, then the focus handoff. Dense but every line carries information; the parenthetical nesting in the 'load' sentence is the only place readability slips.

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?

An output schema exists, so return values needn't be explained, and the description covers actions, prerequisites, side effects and the follow-up handoff to dd2_hand_back. It is nearly complete for a six-parameter mutating tool; only the overwrite behavior of 'load'/'unshelve' on existing saves is 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 coverage is 0%, so the description must compensate and largely does: it maps action to four values, attaches name/slot/area/notes to shelve and name to unshelve/load, and defines restart. The slot-type legend (0 Auto, 1 Last Inn Rest, 2 unmoored, 3 Clear, 4 AddAuto) adds real meaning, though it doesn't say which of the 0-4 range the 'slot' argument accepts when shelving a new entry versus restoring.

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

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

Opens with a specific verb+resource framing ('Test-harness save scenarios, single slots of the test character unit') and enumerates the four actions it performs. It is clearly distinct from siblings like dd2_saves (actual save files) and dd2_saveguard (the guard itself) because it names the guard as something this tool arms rather than provides.

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

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

Gives per-action guidance and the key gating condition ('unshelve ... game must be closed'), plus the semantics of restart=true. It stops short of stating when an agent should prefer this over dd2_saves or dd2_launch for a plain launch, so the boundary with those siblings is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: it captures only the *primary* screen (scope limit), the format is PNG, and the output is a file path requiring a separate image-capable Read to view. It omits where the file is written, whether it overwrites previous captures, and multi-monitor handling.

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, front-loaded with the core action and followed by the required follow-up step. Every clause earns its place with no filler.

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

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

With zero parameters and an output schema present, the description needn't explain return values, and it adds the critical operational note that the path must be opened with an image-capable Read. Minor gaps remain around file location and preconditions, but nothing essential to calling it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies a no-argument call.

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 ('Capture the primary screen to a PNG') plus the return artifact (its path). No sibling tool in the list performs screen capture, so an agent can distinguish it immediately.

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

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

The description tells the agent what to do with the result ('open it with an image-capable Read'), which is useful workflow guidance, but it never states when this tool should be used or under what conditions (e.g., game running, needing visual verification). Usage is only implied.

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

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

No annotations are provided, so the description must carry behavioral weight. It usefully discloses a conditional: player position is only reported 'if a save is loaded', which tells the agent results vary by game state. It does not confirm the call is side-effect free or whether it is safe to poll repeatedly.

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 most important content (game process, bridge state) comes first. It loses a point only because the fragment form makes the payload list read as description rather than a clear statement of what the call returns.

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 zero parameters and an output schema present, the description does not need to explain return values, and it correctly notes the save-loaded precondition. However, for a diagnostic entry point among 24 siblings it still lacks the guidance an agent needs on when to reach for it and whether it is safe to call at any time.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly adds no spurious parameter discussion.

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

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

The description enumerates exactly what the tool reports: game process state, REFramework revision, bridge state, and player position. That is specific enough to distinguish it from siblings like dd2_log or dd2_pause_state, but it is written as a noun-phrase fragment with no verb (e.g., 'Returns...'), so the action is inferred rather than stated.

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

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

There is no statement of when to call this versus alternatives such as dd2_log, dd2_pause_state, or dd2_install_bridge, and no mention of whether it should be used as a first diagnostic step. The only implicit cue is that it is a status read, which the agent must infer.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavior: it remembers the terminal window, focuses the game, closes the focus-loss pause menu, and checks PauseManager before sending Esc. It does not mention failure modes if the game is absent or whether the window memory is restored automatically, but the core side effects are well covered.

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

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

The description is two dense sentences with no wasted framing, and the core action is front-loaded. The parenthetical about PauseManager and Esc is useful but makes the second clause slightly hard to parse in one pass.

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 focus-control tool with no annotations, the behavioral narrative is fairly complete and an output schema exists so return values are covered. However, the only parameter's meaning is left implicit despite 0% schema coverage, which is a real gap for correct invocation.

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

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

Schema description coverage is 0% for the single 'unpause' boolean, so the description needs to compensate. It mentions closing the pause menu, which implicitly relates to unpausing, but never names the parameter or explains what setting unpause=false would do. An agent must infer the parameter's effect.

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: 'Bring DD2 to the front for testing.' It also distinguishes the complementary role of dd2_hand_back, so an agent can tell the two apart. It stops short of a crisp one-line scope statement because the pause-menu mechanics are woven into the same sentence.

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

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

It gives clear pairing guidance: use dd2_hand_back 'whenever the player needs to read output or answer.' That implies when to take control versus hand back. It does not state exclusions for testing contexts or what to do if the game is not running, so it is clear but not exhaustive.

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

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

No annotations are provided, so the description must carry behavioral disclosure. The word 'Introspect' strongly implies a read-only operation and the description explains the two kind modes, but it never explicitly confirms there are no side effects, whether authentication is needed, or how results are returned.

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 single sentence is front-loaded, information-dense, and contains no filler. It states the operation, the main mode distinction, and the optional filter in one pass.

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?

An output schema exists, so return values need not be described. However, with three parameters and no schema descriptions, the definition still leaves the meaning/format of 'type_name' and the scope of 'managed type' underspecified for an introspection tool.

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

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

Schema description coverage is 0%, so the description should compensate. It usefully clarifies that 'kind' accepts 'methods' (for signatures) or 'fields' and that 'filter' is a substring match, but it leaves 'type_name' and the notion of a 'managed type' 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 ('Introspect') and resource ('a managed type'), and names the two supported kind values. It does not differentiate from siblings such as dd2_enum, so it stops short of 5.

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

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

It explains the two modes ('methods' vs 'fields') but gives no guidance on when to use this tool instead of alternatives like dd2_enum, nor any exclusions or prerequisites. The usage is merely implied by the kind options.

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

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

With no annotations, the description carries the full burden and does well: it discloses auto-starting Vortex, refusing switches while DD2 is running, creating a missing profile from <project>/dd2mod.json, enabling REFramework, and deploying. It doesn't mention cost/latency or the blast radius of the deploy step, which keeps it off a 5.

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

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

The global constraint and action list are front-loaded, and the parenthetical format packs a lot of information into a short space. The action block is somewhat run-on and requires careful parsing, which is a minor structural weakness.

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?

An output schema exists, so return values need not be explained, and the description covers prerequisites, side effects, and per-action inputs for a stateful tool with three undocumented parameters. A note on whether the deploy step touches game files would close the remaining gap.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it explains that 'profile' is a name used with 'switch' and 'project' is a mod project directory read from <project>/dd2mod.json. The action parameter's valid values are enumerated but not typed or formally declared, leaving some ambiguity about invalid input handling.

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+resource (managing Vortex profiles for DD2) and enumerates each action with its distinct effect, so an agent can tell what the tool does without opening the schema. It stops short of contrasting itself with overlapping siblings such as dd2_deploy or dd2_status.

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

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

Each action carries its own usage context ('switch' needs a profile name, 'dev'/'release' need a project dir, 'play' restores the pre-switch profile), and the constraint 'refuses switches while DD2 runs' is an explicit when-not condition. It never names an alternative sibling tool to use instead, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden, and it does add useful behavior by stating the no-filter result shape and the vocation-mask encoding. It does not explicitly state that the tool is read-only or describe any access constraints, leaving a gap for a tool with zero annotation coverage.

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

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

The definition is two compact sentences, front-loaded with the table fields and then the filtering behavior. Every sentence adds information without repetition.

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

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

Given the moderate complexity, existing output schema, and absence of annotations, the description supplies enough context to invoke the tool correctly: available fields, filters, and default unfiltered behavior. It stops short of clarifying safety/read-only semantics and its relationship to other item-related 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?

Schema coverage is 0%, so the description must explain the parameters, and it does: job is tied to JobEnum 1-10, weapon_prefix is a WeaponID prefix such as 'wp07', and name is a substring filter. It does not cover null/default behavior or matching details such as case sensitivity, so it is strong but not exhaustive.

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

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

The description clearly identifies the resource as the weapon item table and lists its fields, so an agent can tell this is a weapon-data lookup rather than a general item tool. It does not explicitly differentiate itself from siblings such as dd2_items, so it falls short of a 5.

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

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

It explains how to filter by job, weapon prefix, or name substring, and notes that an unfiltered call returns counts per type. However, it gives no explicit guidance on when to choose this tool over related siblings like dd2_items.

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