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

Annotations already mark it read-only and non-destructive, but the description adds valuable behavioral context: it explicitly says 'READ-ONLY', 'Does not contact PPSSPP', and clarifies that it only reads and filters a log file. This goes beyond the annotations and removes any ambiguity about side effects.

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

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

The description is well-structured with PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Every section is short, informative, and front-loaded with the tool's core purpose. No filler or redundant explanation.

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

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

For a read-only log filter tool, the description covers the purpose, default path, optional filter behavior, side-effect-free behavior, and return shape. The rich parameter schema and output schema cover the remaining details, making the definition complete for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents each parameter well, including defaults, whitelist restrictions, and case sensitivity. The description summarizes defaults but does not add substantial new parameter semantics beyond what the schema provides.

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?

Description states a specific verb ('Filter'), a specific resource ('PPSSPP log file'), and explicit line types (ERROR/WARNING/CRASH). It clearly distinguishes this from the many sibling PPSSPP tools, none of which are log-filtering tools.

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

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

The description gives clear usage context: log_path is optional with a documented default, filter is an optional keyword, and session_id is reserved. It does not explicitly state when not to use it or compare against alternatives, but the tool's function is unique among siblings and the usage section is concrete.

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 description explicitly labels the operation DESTRUCTIVE, matching the destructiveHint annotation, and adds concrete protection details: kernel and top.prx ranges require force=true and partial writes surface an error instructing disassembly. This goes well beyond the annotation's single boolean.

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 labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) front-load the most important information and keep it to a compact block. No filler sentences.

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

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

For a mutation tool with full schema coverage and an output schema, the description covers invocation, formatting, destructive behavior, protected ranges, partial-failure behavior, and return shape. The only gap is explicit sibling differentiation, which is already penalized under usage guidelines and does not make the definition incomplete for 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 coverage is 100%, so the baseline is 3; the description adds value by clarifying that code may contain newline or semicolon separators, that armips-style comments are unsupported, and that force is required for protected ranges. It does not add address/session_id semantics, but the schema already documents those.

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 opens with a specific action ('Assemble MIPS instruction(s)') and a clear resource ('write the resulting bytes to memory'). This differentiates it from ppsspp_write_memory (raw writes) and ppsspp_disassemble (reading) without requiring the agent to open the schema.

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

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

The USAGE section specifies the required inputs (session_id, address, code) and code formatting ('\n' or ';' separated, no armips comments), and explains that the tool loops because PPSSPP assembles one line per call. However, it never names sibling alternatives like ppsspp_write_memory or states when to choose this over them; usage is implied rather than explicitly routed.

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 description goes beyond annotations by detailing the asynchronous abort behavior: the job's finally block releases the session lock, enabling immediate use. It specifies timing ('step boundary', 'mid-wait cuts within ~1s') and error conditions (cancelling finished job is error). This adds significant behavioral context that annotations do not capture, such as the non-instant cancellation and lock release semantics.

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 tightly structured with clear sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Every sentence contributes: purpose states the action, usage gives the source of the parameter, behavior explains side effects and timing, and returns tells what to poll. No filler or redundancy.

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

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

The tool is a cancel operation with one parameter and a well-defined output schema. The description provides all necessary context: what to pass, what happens on cancellation (lock release, timing), error conditions, and guidance to poll status. Since output schema is present, return values don't need elaboration. The description fully compensates for the 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?

The schema already provides 100% coverage for the single parameter (batch_id) with a clear description. The tool description repeats the same source ('batch_id from ppsspp_batch_step(background=true)'), adding no new meaning. Since schema does the heavy lifting, a baseline of 3 is appropriate.

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

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

The description uses a precise verb ('cancel') with a specific resource ('queued or running background batch job'). It clearly distinguishes from siblings by stating the scope ('background batch job') and referencing the providing tool 'ppsspp_batch_step(background=true)'. This prevents confusion with other batch tools like status or list.

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 explicitly states when to use it: to cancel a queued or running background job, and how to obtain the batch_id. It also mentions a caveat: cancelling an already-finished job is an error, and advises checking ppsspp_batch_status first. However, it does not explicitly state when NOT to use it or name alternatives, though the sibling list is large and the specific scope is clear.

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

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

Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: 'Lock-free registry read — never opens the WS transport and never waits for the per-session lock,' plus ordering and retention eviction semantics. This adds real operational context the annotations do not provide.

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 organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Every sentence carries useful information, including the return shape and retention behavior, with no filler or 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?

For a zero-parameter, read-only list tool with annotations already declaring safety and idempotence, the description covers all needed context: when to call it, ordering, eviction, what is returned, and its relationship to sibling tools. Nothing essential is missing.

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

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

There are zero parameters and the schema is empty with 100% coverage, so the baseline is 4. The description correctly reinforces 'no parameters' and explains why that is sufficient for the tool's list-survey purpose.

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: 'Survey all background batch jobs currently retained by the registry.' It also explicitly positions itself as the 'list companion' to ppsspp_batch_status / ppsspp_batch_cancel, which distinguishes it from those sibling tools.

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

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

It gives concrete when-to-use guidance: 'recover a batch_id after the submit response was lost' or 'survey background activity before touching the session.' It does not explicitly state when not to use it versus status/cancel, but the context is clear enough, so this is one step below full exclusion guidance.

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

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

The description goes well beyond the readOnly/idempotent annotations by disclosing the lock-free registry read behavior, that it never opens the WS transport, and that it is safe during session-owning operations. It also explains how executed-step counts update and what 'completed' contains.

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?

Clearly sectioned PURPOSE, USAGE, BEHAVIOR, and RETURNS makes the content scannable and front-loaded. Every section contributes distinct, useful 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?

With one simple parameter, strong annotations, and a full RETURNS breakdown, the description gives the agent everything needed to call the tool correctly and interpret its result.

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

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

Schema description coverage is 100%, and the single parameter's schema description already explains that batch_id is returned by ppsspp_batch_step(background=true). The description reinforces this but adds little beyond the schema's own documentation.

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 PURPOSE line states a specific verb and resource: polls the state and progress of a background batch job. It also clarifies what it does not do ('without touching the session'), distinguishing it from other batch tools like ppsspp_batch_cancel and ppsspp_batch_list.

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 explicitly tells the agent where to get batch_id (from ppsspp_batch_step(background=true)), giving clear invocation context. It also explains when it is safe to call, though it does not explicitly contrast it with alternatives.

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?

Beyond annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses substantial behavioral detail: 'STATE-CHANGE,' session-lock hold duration, the 25s/30s budget-timeout interaction and BATCH_BUDGET_EXCEEDED error, per-step MCP progress semantics, foreground isError behavior with BATCH_STEP_FAILED, background immediate-submit semantics, and screenshot auto-skip during replay recording. This richly exceeds what the annotations convey.

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

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

The description is long but organized into labeled PURPOSE/USAGE/BEHAVIOR/RETURNS sections that front-load the core intent and make scanning easy. The BEHAVIOR section is dense with critical operational facts that have no home in the schema, so its length is justified. Minor redundancy exists between USAGE and the already-rich schema parameter descriptions.

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 this complexity — four step types, two execution modes, timeout interactions, and failure semantics — the description is complete: error codes, return shapes for both foreground and background, lock behavior, and routing to status/cancel siblings are all present. With a 100%-coverage schema and an output schema present, nothing an agent needs to select and invoke this tool 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents every parameter thoroughly, including examples in the steps array and timeout context in background. The description's USAGE/RETURNS lines summarize this structure but add no meaning beyond the schema — the 60fps frame detail, budget rejection, and polling routes all also appear in the schema.

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

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

The PURPOSE line names a specific verb+resource: 'Execute an ordered automation sequence of press / wait / state_probe / screenshot steps in one call,' which immediately differentiates it from single-step siblings like ppsspp_press_button, ppsspp_wait_frames, and ppsspp_screenshot. It also names the optional detached-background mode, so an agent knows both what the tool does and how it differs from related tools.

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

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

The USAGE line gives the required call shape (session_id + steps, on_failure, background), and the background parameter explicitly routes the agent to ppsspp_batch_status for polling and ppsspp_batch_cancel for cancellation, naming the sibling alternatives. However, it never explicitly says 'for a single press/wait/screenshot use the dedicated single-step tool,' so the when-not-to-use guidance 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?

The description is marked 'MUTATING' and explains important behavioral details: 'Reliable hits need CPUCore=2 (IR Interpreter)', 'mem_remove resolves the watchpoint's real size via mem_list first', and 'mem_update merges existing read/write/change unconditionally (PPSSPP zero-omits omitted bools)'. It also notes that CPU set/remove return no data. These are critical behavioral insights beyond the annotations, which are minimal (no readOnly, no idempotent, no destructive hints). The description compensates fully.

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 well-structured with labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). It is compact yet information-dense, with each sentence serving a purpose. The front-loaded PURPOSE and USAGE sections quickly orient the agent. No filler or redundancy.

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

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

Given the tool's complexity (10 parameters, multiple actions), the description covers essential aspects: purpose, usage patterns, behavioral caveats (CPUCore requirement, size matching, merge semantics), and return shape. The output schema exists, so return details are already structured. The description is complete enough for an agent to call the tool correctly without surprises.

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

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

Schema coverage is 100%, so the schema documents all parameters in detail. The description adds a summary of action semantics and the crucial note about size matching for remove/update. It also clarifies that for mem_update, passing read/write triggers a merge query. This adds meaning beyond the schema, especially the merger behavior and size matching caveat. A slight deduction because not all parameters are described in the description, but the schema is thorough.

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's purpose: 'Set, remove, update, and list CPU execution breakpoints and memory watchpoints.' It uses specific verbs and resources, distinguishing between CPU execution breakpoints and memory watchpoints. The sibling tools are mostly unrelated (memory read/write, stepping, etc.), so this tool stands out as the breakpoint manager.

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 explicitly instructs how to use the tool: 'action + session_id', and details which actions manage which type of breakpoint. It also notes that 'list/mem_list take no address' and that 'CPU set/remove return no data—the tool follows with a list for verification.' This gives clear usage context and differentiates between CPU and memory variants, though it doesn't explicitly mention when to choose this over siblings, but the purpose is unique enough.

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?

Description adds READ-ONLY and 'Pure arithmetic' beyond annotations (which already state readOnlyHint). It further clarifies no PPSSPP contact, which is not visible in annotations, adding genuine behavioral context.

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?

Uses minimal sections with clear labels; every sentence is informativeigator. The core purpose is front-loaded, and it avoids repetition of schema details.

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

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

Given the tool's simplicity, the description covers purpose, usage, behavior, and return values. With output schema present, return format is already documented. The only slight gap is not explicitly describing the 'auto' inference logic in the description, but that is covered by the schema.

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

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

Schema already includes detailed descriptions for all parameters (coverage 100%), so description doesn't need to explain them. However, the description does specify the offset (0x08804000) and mode inference logic, which adds context beyond the schema's enum 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 a specific verb ('convert') and resource ('address between IDA and PPSSPP address spaces') with exact offset. Without opening the schema it is clear what this tool does, and it is distinguishable from siblings like ppsspp_read_memory.

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?

Explains the required parameter (address) and the optional mode parameter with its auto detection behavior. It does not explicitly state when to choose this tool over alternatives, but given the tool's uniqueness (address conversion vs. memory ops), implied usage is clear enough.

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 description states READ-ONLY, notes that it calls memory.disasm via WebSocket, and explicitly guarantees no modification to memory or CPU state. Annotations already carry readOnly/destructive/idempotent hints, so this adds implementation-level context and a state-safety guarantee rather than merely repeating structured data. No contradiction with annotations.

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

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

Four labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) front-load the most important facts and keep every sentence purposeful. The description is compact, scannable, and free of filler or unnecessary repetition of the full schema.

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 description covers the call's purpose, parameter requirements, behavioral safety, and return shape in a few lines. Since an output schema is present and annotations already cover safety, nothing essential for correct invocation is missing; the only mild omission is explicit tool-alternative guidance.

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

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

Schema coverage is 100%, with all three parameters already described in the input schema. The description restates requiredness and defaults for address, count, and session_id, but it does not add new parameter semantics beyond what the schema already provides, so the high-coverage baseline applies.

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

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

The description opens with a specific action and resource: 'Disassemble N MIPS instructions at a given address.' It clearly states the operation, the target, and the count parameter, which distinguishes it from write-oriented siblings like ppsspp_assemble and search-oriented tools like ppsspp_search_disasm.

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 USAGE section gives practical parameter guidance: address is required, session_id is optional only when one session is active, and count has a default. It does not explicitly name alternatives or state when not to use this tool, but the purpose and parameter conditions make the intended call context clear, so it falls just short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'READ-ONLY'. It adds valuable behavioral context beyond annotations by disclosing that an empty capture raises CAPTURE_EMPTY and advising to advance to a relevant scene and retry. The RETURNS section also clarifies how output is delivered.

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 tightly organized into four labeled sections, each carrying distinct information: purpose, usage, behavior, and returns. Every sentence earns its place, and the most important facts are front-loaded. There is no fluff or redundancy beyond a harmless READ-ONLY restatement of the annotation.

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

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

For a single-parameter, read-only tool with an output schema and rich annotations, this description covers everything an agent needs: what it does, its key limitation, its error mode, and the shape of its result. No critical information is missing for selecting or invoking the tool correctly.

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

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

The input schema already documents session_id with 100% coverage, so the description need not repeat it. The description only mentions 'session_id' as a usage label and adds no deeper meaning about its format or constraints. This matches the baseline for high schema coverage.

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 action ('Dump'), a concrete resource ('currently-bound CLUT palette'), and the output form ('image plus metadata'). It further distinguishes the tool from address-targeted dumps by explicitly saying 'no VRAM-address targeting', making its scope unmistakable even among many siblings.

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

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

The USAGE section provides clear context: it takes a session_id and can only capture the currently-bound palette. It does not explicitly name alternative tools or state when-not-to-use it, but the restriction against VRAM-address targeting gives an agent actionable guidance about the tool's limits.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond these: it declares READ-ONLY, details an error condition (CAPTURE_EMPTY) and prescribes a retry action, and explains the return format (structuredContent metadata plus ImageContent block). This exceeds the baseline needed when annotations are present.

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 well-structured with bolded section labels (PURPOSE, USAGE, BEHAVIOR, RETURNS). Each sentence serves a distinct function—purpose, usage constraint, behavior/error, and output format—with zero filler or redundancy.

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

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

Given this is a simple tool with an output schema and annotations already covering safety and idempotency, the description provides all essential operational context: how to invoke it (session_id), what it captures (currently bound texture), what errors may occur and how to recover, and what output to expect. Nothing critical is missing 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 100%, so the schema already fully documents both parameters. The description repeats that session_id is required and clarifies texture selection behavior, but this is largely redundant with the schema's own parameter descriptions. It adds minimal semantic value beyond the schema.

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

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

The description clearly states a specific verb and resource: 'Dump the currently-bound GPU texture as an image plus metadata.' It distinguishes itself from siblings by explicitly noting it targets only the currently bound texture and not VRAM addresses, making it easy to differentiate from tools like ppsspp_screenshot or ppsspp_dump_clut.

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

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

The description provides clear context: it requires a session_id and only operates on the currently bound texture, explicitly excluding VRAM-address targeting. However, it does not name alternative tools or explicitly state when to use this tool over siblings, leaving some inferencing to the agent.

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, idempotentHint, and destructiveHint, so the description's 'READ-ONLY' label mostly repeats structured data. However, 'Pauses/resumes the CPU internally' adds a meaningful behavioral side effect beyond the annotations exceptional. This helps an agent understand why a seemingly safe read may still briefly affect execution 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?

The description is compact and well-organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS. Every line carries meaningful operational information without redundancy or fluff. The most important constraints are front-loaded.

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 two parameters, high schema coverage, and rich annotations, the description provides everything needed to invoke the tool correctly: purpose, required inputs, a behavioral side effect, an alternative for an unsupported use case, and the return shape. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the expression parameter already documents supported syntax, examples, and the no-dereference caveat. The description's 'session_id + expression' adds no new semantic value beyond the schema. There is no coverage gap for the description to compensate for, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Evaluate a debugger expression', and enumerates the accepted operand classes ('register names, hex literals, simple arithmetic'). It also separates itself from memory-reading tools by explicitly stating dereference syntax is not supported and pointing to read_u32 instead.

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 'USAGE' line indicates that session_id and expression are required. More importantly, the exclusion 'No '*addr' dereference syntax — read memory with read_u32 instead' gives an explicit when-not-to-use rule and names the alternative. It does not cover all possible alternatives among the many sibling tools, but the key routing edge case is handled.

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 description explicitly discloses that this is a state-changing operation, that the session lock is held for the whole call, that a paused CPU is resumed before returning, that an already-paused CPU stays paused, and that a failing capture never leaves the game frozen. These details go well beyond the sparse annotations and are exactly the behavioral context an agent needs.

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

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

The description is organized into short labeled sections — PURPOSE, USAGE, BEHAVIOR, RETURNS — and every sentence adds distinct information. There is no filler despite covering multiple facets of the tool's 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 state-changing, multi-step tool with an output schema, the description covers purpose, invocation parameters, lock and resume semantics, failure behavior, and the exact return shape including the nullable-key contract. Nothing an agent needs to safely call this 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?

The input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description reinforces defaults and semantics (optional probes, want_registers default true) but mostly mirrors the schema rather than adding new parameter-level meaning. The nullable-key contract is valuable but is return behavior, not parameter 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?

The description states a precise composite operation: pause (unless already paused), capture PC + registers + optional probes, then resume. This clearly distinguishes it from a manual pause/query/resume sequence and from sibling tools like get_pc or query. The verb and resource are specific and 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?

It gives explicit invocation guidance and directly recommends this tool over a manual pause + query(registers) + resume sequence, which is the natural alternative. It does not enumerate all sibling exclusions, but the usage context is clear enough for an agent to know when to choose this combined snapshot action.

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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description reveals that the CPU is paused temporarily for read consistency and then resumed, and that trust_level='high' is returned. This adds meaningful behavioral context that annotations alone do not provide.

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 well-organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Each line carries distinct information with no filler or redundancy.

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

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

For a one-parameter read-only getter with full schema coverage and an output schema, the description covers session resolution, CPU pause/resume behavior, and trust_level. Nothing needed to invoke 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?

Schema coverage is 100% and the schema already documents that session_id is optional and omitting it auto-resolves when exactly one session is active. The description's USAGE line essentially restates this, adding no new semantic meaning.

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

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

The description opens with a specific verb and resource: 'Safely read the current Program Counter.' This unambiguously identifies the operation and its target, and clearly distinguishes it from sibling tools like read_memory, disassemble, or write_register.

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 USAGE line only addresses the optional session_id parameter ('optional when exactly one session is active') rather than explaining when to prefer this tool over alternatives. Selection guidance is implied by the PURPOSE statement, but no explicit when/when-not or alternative routing is provided.

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

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

Beyond the readOnlyHint annotation, the description reveals the output destination (output/gpu_dumps/), the binary (non-JSON) format, and the MCP pre-probe error conversion. It explicitly says READ-ONLY, which is consistent with annotations, and adds meaningful behavioral context not visible in the schema.

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

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

The description is organized into four compact labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) and front-loads the key facts. Every sentence carries operational value with no filler.

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

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

For a single-parameter tool with a rich annotation set and an existing output schema, the description covers purpose, precondition, output behavior, and return shape. An agent has enough information to invoke it correctly and understand the result without looking up additional context.

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

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

Schema coverage is 100% and the session_id parameter is already documented as 'Active session ID.' The description only repeats 'session_id' in USAGE without adding extra syntax, validation, or format semantics, so the baseline of 3 applies.

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

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

The description uses a specific verb and resource: 'Capture the next rendered frame's GE command stream as a binary dump file.' This clearly identifies the tool's operation and distinguishes it from sibling GPU tools like ppsspp_gpu_stats or ppsspp_screenshot.

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

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

It states the only required input, session_id, and gives an explicit precondition: the CPU must be RUNNING, with a concrete explanation of why and the resulting CPU_STATE_ERROR. It does not name alternative sibling tools, but the when-to-use condition is unambiguous.

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

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

Discloses a behavioral trait not covered by annotations: the MCP pre-probe returns CPU_STATE_ERROR when paused instead of hanging, which also doubles as a probe. The READ-ONLY statement is consistent with annotations and adds no contradiction, while the error behavior is genuinely additional context.

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 well-structured with PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, each contributing value. Front-loaded with the purpose and behavior, it avoids filler while including a dense but useful note about the paused-CPU probe.

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

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

For a single-parameter, read-only, idempotent tool with an output schema, the description covers purpose, usage condition, error behavior, and return fields. Nothing an agent needs to invoke 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 schema already fully documents the only parameter, session_id ('Active session ID.'), with 100% coverage. The description merely restates 'session_id' in the USAGE section without adding new semantic meaning, so the baseline of 3 is appropriate.

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

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

Description states a specific verb ('Query GPU counters') and the exact metrics returned (fps, vblanks per second, timing info), leaving no ambiguity about the resource and action. It clearly differentiates from the sibling ppsspp_gpu_record by focusing on stats/query rather than recording.

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

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

Provides explicit usage conditions: 'The CPU must be RUNNING' and explains the paused-CPU behavior (CPU_STATE_ERROR instead of hanging), including a clever secondary use as a cheapest paused-CPU probe. However, it does not name alternatives, so it falls short of full when-to-use vs. when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's added value is explaining exactly what it reads ('in-memory server counters') and that it 'does not contact PPSSPP and does not modify any state.' This goes beyond the annotations and gives the agent a concrete picture of the tool's behavior.

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

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

The description is organized into clear labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) and every sentence carries key information. It is front-loaded with the purpose and usage, and contains no filler.

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

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

For a simple health-check tool with zero parameters and an output schema, the description fully covers purpose, usage, behavior, and return format. It even includes the possible status values and specific return fields. Nothing an agent needs to invoke 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 has zero parameters and schema coverage is 100% (trivially). The description explicitly states 'No parameters,' which is all that is needed. The baseline of 4 for zero parameters applies.

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

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

Description states a specific verb ('probe'), resource ('MCP server liveness and readiness'), and explicitly differentiates from siblings by saying 'without contacting PPSSPP' and 'Use this before any session-dependent tool'. An agent can clearly distinguish this health-check tool from the many PPSSPP interaction tools.

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

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

It gives an explicit when-to-use instruction: 'Use this before any session-dependent tool to verify the server is up.' It also implies not to use it for PPSSPP state checks via 'without contacting PPSSPP', but does not name specific alternative tools or provide a when-not-to-use list, so it falls short of the full 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?

The description explicitly identifies the operation as a STATE-CHANGE and reveals that the held state persists until a subsequent hold_buttons or send_analog call, which is meaningful behavior beyond the annotation hints. It does not contradict the annotations (readOnlyHint=false is consistent with setting state), though it could add more detail about release semantics.

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 uses labeled PURPOSE, USAGE, BEHAVIOR, and RETURNS sections that are easy to scan. Every line adds operational information, and there is no filler.

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

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

For a two-parameter tool with complete schema documentation and an output schema, the description covers purpose, usage, state persistence, and return shape. It is slightly less complete because the explicit method to release (empty combination / press_button) is left to the schema rather than stated in the description.

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

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

Schema description coverage is 100% and the schema already documents the button names, separator, and release behavior. The description essentially restates the format and required params without adding meaning beyond the schema, so it earns the baseline rather than a higher score.

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 action ('Hold') and resource ('combination of PSP buttons') and clarifies the distinguishing persistence behavior via 'until a subsequent call changes the state.' It does not explicitly name related sibling tools like ppsspp_press_button, so it is clear but lacks explicit sibling differentiation.

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

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

USAGE describes required parameters and the pipe-separated button format, and BEHAVIOR explains that the hold persists until another hold_buttons/send_analog call, giving clear context for when to use a hold rather than a momentary input. It does not explicitly say when-not-to-use or name alternatives, 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?

Beyond the readOnlyHint/idempotentHint annotations, the description discloses that integer values ≥0x1000 are returned as paste-ready hex strings and that unknown sections produce an error listing valid sections. This is useful non-obvious behavior that helps an agent predict tool output.

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, front-loaded with the purpose, and organized into clear PURPOSE/USAGE/BEHAVIOR/RETURNS sections. Every sentence carries distinct information without redundancy.

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

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

Given the single optional parameter, available output schema, and annotations covering read-only/idempotent behavior, the description fully covers what an agent needs: purpose, filter semantics, error behavior, return format, and result 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 schema already documents the optional section parameter with examples, and coverage is 100%. The description adds meaningful detail beyond the schema by clarifying that the returned hex values can be plugged directly into address parameters and that invalid sections yield a helpful error.

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

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

The description identifies a specific verb and resource: 'List the project's known address constants from addresses.yaml'. It also positions the tool as 'the single source of truth; never guess hex addresses', which clearly separates it from siblings like read_memory or convert_address.

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 explains the optional section filter and error behavior for unknown sections, giving clear operating context. It stops short of explicitly naming when-not-to-use or comparing against alternatives, so it earns a 4 rather than 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context by stating that the tool reads the in-memory manifest registry loaded at startup and does not execute any script. This goes beyond the structured annotations and clarifies the side-effect-free nature.

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, front-loaded with purpose, and uses clear labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS). Every sentence contributes useful information with no filler or redundancy.

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

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

For a low-complexity read-only listing tool with one optional parameter and an output schema, the description is complete. It covers what the tool does, the filter options, behavioral guarantees, and the return envelope. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, so the input schema fully documents the category parameter and its valid values. The description repeats this information and adds a return-shape hint, but it does not provide meaningful new semantics beyond what the schema already includes.

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 ('List') and a precise resource (diagnostic scripts declared in .ppsspp-dfx/config/scripts.manifest.yaml). It is clearly distinct from sibling tools like ppsspp_run_script and ppsspp_reload_scripts, and the 'Does not execute any script' note reinforces what this tool is for.

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 'USAGE' section explains the optional category filter and its valid values, but it does not explicitly say when to choose this tool over siblings or when not to use it. The intended use is implied rather than stated, and no alternatives are mentioned.

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 description declares READ-ONLY, which is consistent with the annotations, and adds value beyond them with 'Returns a single extent per matching tag'. This is useful behavioral context not captured by readOnlyHint or idempotentHint alone.

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 organized into four labeled sections, with the purpose front-loaded. Every sentence contributes either a selection cue, invocation detail, behavioral trait, or return shape; 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?

Given a full 100% parameter schema, a rich annotation set, and an output schema, the description covers the remaining needs: purpose, required/optional arguments, read-only behavior, and return structure. Nothing an agent needs to invoke 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?

Schema description coverage is 100%, so the input schema already documents all five parameters. The description restates the required/optional split but adds no new meaning beyond the schema, matching the baseline of 3 for high schema coverage.

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 ('Search') and a precise resource ('PPSSPP's memory-tracking metadata') and narrows it further to allocation/texture tags. This is distinct from sibling tools like read_memory, memory_map, and search_disasm, so an agent can tell them apart.

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 USAGE section states exactly which parameters are required (session_id + match) and which are optional filters (address/end/type). It provides clear context for calling the tool, though it does not explicitly name alternatives or when-not-to-use conditions.

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, idempotentHint, and destructiveHint=false, and the description's 'READ-ONLY' line is redundant. It does add useful return-shape context ('{ranges[], mapping, text}') and the region taxonomy, but no deeper behavioral details about pagination, errors, or session requirements.

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 labeled one-line sections deliver purpose, usage, behavior, and return shape with zero filler. The purpose is front-loaded and every sentence contributes meaningful information.

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

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

For a tool with a single documented parameter, strong annotations, and an output schema, the description covers the essential contract needed to call it correctly. Missing sibling guidance is a minor secondary concern, not a completeness 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 100%, and the session_id parameter is already documented as 'Active session ID.' The description merely repeats 'session_id' without adding semantic details such as format, validity, or how a session is obtained.

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: 'Get the PPSSPP memory region map (user / kernel / VRAM ranges)'. It clearly distinguishes from sibling memory tools such as read_memory or disassemble by focusing on memory region ranges rather than contents.

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 'USAGE: session_id' line only restates the parameter requirement and gives no contextual guidance. It does not mention when to choose this tool over related siblings like read_memory, memory_info_search, or convert_address, nor does it state 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?

The description explicitly states 'STATE-CHANGE' and that 'Button state returns to released after the duration elapses,' adding behavioral context beyond the annotations (readOnlyHint=false, etc.). It clarifies the non-idempotent nature and auto-release behavior, which is valuable.

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 tightly structured with PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Purpose is front-loaded, and each section is concise with no wasted words. It earns its place and is easy to scan.

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

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

The description covers purpose, usage, behavior, and return format. The output schema exists, so return values are also documented. The only gap is the conflicting default duration, but that's a schema/description mismatch rather than a missing aspect. Overall, it is complete enough 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 coverage is 100%, so the schema already documents parameters. However, the description incorrectly states 'default 10 frames' while the schema specifies 'default 1' – a factual contradiction that could mislead the agent. It also redundantly lists button names already in the schema, adding no new value.

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 a specific action: 'Simulate a single PSP button press for a duration.' This distinguishes it from siblings like hold_buttons (which holds multiple buttons) and send_analog (analog input). The purpose is unambiguous.

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

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

The USAGE section specifies required parameters (session_id, button) and optional duration, plus valid button names. It provides clear operational context but does not explicitly compare with alternatives like hold_buttons or send_analog. However, the purpose is specific enough that an agent can infer when to use it.

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

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

Goes well beyond the annotations: discloses that func_add/func_remove mutate the debugger function list despite the read-only framing, warns that running-state PC/isCurrent is low trust, and describes the return envelope {action, data, trust_level}. Annotations already cover the broad read-only/destructive safety profile, so this added context is meaningful.

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 labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) pack a lot of information into about 70 words with no filler. The purpose and usage are front-loaded, and every sentence adds operational information.

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

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

For a multi-action tool with 6 parameters and an output schema, the description covers purpose, invocation pattern, per-action requirements, prerequisites, and return shape. The per-action details are in the schema's enum descriptions, and the description fills the gaps around state requirements and payload size.

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

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

Schema coverage is 100% and the schema already documents every parameter, so the baseline is 3. The description adds cross-parameter dependencies ('register' needs name, func_scan/func_remove need address) and the top_n=0 size warning/hle.func.list 700+KB note, which are not inferable from individual property 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 states a specific high-level operation ('aggregate game-state queries') and enumerates all ten concrete actions it dispatches (game_state, registers, backtrace, threads, modules, func_*). This makes it clearly distinguishable from sibling tools like ppsspp_read_memory or ppsspp_get_pc without needing to inspect their schemas.

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

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

Provides concrete usage constraints: 'register' needs a name, func_scan/func_remove need an address, and the paused-CPU requirement for backtrace/threads/func_* with a 'pause first, or use get_pc' hint. It does not explicitly name alternative tools or state when-not-to-use, so it stops short of the highest bar.

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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses silent skipping of unreadable scan blocks, the IR_ENCODING_DETECTED sentinel for JIT-IR, ASCII-only string handling, and the exact return payload fields. No annotation contradiction exists.

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 PURPOSE/USAGE/BEHAVIOR/RETURNS structure front-loads the core capability and packs each sentence with operational detail; there is no filler and the caveats are placed where they are likely to be consulted.

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 13-parameter memory tool with rich annotations, the description covers invocation, limits, return shape, and edge cases; nothing needed to call it correctly appears 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?

With 100% schema coverage, the description still adds meaning: byte-size limits, split-large-read guidance, scan range and chunk-size trade-offs, max_len's 4096 cap and NUL-scan behavior, and output-mode selection guidance for near-cap reads.

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 ('Read memory') and enumerates the four concrete actions (read_bytes, read_u32, read_string, scan), clearly distinguishing the read/scan scope from write, assemble, and disassemble siblings.

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

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

Gives explicit operational constraints (size cap, split larger reads, scan region limits, chunk_size) and one direct routing cue: use disassemble instead of read_u32 on JIT-IR code. It does not broadly compare this tool to all read-related siblings, but the guidance provided is concrete and actionable.

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 indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds important behavioral details: MUTATING behavior, clears cache, and the exact notification semantics (tool-list-changed notification when exposed tool set changes). It also explains reversibility. This goes beyond annotations to clarify the side-effect profile and client notification, which is valuable.

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 well-structured with clear sections for PURPOSE, USAGE, BEHAVIOR, and RETURNS. It is dense but every sentence adds value: purpose, parameter count, behavior specifics, and return format. It is front-loaded with the main purpose and then explains nuances without redundancy.

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

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

Given the tool's simplicity (no parameters) and the presence of an output schema that defines the return shape, the description is complete. It provides the purpose, usage, behavior, and return summary. The annotations cover safety and idempotence. There is nothing an agent needs to know to call this tool correctly that 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 has 0 parameters, and the schema is empty. The description clearly states 'No parameters.' Since there are no parameters to disambiguate, the description fully handles parameter semantics. The schema provides no property documentation, but the description compensates by confirming the absence of parameters.

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

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

The description clearly states the tool's specific action: manually reload the script manifest YAML and clear the script module cache. The verb 'reload' and resource 'script manifest' and 'script module cache' are explicit. It is distinct from siblings like 'list_scripts' or 'run_script' which involve different actions.

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 indicates this is a manual reload action, implying it is used when the user manually changes the script manifest or wants to refresh without waiting for automatic updates. It does not explicitly contrast with alternatives, but the context is clear that this is for manual intervention. No when-not-to-use is stated, but the tool's niche is well understood.

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 are only generic flags (readOnlyHint false, etc.), so the description carries the burden and delivers richly. It discloses that this is a state-changing tool, that recording requires the CPU running, that executing/saving never clear on their own, that execute/load auto-abort live state, and that restore_rtc rewinds the game-visible wall clock and pollutes in-game timers. These are exactly the behavioral traps an agent needs to avoid.

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

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

The description is long but well-organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS, with critical warnings front-loaded in the BEHAVIOR section. Some redundancy with the schema exists, but for a tool with ten actions and many side-effect caveats, the density is justified and every section 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 complex multi-action stateful tool, this description covers the complete calling contract: required fields per action, file containment, boot-aligned replay sequence, return payload shape, and side-effect warnings. An output schema exists for return values, and the description still supplies the non-obvious execution model, making it fully adequate 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 100%, so the baseline is 3. The description restates which parameters each action requires, but the schema already documents those dependencies in detail. It adds little new parameter-level meaning beyond the schema, though its behavioral caveats around execute/load and wait_complete are valuable context.

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 ('Aggregate PPSSPP replay subsystem') and enumerates its core responsibilities: record input sequences, execute them, and save/load .ppr recordings. This clearly distinguishes it from the sibling input tools like ppsspp_press_button and ppsspp_hold_buttons, which are for live input rather than replay.

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

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

Provides explicit usage structure: action plus session_id, required parameters per action, and file-name containment rules. It also gives important when-not guidance, such as 'execute/load ONLY loads the event table... it does NOT play by itself' and warns that wait_complete always times out on an un-aborted replay. It stops short of explicitly naming sibling alternatives for routing, but the action-level guidance is strong.

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 description explicitly declares 'STATE-CHANGE', matching the annotations (readOnlyHint=false, idempotentHint=false). It adds behavioral context beyond annotations by naming error codes (SCRIPT_NOT_FOUND, SESSION_NOT_FOUND) and noting that skeleton scripts are non-functional. While it doesn't detail what state changes occur, the description covers the critical edge cases and the fact that it runs arbitrary registered code.

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 exceptionally well-structured with clear PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. It is concise, with every sentence providing necessary information and no filler. The front-loaded purpose statement immediately tells the agent what the tool does.

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 that runs scripts with three parameters, an output schema, and a rich set of sibling tools, the description is complete. It covers how to obtain valid names, handles the session_id requirement, describes error behavior, and specifies the return shape. The agent has everything needed to call it correctly without additional lookups.

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

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

Schema description coverage is 100%, so all three parameters (name, input, session_id) are already well-documented in the schema. The description adds marginal value by referencing ppsspp_list_scripts for name discovery and clarifying the session_id priority, but these are largely restatements of schema hints. The baseline of 3 is appropriate because the schema carries the load, and the description does not meaningfully enhance parameter meaning beyond that.

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

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

The description states a specific verb ('Invoke') and resource ('manifest-registered diagnostic script') with validated input, clearly distinguishing it from siblings like ppsspp_list_scripts (which lists scripts) and ppsspp_reload_scripts (which reloads). It even notes that skeleton scripts return not_implemented, further disambiguating expected 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?

The USAGE section explicitly tells the agent to get the script name from ppsspp_list_scripts, mentions that skeleton scripts return not_implemented, and clarifies the session_id requirement with the error SESSION_NOT_FOUND when missing. It also implies when not to use the tool (for skeleton scripts) without being verbose.

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?

Beyond the readOnly/idempotent/destructive annotations, it discloses the render-to-VRAM auto-fallback, unreliable colors on VRAM, crash risk of 'output', and the empty=true instead of error behavior. These are precisely the behavioral traits that affect invocation and interpretation of results.

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?

Organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS with each sentence carrying distinct information and no filler. The critical caveats are near the top and easy to scan.

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

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

With annotations covering safety and an output schema covering metadata, the description adds exactly what is needed: purpose, source selection rules, empty-capture semantics, and how the image is returned and where it is saved. No critical invocation detail is missing.

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

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

Schema coverage is 100%, so the schema already documents the parameters, but the description adds operationally important semantics: source default plus fallback behavior, the 'output' risk warning, mode deprecation and exclusivity, and the single-active-session condition for omitting 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, resource, and output: captures the framebuffer as an ImageContent plus metadata. The purpose is clear, but it does not explicitly distinguish itself from close siblings such as ppsspp_frame_snapshot or ppsspp_dump_texture.

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

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

Provides actionable usage conditions: session_id may be omitted when exactly one session is active, source='render' is the safe default, and source='output' is explicitly marked crash-risk and not to be used. It explains mutual exclusivity with the deprecated mode param, though it does not name alternative tools for when this tool should be avoided.

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 destructiveHint=false, and the description repeats 'READ-ONLY.' It also discloses loop/wrap behavior and match collection, but these details are already in the schema's parameter descriptions, so the description adds little new behavioral context beyond the annotations.

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

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

The description uses four labeled one-line sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) and front-loads the purpose. Every line earns its place, and there is no fluff or redundant elaboration.

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 the detailed input schema covering all parameters, the read-only/idempotent annotations, and an output schema present, the description gives enough operational context including defaults, wrap behavior, and return envelope. An agent has all needed information to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and every parameter already has thorough semantic explanation (e.g., end=0 wrap behavior, '$' stripping, max_results loop mechanism). The description's USAGE line merely summarizes these details without adding further meaning, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Loop-search disassembly for a substring, collecting matching instructions with context.' This makes the tool's function immediately clear and inherently differentiates it from siblings like ppsspp_disassemble (one-shot disassembly) and ppsspp_memory_info_search (searching memory values rather than disassembly text).

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

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

The USAGE section provides concrete invocation guidance: required session_id and match, leading '$' stripping, start address, end=0 wrap-around, and max_results default. It does not explicitly name alternatives or state when not to use this tool, but the context is clear enough to proceed.

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 BEHAVIOR section explicitly labels this as a STATE-CHANGE operation, states that the position persists until the next send_analog call, and notes that it is not idempotent in effect. This adds meaningful context beyond the annotations (which only say readOnlyHint=false, idempotentHint=false) by explaining the persistence semantics.

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 well-structured with clear PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Every sentence earns its place, and the most important information (what the tool does and required parameters) is front-loaded.

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 description covers purpose, usage, behavior, and return value. With an output schema present and full parameter schema coverage, nothing critical is missing. It could slightly improve by noting whether the analog position resets on session end, but this is a minor gap.

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

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

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds a concise summary of the coordinate system but does not add new information beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Send') and resource ('analog stick position'), and precisely defines the coordinate semantics (x, y in [0, 255], 128 = center). It clearly distinguishes this from sibling input tools like ppsspp_press_button and ppsspp_hold_buttons by focusing on analog state rather than discrete button presses.

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 USAGE section explicitly lists required parameters (session_id + x + y) and explains the value mapping (0 = full left/up, 255 = full right/down). It does not explicitly name alternative tools or when-not-to-use conditions, but the purpose is specific enough that an agent can infer when to use it versus siblings.

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

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

Beyond annotations, the description details state-change semantics: start spawns a subprocess and WS debugger, stop terminates it, wait_ready polls a probe and fails with [BOOT_TIMEOUT], and get is read-only. It also discloses the self-healing quarantine and relaunch behavior with the same session_id, adding substantial behavioral context that annotations alone do not provide.

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

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

The description is long but well-organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, and every sentence carries actionable detail. It is appropriately sized for a multi-action tool, though it could be trimmed slightly without losing meaning.

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

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

Given the tool's complexity (7 parameters, 4 actions, self-healing behavior), the description covers start, stop, get, and wait_ready flows, return shapes, failure modes, and ordering prerequisites. The output schema exists and the RETURNS section states what each response contains, so nothing an agent needs to call 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?

Input schema already covers all parameters at 100%, so the baseline is 3. The description adds value by tying parameters to behavior ('wait_ready=true to block until the CPU is up in the same call', resilient self-heals with up to 2 retries) and by giving operational warnings like 'never taskkill the process yourself'. This goes beyond simple parameter repetition, though the schema already does heavy lifting.

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

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

Description opens with 'PURPOSE: Start / stop / inspect PPSSPP debug sessions' and enumerates action values start/stop/get/wait_ready, giving a precise verb-resource mapping. It differentiates from the sibling ppsspp_session_list by focusing on lifecycle operations rather than listing 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?

Usage section explicitly states which action requires which parameter ('action='start' needs iso_path', 'stop/get/wait_ready need session_id'), and gives ordering guidance ('Call wait_ready AFTER start and BEFORE any memory tool'). It even warns against taskkilling and explains resilient mode's retry behavior, leaving no ambiguity about when or how to use the tool.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with 'READ-ONLY.' Crucially, it discloses a subtle side effect beyond what annotations can express: idle sessions (>30 min) are auto-GC'd, and it preemptively clarifies this 'does not mutate the caller's state.' The description also names the exact data source (in-memory session dict) and the return shape, adding meaningful context without contradicting the annotations.

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

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

The description is organized into labeled sections (PURPOSE, USAGE, BEHAVIOR, NOT, RETURNS) that make it highly scannable. Every sentence carries distinct information: scope, side effect, read-only behavior, sibling routing, the 'do I need this for an ID?' question, and return format. There is no redundancy or filler.

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

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

For a zero-parameter, read-only list tool with an output schema, the description is complete: purpose, side effects, alternatives, return shape, and even the most likely misuse (calling it just to resolve a session ID) are all covered. Nothing an agent needs to correctly select and invoke this 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?

With 0 parameters, the rubric baseline is 4, and the empty schema needs no compensation. The description explicitly states 'No parameters' and adds relevant selection context about session_id auto-resolution in sibling reader tools. It adds modest value beyond the schema but there is no parameter to elaborate on, so 4 is appropriate.

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

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

The PURPOSE section states a specific verb and resource: 'List all active PPSSPP sessions.' It goes further by explicitly distinguishing itself from siblings: 'NOT a per-session status probe,' naming ppsspp_smoke_test, ppsspp_get_pc, and ppsspp_query as the correct tools for those needs. An agent can select this tool without opening any schema.

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

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

The description gives explicit when-to-use and when-not-to-use guidance with named alternatives: use ppsspp_smoke_test for session health, ppsspp_get_pc/ppsspp_query for CPU/game state, and it warns that session_id-optional reader tools auto-resolve when one session is active, so 'you normally do NOT need to call this first just to obtain an ID.' Nothing is left to inference.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'READ-ONLY. Battery of probes.' It adds useful context about the operation's nature and describes the return shape, which goes beyond what annotations alone convey.

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 well-structured with clear PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Every sentence earns its place and the key purpose is front-loaded.

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

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

For a read-only health-check tool, the description covers what it does, how to invoke it, what it is not for, alternatives, and the return shape. The output schema also exists, so nothing an agent needs to call this 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?

Schema description coverage is 100%, and the schema already documents session_id and the optional checks subset with valid values. The description only restates session_id and adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb ('health check') and resource (session) and enumerates the four concrete checks. It explicitly distinguishes itself from an ISO boot-acceptance test and names the sibling tools to use instead, so an agent can tell it apart from related session/diagnostic tools.

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

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

Provides a clear usage context: pass a session_id for a four-point session health check. It explicitly says when NOT to use it ('NOT an ISO boot-acceptance test') and points to alternatives ('use session wait_ready + analyze_log for boot triage').

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?

Without relying on annotations, the description discloses side effects (register/clear mutate registry), process-wide sharing, seeding from addresses.yaml, and non-reseeding after clear. It also details idempotent clear semantics and contrasts with ppsspp_breakpoint mem_remove, going far beyond the sparse annotations.

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

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

Four labeled sections (PURPOSE, USAGE, BEHAVIOR, RETURNS) front-load the most important selection and invocation information. Each sentence earns its place with minimal redundancy.

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

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

The description captures the registry lifecycle, cross-session scope, idempotency exception, and return envelope shape; combined with the output schema this gives an agent everything needed to call the tool safely. The only minor gap is a lack of explicit sibling-selection guidance, but that does not undermine completeness 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 coverage is 100%, so the baseline is 3; the description adds only a condensed action-parameter summary and does not introduce semantics absent from the schema. The samples behavior and per-action parameter roles are already fully described in the input schema.

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

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

Opens with a PURPOSE line that names a specific mechanism (named memory-probe registry) and a distinct use case (register once, sample cheaply every loop). This differentiates it from sibling memory tools like ppsspp_read_memory and ppsspp_breakpoint.

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 USAGE section gives action-parameter mappings (register needs name+address, observe takes names+samples), which is clear operational context. It does not explicitly state when to prefer this tool over siblings or list exclusions, so it stops short of full differentiation.

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 description goes beyond the annotations by explicitly warning that 'reset' reboots the game and loses in-memory state, and that 'run_until' sets a temporary breakpoint and resumes execution. This is meaningful behavioral disclosure for a state-changing tool, though pause/resume side effects are not detailed.

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 tightly organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS, with no filler. The most important behavioral caveat is surfaced early, and each sentence 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?

Given the 3 parameters, full schema coverage, annotations, and an output schema, the description supplies everything needed to select and invoke the tool: purpose, invocation constraints, state-change behavior, and return shape. The only notable omission is explicit alternative routing, which is a usage-guidelines concern rather than a completeness 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 description coverage is 100%, so the schema already fully documents action, address, and session_id. The description usefully summarizes the action-to-parameter relationship but largely duplicates what the schema says, keeping it at the baseline for high coverage.

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 opens with a concrete purpose ('Aggregate CPU step + run-state control') and enumerates all supported actions, so an agent knows exactly what operations the tool covers. This precise operation set distinguishes it from sibling tools like batch_step, breakpoint, or press_button without needing to name 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?

It gives explicit action-dependent invocation rules: most actions require only session_id, run_until requires address, and session_id is optional when exactly one session is active. However, it does not mention when to prefer alternative tools such as batch_step or wait_breakpoint, so it stops short of full guidance.

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

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

The BEHAVIOR section is exemplary: it discloses that the tool MUTATES by arming a temporary breakpoint, guarantees the breakpoint is always removed even on error paths, explains the lock is only held for arm/capture/cleanup, and warns about the first-broadcast-wins race. This adds substantial behavioral context beyond the annotations, which are all false and provide no safety or mutation hints.

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

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

The description is organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, making it scannable for an agent. Although long, nearly every sentence carries non-obvious operational detail, and the most important purpose and usage constraints are front-loaded.

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 7 parameters and complex runtime behavior, the description covers inputs, preconditions, concurrency hazards, cleanup guarantees, and the full return shape. The RETURNS field enumerates the result object with nested hit fields, so nothing essential is missing even without viewing the output schema.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents defaults, ranges, and behavior for each parameter. The description mostly restates access types, size 1/2/4, timeout_s, and optional flags without adding new parameter-level meaning. It does add some context, like needing a running session, but this is more usage guidance than parameter 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?

The description opens with a specific purpose: 'One-call answer to what code reads/writes this address', and spells out the operational sequence (arm breakpoint, wait, capture pc, remove breakpoint, resume). This clearly differentiates it from sibling tools like ppsspp_breakpoint, ppsspp_step, and ppsspp_wait_breakpoint by framing it as a complete trace operation rather than a component.

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 USAGE section explicitly states required inputs, optional flags, and a critical precondition: 'Game must be RUNNING (call after session wait_ready).' It also gives a clear exclusion rule: 'Do NOT run other breakpoint/step tools during the wait: the first cpu.stepping broadcast wins.' This tells the agent exactly when and how to invoke the tool, and what to avoid.

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

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

Annotations declare readOnlyHint=true, and the description reinforces this with 'READ-ONLY' while adding substantial extra behavior: it subscribes to cpu.stepping, holds no session lock, warns against step/pause/resume during the wait, and explains the already-paused CPU edge case. This goes well beyond 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 description is organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, front-loading the core purpose and keeping each sentence dense and relevant. Every section earns its place and no content is redundant with the schema.

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 definition covers the prerequisite, the decision between this and trace_memory_access, the locking/concurrency warning, the paused-CPU edge case, timeout semantics, and return field nullability. This is complete for a blocking wait tool with no hidden caveats left for the agent to discover by trial and 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 description coverage is 100%, with both session_id and timeout_s already described in detail including the default and clamping. The description's mention of 'session_id; timeout_s default 30' adds no meaningful information beyond the schema, so the baseline of 3 is appropriate.

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

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

Purpose is precise: 'Block until a breakpoint hit (any kind)' names a specific verb, resource, and scope. It also differentiates itself from ppsspp_trace_memory_access and from polling gpu_stats, so an agent can distinguish it from closely related siblings.

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

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

Explicitly states when to use it ('only need to know a hit happened'), names the alternative for richer capture, and gives a prerequisite ('Arm a breakpoint first via ppsspp_breakpoint'). It also explains timeout semantics as pollable rather than an error, leaving no ambiguity about acceptable usage.

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 description explicitly says 'STATE-CHANGE' and that the emulator 'advances N frames,' while annotations declare idempotentHint=true. Repeatedly waiting N frames advances emulator state cumulatively, so this is an Annotation Contradiction.

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

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

The description is tightly structured with labeled PURPOSE, USAGE, BEHAVIOR, and RETURNS sections, front-loading the key purpose and call contract. Every sentence is informative and there is no filler.

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

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

For a simple three-parameter tool with an output schema, the description covers purpose, call requirements, behavioral effect, session validation, and return shape. It is nearly complete, but the unresolved idempotency contradiction could confuse an agent about repeated-call semantics.

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

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

Schema description coverage is 100%, so the schema already documents frames, interval, and session_id. The description restates required fields and the default 1/60 s interval but adds no substantial meaning beyond the schema, meeting only the baseline for fully documented parameters.

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

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

PURPOSE states a specific operation—'Wait N frames'—with timing semantics ('wall-clock sleep at 60 FPS by default') and the intended effect ('let the emulator advance'). This clearly identifies the tool's role and distinguishes it from sibling stepping or breakpoint-wait operations.

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 specifies the required arguments ('session_id + frames required; interval optional') and the default interval, which tells an agent how to invoke it. However, it does not explain when to prefer this tool over siblings like ppsspp_step, ppsspp_batch_step, or ppsspp_wait_breakpoint, nor does it state any exclusions or alternatives.

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 description explicitly labels the operation 'DESTRUCTIVE' and discloses that protected ranges (kernel, top.prx code) require force=true to avoid accidental crashes. This adds behavioral context beyond the annotations by describing the protected-range constraint and the consequence of not using force.

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 tightly organized into PURPOSE, USAGE, BEHAVIOR, and RETURNS sections. Every sentence carries meaningful information, with the destructive behavior and key constraint front-loaded.

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 description covers purpose, invocation requirements, behavioral risks, protected-range handling, and return shape. Combined with a rich schema and output schema, an agent has sufficient information to call the tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents data, format, address, force, and session_id in detail. The description's usage line mostly restates this information, adding little beyond the schema.

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

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

The description states a specific action and resource: 'Write u8/u16/u32 or raw bytes to memory.' It clearly distinguishes from sibling tools like ppsspp_write_register and ppsspp_read_memory by specifying the resource (memory) and accepted formats.

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 an invocation formula ('session_id + address + data + format'), but no guidance on when to choose this tool over alternatives such as ppsspp_write_register or ppsspp_assemble. The only conditional guidance ('protected ranges ... need force=true') is about a parameter, not about tool selection.

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 description explicitly discloses that the tool is DESTRUCTIVE, which aligns with the destructiveHint annotation. It also adds valuable behavioral context beyond the annotations: it pauses and resumes the CPU automatically, and handles REQUIRED_STEPPING internally. This is exactly the kind of behavioral detail an agent needs to know before invoking 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?

The description is compact and front-loaded: PURPOSE, USAGE, BEHAVIOR, RETURNS. Every section earns its place, and the most important information (destructive, auto-pause) is prominent. No filler or redundancy.

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

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

The description covers purpose, usage, behavior, and return value shape. The output schema exists, so return values are already documented. The only minor gap is that it doesn't explicitly state what happens on invalid register names or out-of-range values, but the schema already covers value wrapping. Overall, it's complete for a tool of this 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 100%, so the schema already documents all three parameters thoroughly. The description adds a bit of context (e.g., 'r5' normalizes to 'v1', value is hex) but mostly restates what the schema already says. Baseline 3 is appropriate because the schema does the heavy lifting.

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

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

The description states a specific verb ('Set') and resource ('CPU register'), and enumerates the exact register families (GPR/FPU/VFPU, plus pc/hi/lo). This clearly distinguishes it from sibling tools like ppsspp_write_memory, which writes to memory rather than registers.

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 explicit usage context: it requires session_id, name, and value, and notes that MIPS ABI names are required (with 'r5' normalizing to 'v1'). It also states that no manual pause is needed because stepping is handled internally. It doesn't explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to select it appropriately.

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