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

The description covers key behaviors: typing via keyboard, case insensitivity, and line endings. However, it does not disclose the effect of the session parameter, prerequisites (e.g., PET must be running), or potential side effects like overwriting existing program text.

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 highly concise with two sentences, each serving a distinct purpose: first describes the main action, second adds the optional run behavior. No superfluous words.

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

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

Given the tool has three parameters and no output schema, the description covers the primary action but omits the session parameter and any prerequisites for use (e.g., PET session must be active). This leaves gaps in fully understanding the tool's 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?

The description explains two of three parameters (text and run) beyond the schema, noting text as BASIC program lines and run as typing RUN. The session parameter is not mentioned at all, leaving its meaning unclear.

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 types BASIC program text into the PET via keyboard, with explicit details on case insensitivity and line endings. It distinguishes from sibling tools like pet_run (which presumably runs a program) by focusing on inputting text programmatically.

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 does not provide explicit guidance on when to use this tool versus alternatives such as pet_load or pet_run. It only hints that setting run=true will type RUN afterwards, but no comparisons or when-not conditions are given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the machine keeps running (non-blocking), which is a key behavior. It does not detail side effects, but for a simple breakpoint add, the description is sufficiently transparent.

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

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

The description is extremely concise at two sentences with no fluff. It front-loads the core purpose and immediately follows with the crucial behavioral note and alternative tool reference.

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

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

Given 4 parameters, no output schema, and no annotations, the description is incomplete. It does not cover the return value or explain the optional parameters (session, condition, temporary), which are important for effective use of the tool.

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

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

The input schema has 4 parameters with 0% description coverage, yet the tool description only hints at the 'ref' parameter ('at an address or symbol'). It provides no explanation for 'session', 'condition', or 'temporary', leaving the agent without semantic guidance beyond parameter names.

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

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

The description clearly states 'Set a breakpoint at an address or symbol', providing a specific verb and resource. It further distinguishes itself from the sibling tool 'pet_wait_break' by noting that the machine keeps running, so the user knows this tool only sets the breakpoint without blocking.

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 tells the user to use 'pet_wait_break' to block until the breakpoint fires, giving clear guidance on when to use this tool versus an alternative. It implies that for non-blocking breakpoint addition, this is the correct choice.

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

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

With no annotations, the description discloses that breakpoints persist across runs and that clearing all removes stale ones. It also states watchpoints are unaffected, providing good 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?

Two sentences with zero waste. Every sentence adds essential information: what it does, what it doesn't affect, and why you'd use it.

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

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

The description is mostly complete for the tool's core function but misses explaining the session parameter. Without output schema, the return behavior is also unknown. Adequate but with a clear gap.

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

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

The single parameter 'session' is not described in the schema (0% coverage) and the tool description does not explain what it does or its significance. The agent has no guidance on when or how to set it.

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

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

The description clearly states 'Remove ALL breakpoints (exec checkpoints)' and distinguishes from sibling tools like pet_break_remove and pet_watch_clear, which target single breakpoints or watchpoints.

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 that watchpoints are kept, implying use pet_watch_clear for those, and notes checkpoint persistence to guide cleanup. However, it does not explicitly say when not to use this 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?

No annotations provided, so description must carry behavioral info. States output includes hit counts, but lacks details on side effects, session boundaries, or behavior with no session specified.

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?

Extremely concise with no superfluous words. However, the brevity omits essential information about the session parameter, making it slightly less effective despite efficient phrasing.

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 list tool with one undocumented parameter and no output schema, the description fails to provide enough context for correct invocation. The session parameter is critical but unmentioned.

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

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

Schema coverage is 0% and description does not explain the sole parameter 'session'. The agent has no information on its purpose, allowed values, or default behavior.

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

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

Description uses specific verb 'List' and identifies exact resources 'breakpoints/watchpoints' with a notable detail ('with hit counts'). Clearly distinguishes from sibling tools like pet_break_add (add) or pet_break_remove (remove).

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

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

No guidance on when to use this tool vs alternatives. Does not mention prerequisites, session scope, or comparison with watchpoint listing tools like pet_watch_add.

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

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

No annotations are provided, so the description carries full burden. It implies mutation ('Remove') but lacks disclosure of side effects, permissions, or error behavior (e.g., what happens if checkpoint_id is invalid). The term 'breakpoint/watchpoint' introduces ambiguity.

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

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

The description is a single sentence with no wasted words, but it is overly brief and lacks structured information. It meets a minimum standard for conciseness but sacrifices completeness.

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 (2 params, no output schema), the description is insufficient. It does not clarify what 'checkpoint_id' refers to or how session affects behavior, leaving gaps 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 has 2 parameters with 0% description coverage. The description does not explain the purpose of 'session' or the meaning of 'checkpoint_id', leaving the agent without essential syntactic or semantic guidance.

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 explicitly states the verb 'Remove' and the resource 'breakpoint/watchpoint by id'. It clearly distinguishes from sibling tools like pet_break_add (add) and pet_break_clear (clear all).

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 no guidance on when to use this tool versus alternatives (e.g., when to use remove vs. clear) or any prerequisites or context for invocation.

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

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

With no annotations, the description must disclose behavioral traits. It mentions output files (.prg, label file) but omits potential side effects (e.g., overwriting files), authorization needs, or output format details. Minimal transparency beyond the basic action.

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

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

The description is a single, well-structured sentence that efficiently conveys the core purpose. However, it sacrifices detail for brevity, omitting parameter explanations and usage context.

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 2-parameter schema, no annotations, and no output schema, the description lacks essential context: source input format, model semantics, output file locations, and preconditions. Incomplete for a reliable tool 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?

The description adds no information about parameters. The schema has 0% coverage, and 'model' (default pet4032) and 'source' are unexplained. Agents must infer meanings from names alone, which is insufficient for correct invocation.

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 action: assembling 6502 source (ca65 syntax) to .prg and VICE label files. It specifies the input source language and output file types, which distinguishes it from all sibling tools that focus on debugging, running, or other 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?

The description implies the tool is used when assembly of ca65 source is needed, which is unique among siblings, but it does not provide explicit guidance on when to use or avoid it, nor prerequisites or context (e.g., need for an active session or source file location).

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

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: fake return address on stack, optional register setup, and machine states (STOPPED on success, RUNNING on timeout). This is more transparent than many tool descriptions.

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

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

The description is two sentences and front-loads the core action and purpose. Every word is useful, with no redundancy. The structure is efficient for quick parsing.

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 6 parameters and no output schema, the description covers the main intent and mechanism but omits details about the 'routine' parameter format, 'session' usage, and potential return values. The outcome states are helpful, but additional context would improve completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'optional A/X/Y on entry' and 'routine', but does not detail the 'session' parameter or the expected format for 'routine' (e.g., address or label). The timeout default is mentioned in the schema but not in the description. This adds limited value beyond parameter names.

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

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

The description clearly states it performs a JSR to a routine and stops at RTS, describing it as a unit-test primitive. This distinguishes it from generic run/continue tools, though it could explicitly name sibling tools for 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?

It outlines a usage pattern ('poke inputs, call, then assert registers/memory') and describes success/timeout outcomes. However, it does not explicitly state when to use this tool versus alternatives like pet_step or pet_run, leaving implicit 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?

With no annotations, the description must fully disclose behavior, but it only states the purpose without describing what happens on resume, edge cases (e.g., no breakpoint set), or side effects. This is insufficient for safe invocation.

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

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

The description is a single concise sentence that gets straight to the point with no wasted words.

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

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

Given no output schema, no annotations, and a single parameter, the description lacks details on return values, side effects, or prerequisites, making it incomplete for an agent to fully understand the tool's behavior.

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

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

Schema description coverage is 0%, yet the description adds no explanation for the 'session' parameter. The description does not help an agent understand the parameter's role or how to use it.

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

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

The description 'Resume execution after a breakpoint/step' clearly states the action (resume execution) and the context (after a breakpoint/step), distinguishing it from siblings like pet_step (single step) and pet_run (start execution).

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

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

The description implies usage after a breakpoint or step, which provides context but does not explicitly state when not to use it or name alternatives. However, the contrast with sibling tools 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?

No annotations are provided, so the description carries full burden. It fails to disclose critical behavior such as whether the session is reset, what happens to previous state, or if the tool waits for the program to finish.

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

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

The description is a single, concise sentence that conveys the core action without extraneous words.

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

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

The tool is a boot operation, but the description lacks information about return values, error conditions, side effects, or what happens after loading/running. More context is needed for effective use.

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 description only implicitly explains the 'image' parameter as 'disk image', leaving the 'session' parameter completely undocumented. With 0% schema description coverage, this is insufficient.

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: attach a disk image and LOAD+RUN its first file. It is specific and distinct from siblings like pet_load, pet_run, and disk manipulation 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 implies usage for booting from a disk but does not explicitly state when to use this tool versus alternatives like pet_load or pet_run, nor does it mention prerequisites or exclusions.

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

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

With no annotations, the description carries full burden. It only states the basic action without disclosing behavioral traits such as whether it overwrites existing files, required permissions, or disk size limits. This is insufficient for a creation 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 a single concise sentence that is front-loaded. However, it sacrifices informational value for brevity; a slightly longer description could convey more without being verbose.

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 no annotations, no output schema, and low parameter documentation, the description is incomplete. It does not cover return value, file creation location, or error conditions, leaving gaps for an agent to use 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 0%, and the description fails to explain the parameters. It does not clarify that 'image' likely means filename/path, or what 'label' and 'disk_id' represent. The description adds no value beyond the schema's parameter names and defaults.

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 action 'Create' and the resource 'blank d64/d80/d82 disk image', specifying the disk image types. This distinguishes it from sibling tools like pet_disk_get, pet_disk_ls, and pet_disk_boot, which have different purposes.

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 no context on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. An agent would not know if this tool is suitable for overwriting an existing file or creating a new disk for a specific purpose.

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 lacks detail on side effects, permissions, or error conditions. Without annotations, the description should disclose behavioral traits such as whether the operation is read-only (likely safe) or if it modifies the disk image (unlikely). No such details are provided.

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 very concise, consisting of a single sentence. It is front-loaded and not verbose, but it sacrifices helpfulness for brevity. It earns its place but does not add value beyond the bare minimum.

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 lack of annotations, output schema, and parameter descriptions, the description is severely incomplete. It fails to clarify the data types, error handling, or any prerequisites, leaving the agent with insufficient information to use the tool reliably.

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 description does not explain the parameters beyond their names in the schema. With 0% schema description coverage, the agent must guess that 'image' refers to the disk image path, 'name' is the file on the image, and 'dest' is the host destination. No additional meaning is added.

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 action: 'Copy a file off a disk image to the host.' It uses a specific verb and resource, and differentiates from sibling tools like pet_disk_put (which copies onto the image). However, it could be more explicit about the direction (from emulated disk to host filesystem).

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

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

No guidance is given on when to use this tool versus alternatives. The context implies it's for extracting files, but there is no mention of when not to use it or what prerequisites exist (e.g., disk image must be mounted).

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

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

No annotations are present, so the description must disclose behavior. It does not mention side effects, output format, or error conditions. Only the basic action is stated.

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?

Extremely concise with no wasted words. However, it sacrifices necessary detail for brevity, making it under-specified.

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 no output schema and low schema coverage, the description should explain what the output contains. It does not, and also omits usage context like required state of the disk image.

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

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

Schema coverage is 0%, and the description only implies that 'image' refers to a disk image. It does not clarify format, path, or required values, leaving ambiguity.

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 lists the directory of a disk image, using a specific verb and resource. It distinguishes from siblings like pet_disk_get and pet_disk_put, which handle file 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?

No guidance on when to use this tool versus alternatives or prerequisites. For example, does the disk need to be mounted? No exclusions or context 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?

With no annotations, the description carries full burden but fails to disclose behaviors like overwrite policy, disk space handling, or requiremount status. The minimal description lacks essential 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?

The description is a single, concise sentence that communicates the core action efficiently. However, it lacks structured breakdown for parameters or usage nuances.

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 three parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, error conditions, or edge cases, leaving significant gaps for the agent.

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

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

Schema description coverage is 0% and the description adds no meaning to the parameters. Parameter names are self-explanatory but details like 'name' usage are not clarified.

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 action ('Copy'), source ('host file'), and target ('onto a disk image'), effectively distinguishing it from siblings like pet_disk_get or pet_disk_ls.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or scenarios. It only states the basic function.

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

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

With no annotations, the description carries full burden. It discloses the stopping condition (subroutine return) but omits other behavioral traits like side effects, permissions, or error states.

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

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

Two short sentences with no redundant words. Efficiently communicates the core action and state.

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 niche domain (subroutine execution in an emulator), the description is too sparse. No output schema or parameter explanations, leaving agents with insufficient context 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?

The description does not mention the 'session' parameter at all. With 0% schema description coverage, the agent receives no help on how or why to use the parameter.

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 runs until the current subroutine returns and that the machine stops. However, it does not differentiate from sibling tools like pet_run or pet_until, which may have similar behaviors.

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

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

No explicit guidance on when to use this tool vs alternatives like pet_step or pet_continue. The description implies usage for subroutine completion but does not provide context or exclusions.

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

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

With no annotations, the description carries full burden. It discloses critical behaviors: machine ends STOPPED, uses $97 poke, and is model-specific. It could mention more side effects but is fairly transparent.

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 concise (two sentences) and front-loaded with the core purpose. However, the technical jargon makes it dense and less readable for an AI agent.

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 complexity of emulator-specific tools and no output schema, the description covers key behaviors (ends STOPPED, model dependency). Lacks detail on the 'frames' parameter and return value, but is adequate for a low-level tool.

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

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

Schema description coverage is 0%, so description must add meaning. It explains 'key' (one character or space) and 'at' (frame anchor). 'frames' is implied by 'N game ticks', but 'session' and 'timeout' are not described. Only 2 of 5 parameters get clarification.

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 holds a key down for a number of game ticks, detailing the mechanism (re-poking $97) and the frame anchor. It distinguishes from siblings like pet_key_type by specifying 'hold' versus type.

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 context for usage (holding a key for precise timing) and includes a constraint (BASIC 4 models only). It does not explicitly say when not to use or list alternatives, but the purpose is clear enough to guide 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?

No annotations provided, so description bears full burden. It discloses that keys are buffered and never touch live key-down state, and clarifies the purpose of pet_key_hold. This is sufficient for a typing tool, though more details on behavior (e.g., buffer limits) could improve transparency.

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

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

Two sentences, no fluff, front-loaded with action and key details. Every sentence adds value.

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 2 params and no output schema or annotations, the description covers the main behavior but lacks details on session parameter, return value, buffer size limits, or side effects. Adequate but with clear gaps.

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

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

Schema coverage is 0% (no descriptions in schema). The description only adds meaning for the 'text' parameter (type string, for RETURN) but does not explain the 'session' parameter at all. Since coverage is low, description should compensate more for both 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 types text into the PET's keyboard buffer, specifies the special character for RETURN, and distinguishes from pet_key_hold by noting buffered keys don't affect live key-down state. This effectively differentiates it from 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 description implicitly contrasts with pet_key_hold for games reading $97, suggesting when to use each. However, it does not explicitly mention when to use pet_basic_type, another sibling, but the differentiation is still clear for the key-related tools.

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

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

With no annotations, the description carries full burden. It discloses loading behavior, optional RUN execution, and symbol registration for debugging. However, it omits side effects (e.g., program state overwrite) and does not clarify the 'autostart' mechanism for unfamiliar users.

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

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

The description is a single, front-loaded sentence that efficiently conveys the main action. However, it could be slightly more structured (e.g., separate clauses for clarity) without losing conciseness.

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

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

No output schema exists, and the description does not explain the output or state after loading (e.g., 'program loaded and ready' or 'execution started if run'). It also lacks prerequisites like needing an active session, which is suggested by the session parameter.

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

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

Schema coverage is 0%, so description must compensate. It explains prg (implied), run (with 'optionally without RUN'), and symbols (VICE label file), but entirely misses the 'session' parameter. The parameter types are not elaborated 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 the verb 'Load' and the resource '.prg' via autostart, and it distinguishes itself from siblings like pet_run (which runs) and pet_build (which builds) by specifying loading via autostart with optional steps.

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 does not explicitly state when to use this tool versus alternatives like pet_run, pet_build, or pet_disk_boot. It implies loading via autostart but offers no guidance on prerequisites or when not 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?

Discloses 'does not disturb run/stop state' and truncated flag, but no other behavioral details like auth or 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?

Two clear, front-loaded sentences with no extraneous text; could benefit from slight structure but efficient.

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?

Missing details on many parameters, no output schema or annotation support; leaves agent underinformed 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?

Explains 'values' format but not limit, start, length, or session; schema coverage is 0%, description adds only partial parameter info.

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?

Describes search memory for byte pattern, returns match addresses, clearly differentiates from memory read/write 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?

Implies usage for pattern finding but lacks explicit when-to-use or alternatives among 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?

No annotations provided, so description must cover behavior. It describes address formats and return structure but omits side effects, security, or potential errors. Adequate but not fully transparent.

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

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

Two sentences, front-loaded with purpose, then concise details. No extraneous content.

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

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

Covers addr and return format but lacks explanation of optional parameters (length, session) and potential errors. Minimal for a tool with no output schema and no annotations.

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

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

Schema description coverage is 0%. Description details addr format but provides no information about length or session parameters. Partially compensates for one parameter.

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?

Clearly states 'Read emulated memory', indicating a specific verb+resource. Distinguishes from siblings like pet_mem_write and pet_mem_find.

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 accepted formats for addr but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not guidance.

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

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

No annotations are present, so the description must disclose behavioral traits. It only mentions address format, but fails to describe side effects (e.g., overwriting, permissions required, error handling for invalid addresses).

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 consists of two efficient sentences, each serving a clear purpose: stating the tool action and clarifying the input format. There is no redundant 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?

Given the tool's complexity (write operation, 3 parameters, no annotations, no output schema), the description is too sparse. It lacks details on return values, error conditions, session behavior, and byte value constraints, leaving significant gaps for an AI agent.

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

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

With 0% schema coverage, the description adds value by explaining the address format ('$hex/0xhex/decimal/symbol'), but it does not clarify the 'values' parameter (expected range, byte count) or the optional 'session' parameter.

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 verb 'Write' and the resource 'emulated memory', making the tool's action unambiguous. This distinguishes it from siblings like pet_mem_read (read) and pet_mem_find (find).

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

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

No guidance is provided on when to use this tool versus alternatives, such as pet_mem_read or pet_mem_find. The description does not exclude any contexts or mention prerequisites.

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

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

With no annotations, the description carries the burden. It discloses the output format based on extension and the return of a run command. However, it does not mention side effects, required session, or authorization needs, which are important for a packaging 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?

Two concise, action-oriented sentences with no filler. The first sentence states the core function, and the second adds a key behavioral detail (return of run command). Efficient and well-structured.

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 and lack of output schema/annotations, the description is moderately complete. It covers the core functionality and output format, but omits parameter details and prerequisites (e.g., whether a PET session is needed). Adequate but not comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the source and output parameters implicitly (source is the input file, output determines disk vs prg), but model and title are not explained at all. This leaves significant gaps in understanding.

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 packages .s/.bas/.prg files into a .prg or disk image that any VICE user can run, with specific details on autostart behavior. This distinguishes it from sibling tools like pet_build or pet_run by focusing on creating distributable artifacts.

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

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

The description implies usage for distribution ('any VICE user can run') but does not explicitly state when to use this tool versus alternatives like pet_build. No exclusions or when-not-to-use guidance 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?

With no annotations, the description carries full burden. It discloses that PC is annotated with the nearest symbol if a label file is loaded, but does not mention other registers, side effects, or whether the tool is read-only. Adequate but minimal.

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 concise with two well-structured sentences. The first states purpose, the second adds a specific detail. No wasted words, though it could benefit from a more structured explanation including parameter and output info.

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 (one optional param, no output schema), the description covers core behavior but omits expected return format and any explanation of the session parameter. Complete enough for basic use but not fully informative.

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 has one parameter 'session' with no description (0% coverage). The description does not explain 'session' at all, leaving the agent without guidance on its meaning or usage. The tool name and description add no 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 'Read CPU registers', which is a specific verb and resource. It distinguishes from siblings like pet_reg_set (write) and pet_mem_read (memory). The added detail about PC annotation further specifies 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 description implies usage for reading CPU registers, but does not explicitly state when to use or not use this tool, nor does it mention alternatives like pet_reg_set for writing. No guidance on context or prerequisites.

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

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

With no annotations, the description must disclose behavioral traits. It mentions value format but omits side effects, prerequisites (e.g., active session), error conditions, or whether changes affect execution.

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 very short (one sentence) and front-loaded with purpose. However, it is too brief and could include more structured information without being verbose.

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 (mutation, 3 params, no output schema), the description is incomplete. An agent lacks info on session usage, valid register names, and success/failure indicators.

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

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

Schema description coverage is 0%, so the description must compensate. Only 'value' format is explained; 'name' (valid registers, case sensitivity) and 'session' (purpose, optionality) are not described.

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 verb 'Set' and resource 'CPU register' with examples like PC, A, X, Y. It distinguishes this tool from siblings such as pet_reg_get.

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

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

No explicit guidance on when to use this tool versus alternatives like pet_reg_get or pet_mem_write. The description implies usage for setting registers but offers no exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only disassembly operation but does not disclose whether it modifies state, requires an active session, or what the output format is. Key behavioral aspects like side effects and constraints are missing.

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

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

The description is extremely concise: two sentences that clearly convey the tool's purpose and a critical parameter detail. Every sentence adds value with 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?

Given the tool has three parameters, no output schema, and no annotations, the description is too sparse. It omits explanations for two parameters and provides no information about return values or behavioral context. A more complete description is needed for effective use.

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

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

With 0% schema description coverage, the description must explain parameters beyond the schema. It only describes the 'start' parameter format, leaving 'length' (default 32) and 'session' (nullable string) unexplained. This is insufficient for a three-parameter tool.

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

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

The description clearly states the verb 'disassemble' and the resource 'live memory with ROM + session symbol annotations'. It distinguishes the tool from siblings like pet_mem_read (raw memory read) and pet_build (build) by specifying the annotation context.

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 guidance on the start parameter format (hex, decimal, or symbol), which is helpful for usage. However, it does not explicitly state when to use this tool over siblings like pet_mem_read or pet_mem_find, nor does it mention prerequisites or exclusion criteria.

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 annotations, the description should disclose behavioral traits, but it only states the basic function. It does not mention whether the tool is read-only, requires authentication, or has side effects. The optional 'session' parameter is not explained.

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

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

The description is a single, clear sentence with no unnecessary words. It is front-loaded with the verb and resource. However, it could afford to be slightly more detailed without becoming verbose.

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 lack of output schema and the one optional parameter, the description is insufficient. It does not explain the return format, how the optional session affects behavior, or how it differs from other ROM-related tools. The agent has limited guidance 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?

The description adds no meaning to the 'session' parameter, which has a schema description coverage of 0%. The agent is left to infer the parameter's purpose from context alone.

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 identifies the loaded ROM set including names and content hashes. It uses a specific verb and resource, and implicitly distinguishes from siblings like pet_rom_disasm and pet_load.

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 no guidance on when to use this tool versus alternatives among the many sibling tools. There is no mention of prerequisites, context, or exclusions.

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

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

With no annotations, the description carries full burden and discloses key behaviors: conditional build/tokenization, loading, running, and symbol registration. It lacks details about potential side effects (e.g., screen output, memory overwrites) but covers the primary actions adequately.

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

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

The description is a single sentence with 22 words, efficiently conveying the purpose and behavior. It is front-loaded with the main action and contains no filler or redundant 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?

Given no output schema, no annotations, and two undocumented parameters, the description lacks completeness. It does not explain return values, failure modes, or what happens after the run. A more detailed description is needed for such a complex operation.

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

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

Schema description coverage is 0%, yet the description does not explain the 'source' or 'session' parameters. The description only hints at input file types via extensions in the purpose, but fails to define parameter roles or constraints.

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 specifies the verb (build/tokenize, load, run) and the resource (PET program files). It explicitly mentions the file types (.bas/.s/.prg) and the automatic registration of assembly symbols, distinguishing it from siblings like pet_build and pet_load.

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

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

The description implies that this tool is used to run a program after building/tokenizing if necessary, but it does not explicitly state when to prefer this over alternatives like pet_build, pet_load, or pet_continue. No when-not or exclusions are 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?

No annotations are provided, so the description carries the full burden. It states the tool is read-only ('Read'), which is safe, but does not disclose any other behavioral traits such as return format, side effects, or authentication requirements. For a simple read tool, this is minimally adequate.

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

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

The description is a single, front-loaded sentence of 15 words. It contains no filler and every word contributes meaning, making it highly efficient.

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 read tool with one optional parameter and no output schema, the description covers the essential purpose and differentiator. However, the lack of parameter documentation and return value information leaves minor gaps for an agent to fully understand usage.

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 has one optional parameter ('session') with 0% description coverage. The description does not mention this parameter at all, failing to explain its purpose or usage. The description adds no value beyond the schema itself.

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 verb ('Read'), the resource ('raw screen-code matrix'), and the intent ('checking glyphs without decoding ambiguity'). It effectively distinguishes from sibling tool pet_screen_text which likely returns decoded 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 phrase 'without decoding ambiguity' strongly implies usage when exact raw codes are needed rather than decoded text, providing clear context. However, it does not explicitly name alternatives or state when not 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?

No annotations are present, so the description carries full responsibility. It explains the scale parameter's behavior (nearest-neighbour upscale) and gives a usage tip. However, it does not mention where the screenshot is saved or any side effects, but the core behavior is disclosed.

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 three sentences long, with the purpose front-loaded. Every sentence adds value: purpose, when to use, and parameter guidance. No wasted words.

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

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

Given the tool's low complexity (3 parameters, no output schema), the description covers the essential purpose and usage context. However, it omits explanation of the 'path' and 'session' parameters. Still, it is largely complete for typical use cases.

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

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

Schema description coverage is 0%, so the description must add meaning. It explains the 'scale' parameter and its recommended values, but does not describe the required 'path' parameter or the optional 'session' parameter. This partial coverage adds some value but leaves gaps.

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 saves a PNG screenshot, specifying the resource (PNG screenshot) and the verb (save). It also distinguishes from the sibling tool pet_screen_text by noting when to use each, making purpose very clear.

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

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

Explicit guidance is provided: 'Prefer pet_screen_text for reading output; use this only when pixel-level appearance matters.' This tells the agent when to use this tool versus the alternative, fulfilling the usage guidelines dimension effectively.

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

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

With no annotations, the description discloses that graphics decode to Unicode by default and style='ascii' restores legacy mapping. It does not mention session or ansi_reverse behaviors, but the core read operation is well described.

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

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

Three sentences, front-loaded with purpose, no redundant words. Every sentence adds value: purpose, recommendation, and parameter detail.

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

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

For a read tool with 3 parameters and no output schema, the description covers the tool's main function and the key parameter but omits the other two parameters and the return format (plain text). It is adequate but not fully complete.

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

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

Schema coverage is 0%, so description must compensate. Only the 'style' parameter is briefly explained (Unicode default vs. ASCII legacy). The 'session' and 'ansi_reverse' parameters are completely undocumented, leaving the agent without guidance on their purpose or usage.

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?

Clearly states the tool reads the PET screen as plain text, explicitly distinguishes from screenshots as the preferred and faster method, and mentions the stylistic choice between Unicode and ASCII.

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 frames this as the preferred way to see program output, faster and more reliable than screenshots, guiding agents to use it over pet_screenshot. Does not cover when not to use it or alternative scenarios beyond screenshots.

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

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

No annotations are provided, so the description must carry the behavioral disclosure. It states the tool is idempotent and reports which action occurred via a 'started' field, which is helpful. However, it omits other behavioral details such as error conditions, required permissions, or the exact effect when booting (e.g., headless/warp specifics).

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

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

The description is extremely concise, consisting of two short sentences. The first sentence immediately conveys the core action, and the second adds idempotency and output hint. Every word serves a purpose with no 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 (2 optional params, no output schema), the description provides the essential purpose and behavioral note (idempotency). However, it lacks parameter semantics and does not fully explain the return value beyond 'started'. For a tool with many siblings, more contextual differentiation would be beneficial.

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

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

Schema description coverage is 0%, and the description does not mention or explain the two parameters (name, model). It refers to 'headless, warp' modes, which are not clearly linked to any parameter. The description adds no value beyond what the schema provides, failing to compensate for the lack of schema descriptions.

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

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

The description clearly states the verb ('attach' or 'boot'), the resource ('PET session'), and the specific scenario (running or non-existent). It also hints at idempotency and differentiates from siblings like pet_session_start by offering a combined attach-or-boot action.

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

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

The description implicitly defines when to use the tool: when you need a session running, either by attaching to an existing one or booting a new one. It does not explicitly list exclusions or contrast with alternatives like pet_session_start, but the context is clear enough for an agent to infer 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?

No annotations are provided, so the description carries the full burden. It indicates a read-only operation ('list'), but does not disclose prerequisites, potential emptiness, or connection requirements. For a simple list, this is acceptable but not thorough.

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

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

The description is a single sentence that conveys the essential information with no redundancy. It is front-loaded and efficient.

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 no parameters, no output schema, and simple behavior (list running sessions), the description fully covers what an agent needs to know to invoke it correctly. No gaps remain.

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 schema coverage is 100% (vacuous). The description adds no parameter info because none exist, which is appropriate. Baseline 4 is justified.

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 verb 'List' and the resource 'running emulated PET sessions', and enumerates the fields returned (name, model, pid, monitor port). This distinguishes it from sibling session tools like pet_session_start or pet_session_stop.

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

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

The description implies usage: when you need to see currently running sessions. Since it's a simple list with no parameters, explicit when-not or alternatives are not necessary, but no guidance is provided for selecting among siblings. However, the clarity of purpose makes it adequate.

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

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

No annotations provided, so the description carries full burden. It states 'Leaves the machine running' but lacks details on effects (e.g., state clearing, side effects) and differences between soft and hard reset.

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 very concise with two sentences, no wasted words. However, it could be better structured to separate purpose from parameter 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 numerous sibling tools and two parameters, the description is incomplete. It fails to explain the session parameter, clarify the soft/hard distinction, or mention any return values (no 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 coverage is 0%, and the description only hints that 'hard' parameter controls the reset type. The 'session' parameter is completely unexplained, leaving agents guessing about its 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 clearly states 'Reset the PET' with differentiation between soft and hard power-cycle. It distinguishes from siblings like pet_session_start/stop, though it could be more explicit about what 'soft' versus 'hard' entails.

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

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

No guidance on when to use this tool versus alternatives such as pet_session_stop or pet_continue. The description does not mention prerequisites or when a reset is appropriate.

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

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

No annotations provided, so description carries full burden. It discloses headless and warp mode, and optional disk attachment, but omits details like whether warp means fast-forward, behavior if session already exists, or return value. Adequate but not thorough.

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

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

Two sentences with no fluff; front-loaded with the primary action. Every word earns its place. Efficient and well-structured.

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 no output schema and 3 parameters, the description covers main aspects: action, mode, models, optional disk. Missing details on 'name' and return value, but fairly complete for a start-session tool. Minor gaps prevent a perfect score.

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

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

Schema description coverage is 0%, so description compensates partially. It adds meaning for 'disk' (formats d64/d80/d82) and lists models, but does not explain the 'name' parameter or provide validation rules. Adds some value but not comprehensive.

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 verb 'Boot' and resource 'emulated PET', with mode 'headless, warp' and explicit model list. It distinctively describes starting a new session, differentiating from siblings like pet_session_list and pet_session_stop.

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

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

The description implies when to use (starting a new session) but does not explicitly exclude alternatives or state prerequisites (e.g., no session running). Clear context but lacks explicit 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?

No annotations are provided, and the description only states the action without disclosing side effects, reversibility, or prerequisites (e.g., session must be running). This leaves the agent without key 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?

The description is a single concise sentence that conveys the core purpose and parameter behavior efficiently, without extraneous words. It could be slightly expanded for completeness.

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 tool with one optional parameter and no output schema, the description covers the basic action and parameter nuance. However, it lacks details on return value, error cases, and prerequisites, making it adequate but not complete.

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 description adds meaning to the 'name' parameter by explaining the behavior when omitted ('the only one'), which is not present in the schema (0% coverage). However, it does not define what 'name' refers to (session name/ID) or provide format constraints.

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 verb 'Stop' and the resource 'a running PET session', and clarifies the behavior when 'name' is omitted. It is specific enough to distinguish from siblings like pet_session_start, but does not explicitly differentiate from pet_session_reset.

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

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

No guidance is provided on when to use this tool versus alternatives like pet_session_reset or pet_break_add. There is no mention of prerequisites or context for stopping a session.

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

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

With no annotations, the description adequately discloses that state comes from the daemon, can be 'unknown', and includes program and stale file info. No mention of destructive or rate-limit behavior, which is acceptable for a read-only status 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 fairly concise but the first sentence is grammatically awkward ('The session and whether...'). It front-loads key info but could be structured more smoothly.

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 lack of output schema and 0% parameter coverage, the description covers return values and data source adequately but misses explanation of the session parameter, leaving a gap for effective tool 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?

The description does not mention the 'session' parameter despite 0% schema coverage. The parameter is optional and defaults to null, but its purpose and expected values are unexplained, forcing the agent to guess.

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

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

The description clearly states that the tool reports session and machine running/stopped state, as well as the loaded program and stale source files. It distinguishes from siblings by focusing on status rather than session management 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 implies when to use this tool (to check status) but does not explicitly contrast with alternatives like pet_session_list. It provides context about daemon dependency but lacks explicit 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?

Given no annotations, the description adds some behavioral context: 'The machine STAYS STOPPED afterwards'. This informs the agent about the tool's action effect. However, it does not disclose potential destructive nature, session requirements, or other traits that would be expected with a 0% 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 concise with two sentences. It is front-loaded with the action and includes a key behavioral note, with no wasted words.

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

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

Given the lack of output schema and 0% parameter coverage, the description is significantly incomplete. It does not explain parameters or return values, leaving major gaps for an agent to correctly invoke the tool.

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

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

The description provides no explanation for the three parameters ('over', 'count', 'session'). With 0% schema coverage, the description should compensate, but it fails entirely, leaving the agent without guidance on parameter usage.

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 action ('Execute N instructions') and the resource ('instructions'). It distinguishes from the sibling 'pet_continue' by noting that the machine stays stopped and instructs to use 'pet_continue' to resume.

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 says the machine stays stopped and to use 'pet_continue' to resume, providing clear context for when to use this tool versus an alternative. However, it does not address other siblings like 'pet_run' or 'pet_until'.

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

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

No annotations are provided, so the description carries the full burden. It states the tool runs directories as tests but does not disclose whether it is read-only, modifies state, requires specific permissions, or reports results in a particular way.

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

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

The description is a single, concise sentence that front-loads the action and resource. Every word is necessary, with no wasted content.

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

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

The tool is simple (one optional param, no output schema), and the description covers the core functionality. However, it omits what the return value or output is, which would be valuable for an agent to understand the result of running tests.

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 provides only a 'directory' parameter with a default, but the description explains that it iterates over subdirectories each containing 'program' and 'expect.txt', adding significant meaning 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 the tool runs every example-program directory (program + expect.txt) as a test. The verb 'run' and the specific resource 'example-program directory' make the purpose explicit, and it distinguishes from sibling tools like pet_test_run which likely operates on a single test.

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

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

The description implies usage for batch testing of example programs, but it does not provide explicit guidance on when to use this tool versus alternatives like pet_test_run, nor does it mention preconditions or exclusions.

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

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

With no annotations provided, the description carries full burden but only mentions that it 'boots its own fresh PET,' implying a new environment. It does not disclose potential side effects, permissions needed, or what happens to existing sessions.

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 succinct with one clear sentence and an external reference. No redundant information, but the brevity sacrifices some clarity.

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 (one parameter, no output schema), the description is minimal. It relies on an external spec for completeness, making it insufficient for standalone understanding.

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

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

Schema description coverage is 0% for the single parameter 'yaml_file'. The description does not elaborate on the parameter's purpose, format, or constraints beyond the tool's overall action, leaving the agent without necessary details.

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

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

The description identifies the tool as running a declarative YAML test and notes that it boots its own fresh PET, which distinguishes it from sibling tools like pet_run. However, it could be more specific about what a 'declarative YAML test' entails.

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

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

No explicit guidance on when to use this tool versus alternatives such as pet_run or pet_build. The reference to 'see spec §8' is not actionable within the description itself.

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

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

With no annotations, the description must carry behavioral context. It discloses timeout behavior (machine left running, checkpoint removed) and that the machine stays stopped after count. However, it omits whether the tool is destructive, requires a session, or handles invalid ref gracefully.

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

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

Three concise sentences with minimal redundancy. Every sentence adds value, though the structure could be slightly improved (e.g., separating purpose from behavior). No fluff or tautology.

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 4 parameters, no output schema, and many sibling tools, the description is insufficient. It lacks information about return values (success behavior), session prerequisite, and error handling beyond timeout. The count>1 detail is useful but does not cover the overall completeness needed for safe 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 0%, so description must compensate. It explains 'ref' (address/symbol), 'count' (frame stepping when >1), and 'timeout' (triggers error). However, 'session' parameter is left unexplained, and no default value context is provided for other parameters beyond schema defaults.

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 uses a specific verb ('run') and resource ('address/symbol'), clearly distinguishing from siblings like pet_run (unconditional) and pet_step (single step). Additional details about count and frame stepping further clarify its unique function.

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

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

No explicit guidance on when to use vs alternatives (pet_run, pet_continue, pet_step). The mention of 'deterministic frame stepping' hints at a use case but does not provide clear when-to-use 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?

No annotations provided, so the description carries full burden. It discloses that the machine is left stopped on firing and left running on timeout, and that timeout returns data not error. This is good transparency but could mention more 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?

Two sentences, front-loaded with the primary purpose. Every sentence adds value—no fluff. The timeout case is concisely covered.

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 3 parameters and no output schema, the description covers core behavior and timeout edge case but lacks parameter explanations. It is adequate but not fully complete given the 0% schema coverage.

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

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

Schema description coverage is 0%, and the description only mentions 'timeout' implicitly. It does not explain 'session' or 'checkpoint_id'. The timeout parameter's default of 30 is noted in schema but not contextualized.

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?

Clearly states the tool blocks until a breakpoint/watchpoint fires, reports checkpoint id, PC, and registers. This specific verb-resource pair distinguishes it from sibling tools like pet_break_add and pet_step.

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?

Describes the blocking behavior and timeout handling, but does not explicitly tell when to use this vs alternatives like pet_step or pet_continue. The timeout scenario is well explained.

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 reveals that the tool blocks and accepts hex/decimal values, but it does not disclose timeout behavior, error conditions, or any side effects. With no annotations, this is only partial disclosure.

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

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

The description is a single sentence of 13 words, with the key verb placed first. Every word is necessary and there is no superfluous 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?

Given the 4 parameters, lack of output schema, and no annotations, the description is insufficient for a complete understanding. Missing details on address format, value format, timeout behavior, and how blocking is implemented.

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 description implies the roles of 'addr' and 'equals' but does not clarify their formats (e.g., address representation, value as single byte or string). The 'session' and 'timeout' parameters are ignored, and schema coverage is 0%.

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 action ('Block until'), the resource ('byte at addr'), and the condition ('equals the value'). It effectively distinguishes from siblings like 'pet_wait_break' and 'pet_wait_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?

No guidance is provided on when to use this tool versus alternatives, nor any conditions under which it should not be used. The description merely states the operation.

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

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

With no annotations, the description covers blocking nature, timeout return format, and that timeout is not an error. It does not detail side effects or permissions, but for a read/wait tool, this is adequate.

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

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

Two sentences pack the core behavior and unusual timeout return. No redundant 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?

Given no output schema, the description covers blocking, timeout, and return structure. It lacks details on text matching (exact/substring) and session scope, but overall sufficient for a wait-on-screen-text tool.

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

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

Schema coverage is 0%, and the description only hints at 'TEXT' and 'timeout' parameters. The 'session' parameter is not mentioned. This leaves ambiguity about parameter roles and formats.

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 it blocks until text appears on screen, using the verb 'Block' and resource 'TEXT'. It differentiates from siblings like pet_wait_break and pet_wait_mem by focusing on text detection.

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 timeout behavior (returns structure not error), which guides how to handle non-firing cases. It does not explicitly specify when to use versus alternatives, but the specificity of 'TEXT' implies its domain.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions default trigger (load and store), but doesn't describe what happens when a watchpoint is hit (e.g., execution stops, events emitted), or any side effects like destruction of existing watchpoints.

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

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

The description is a single concise sentence (14 words), no fluff. However, it sacrifices necessary detail for brevity.

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 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain what a watchpoint does, how to use the parameters, or what the outcome is.

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

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

With 0% schema description coverage, the description should explain all 5 parameters. It only hints at 'memory range' and 'load/store', leaving 'ref', 'length', 'on_load', 'on_store', and 'session' completely undefined.

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 verb 'Set' and resource 'watchpoint on a memory range', with the default behavior specified. It distinguishes from sibling tools like 'pet_break_add' which sets breakpoints, though not explicitly.

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

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

No guidance on when to use this tool versus alternatives like 'pet_break_add' or 'pet_wait_mem'. The description lacks context for appropriate usage scenarios.

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

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

No annotations provided, so description carries full burden. It explicitly states that breakpoints are kept, adding behavioral context. However, it does not disclose reversibility, effects on ongoing operations, or authorization 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?

Single sentence, no wasted words. Front-loaded with action and key distinction from breakpoints.

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 tool with one optional parameter and no output schema, the description covers the core functionality adequately. Minor gap: purpose of session parameter not addressed.

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?

Description provides no information about the session parameter. Schema description coverage is 0%, and there is no addition of meaning 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?

Description clearly states the tool removes ALL watchpoints (load/store checkpoints) and that breakpoints are kept. This distinguishes it from sibling tools like pet_break_clear.

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

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

Implies usage for clearing watchpoints but does not explicitly state when to use or not use, or provide alternatives. No exclusions or prerequisites mentioned.

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