Server Quality Checklist

Tool Scores

• read_registersB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return format in detail (dict with A, X, Y, S, PC, cycles, and flag string), but does not explicitly state that it is read-only, requires an active session, or what happens on failure. This is partial transparency.

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

  Conciseness5/5

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

  The description is brief and front-loaded, with every sentence contributing useful information. It efficiently conveys the purpose and the exact return format without excess words.

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

  Completeness4/5

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

  The tool is simple (one parameter) and has an output schema, so the description's detailed return format is a bonus. However, it lacks usage context and session_id semantics, making it slightly incomplete for an agent to invoke correctly in all scenarios.

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

  Parameters1/5

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

  The schema has a single required parameter 'session_id' with no description, and the tool description does not mention it. With 0% schema coverage, the description fails to compensate, leaving the parameter's meaning and source completely unexplained.

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

  Purpose5/5

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

  The description clearly states 'Return 6502 register state' with a specific verb and resource, distinguishing it from siblings like read_memory or disassemble. It also details the expected output keys, making the purpose unmistakable.

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

  Usage Guidelines2/5

  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. The description does not mention exclusions, prerequisites, or reference sibling tools, leaving the agent to infer usage from the name alone.

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

• write_memoryA
  3.9/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the burden. It discloses the core mutation (writing bytes) and the hex string format with whitespace tolerance. However, it does not mention side effects, persistence, failure modes, permissions, or what the output contains, which are relevant for a write operation.

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

  Conciseness5/5

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

  The description is three sentences with the main action front-loaded. The data format example is immediately useful and not redundant with the schema, and no sentence is wasted.

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

  Completeness3/5

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

  The description covers the non-trivial data format and symmetry with read_memory, but omits the meaning of session_id, which is required and not obvious from the schema. Given the output schema exists, return values need not be described, but the missing parameter context leaves the tool incomplete for invocation.

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

  Parameters3/5

  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 addr as the start location and data as a hex string with examples, but completely omits session_id, leaving one of three required parameters unexplained.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Poke bytes into memory starting at addr'. It clearly differentiates from sibling read_memory by explicitly noting it is symmetric and that read_memory's hex output can be round-tripped back in.

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

  Usage Guidelines4/5

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

  The description gives clear context that this is the write counterpart to read_memory, implying it should be used to modify memory with data obtained from read_memory. It does not explicitly state when not to use it or name alternatives, but the sibling symmetry provides practical guidance.

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

• destroy_machineA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the idempotent nature (double-destroy is common), the non-error return for unrecognized session IDs, and the side effect of releasing the subprocess. It does not detail permission requirements or other side effects, but for a simple teardown tool, this is sufficient.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and includes only essential behavioral detail. It is concise and well-structured.

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

  Completeness4/5

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

  For a single-parameter destruction tool with an output schema, the description adequately covers the purpose, the main error case, and the idempotency caveat. It does not describe success return or cleanup details, but these are likely covered by the output schema. Overall, it is complete enough for an agent to safely invoke.

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

  Parameters3/5

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

  The schema has 0% description coverage, so the description must compensate. It references 'session id' in the return text, confirming that the parameter is a session identifier, but it does not explain where the ID comes from (e.g., create_machine) or its format. This adds minimal value beyond the schema's title.

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

  Purpose5/5

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

  The description uses a specific verb ('tear down', 'release') and identifies the resource ('session', 'beebjit subprocess'). It clearly distinguishes from sibling tools like create_machine and reset by describing termination rather than creation or state reset.

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

  Usage Guidelines3/5

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

  The description implies usage for ending a session but does not explicitly state when to use it vs. alternatives. The double-destroy note gives contextual guidance that calling it on an unrecognized session is safe, but no direct comparison to reset or other lifecycle tools is provided.

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

• read_mode7_textA
  4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full burden. It thoroughly explains the behavior for non-printable bytes under each 'controls' option (row width, visual representation, byte preservation), and discloses the return format (raw row list and joined string). It also discloses the Pydantic wire-boundary rejection of unknown enum values. It does not discuss error handling for an invalid session_id or what happens if MODE 7 is not active, but the disclosed behavior is substantial and accurate for a read tool.

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

  Conciseness5/5

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

  The description is front-loaded with the core purpose, then uses a clean bulleted list for the 'controls' options. Each sentence earns its place: the first sentence gives the high-level function, the bullets explain parameter behavior, the JSON/Pydantic paragraph clarifies wire-format expectations, and the final sentence summarizes return values. No redundant filler.

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

  Completeness4/5

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

  Given the tool's complexity (2 params, no annotations, but an output schema), the description is quite complete. It covers the main parameter behavior, return format, and coercion logic. The missing explanation of session_id is the primary gap, and it could also benefit from a note about when the screen is in MODE 7 vs. other modes. Nevertheless, most necessary information for invocation is present.

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

  Parameters3/5

  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 does so excellently for the 'controls' parameter, detailing the three enum values, their display effects, and caller considerations. However, it never explains 'session_id'—not its purpose, format, or relationship to the machine/session. Since session_id is required, its omission is a clear gap. The description covers only 50% of parameters meaningfully.

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

  Purpose5/5

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

  The description opens with a clear, specific verb-object statement: 'Capture the MODE 7 screen as 25 rows of teletext text.' This verb ('capture') distinguishes it from sibling tools like screenshot (visual capture) or read_memory (raw memory access), and the result (25 rows of text) is unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage: if you need MODE 7 screen text, this is the tool. It does not explicitly contrast with alternatives (e.g., 'use screenshot for graphics' or 'use read_memory for raw bytes'). However, it does provide guidance on choosing between the 'controls' values (e.g., 'best for substring assertions' vs. 'when callers need the original byte value'), which is a form of usage guidance for parameter selection. No exclusions or when-not-to-use conditions are given.

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

• key_upA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description takes on the full burden of disclosure. It reveals the raw event nature, the inverse behavior, the accepted key formats, and the special RELEASE_ALL effect, which is valuable behavioral context. It doesn't discuss session_id, but that's a shared parameter rather than a tool-specific behavior.

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

  Conciseness5/5

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

  The description is only three sentences, with the first stating the core purpose, the second clarifying the inverse relationship, and the third detailing the special case. Every sentence adds value, and it is efficiently front-loaded.

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

  Completeness4/5

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

  Given the tool's simplicity (two parameters, output schema present), the description covers purpose, relationship, and a special value. However, it omits any explanation of session_id and leaves key formats implicit, which could be more explicit. Overall it's sufficient but not exhaustive.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate for missing parameter information. It partially does for 'key' by referencing key_down's formats and the special RELEASE_ALL value, but it leaves 'session_id' entirely unexplained and does not enumerate key format options. The compensation is incomplete.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Inject a raw BBC keyup event into the matrix.' It also differentiates itself from key_down by directly stating it's the inverse, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  Provides explicit guidance by positioning itself as the inverse of key_down and documenting the RELEASE_ALL special case for clearing all held keys. It doesn't explicitly list exclusions, but the relationship to key_down is clear enough for an agent to know when 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.

• screenshotA
  4.1/5.0
  Behavior5/5

  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 details the return format (MCP image content block), client compatibility, PNG header dimension extraction, dependency on a fork binary with specific commands, and the structured error behavior for older binaries. This is comprehensive transparency.

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

  Conciseness5/5

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

  The description is composed of several concise sentences, each adding distinct technical value: return type, client support, PNG header details, rendering backend, binary prerequisites, and error handling. There is no fluff or repetition.

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

  Completeness4/5

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

  The description covers return format, compatibility, prerequisites, and error behavior, which is strong for a simple tool. However, it omits an explanation of the session_id parameter and does not explicitly state that the operation is non-destructive (though the context implies it). These are minor gaps.

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

  Parameters2/5

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

  The schema has one required parameter (session_id) with no description, and schema coverage is 0%. The description never mentions session_id, how to obtain it, or its role in identifying the target machine, so it does not compensate for the schema's lack of parameter documentation.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Capture the current rendered BBC screen as a PNG.' This clearly states what the tool does and inherently distinguishes it from sibling tools like read_memory or read_mode7_text, which extract text or data rather than visual images.

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

  Usage Guidelines3/5

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

  The description implies usage when a visual snapshot is needed and notes that it works in any BBC display mode, but it does not explicitly state when to use this tool versus alternatives (e.g., read_mode7_text for text-based screen inspection) or provide exclusions. The context is clear but not explicitly comparative.

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

• read_memoryA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful details: returns both hex and ASCII views, and explains the dot-substitution convention for non-printable characters, tying it to hexdump. The word 'Peek' strongly implies a non-mutating read, though it does not explicitly state side-effect-free behavior or error conditions, which would be useful.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core operation and parameters. Every sentence adds value: the first defines the action, the second explains a display convention. No redundancy or filler.

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

  Completeness4/5

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

  Given the tool's simplicity, the description covers the essential behavior: what it reads, how much, and the return format. An output schema exists, so the return structure need not be fully described. However, missing details such as behavior on invalid addresses or length boundaries are minor omissions. Overall, it is sufficient for a straightforward memory-read tool.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains 'length' and 'addr' in context ('Peek `length` bytes starting at `addr`'), which directly clarifies these two parameters. 'session_id' is not mentioned, but it is a common context parameter that the agent can infer from the tool name and sibling tools, so this is a minor gap.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Peek `length` bytes starting at `addr`' – a specific verb with resource and scope. It distinguishes itself from siblings like disassemble and read_registers by specifying the output is hex and ASCII views, making its raw-memory-inspection role unambiguous.

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

  Usage Guidelines3/5

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

  The description implies usage for raw memory inspection via 'Peek' and 'hex and ASCII views', but it does not explicitly state when to use this tool versus alternatives like disassemble or read_registers. No exclusions or alternative conditions are mentioned, so the guidance remains implicit rather than explicit.

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

• run_for_cyclesA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of disclosing behavior. It explains what happens (advances emulator by a number of cycles) and what is returned (cycles consumed and total count). This is sufficient for a simple step tool, though it does not mention potential side effects (e.g., stopping on error or breakpoints) or permission needs.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core action. The second sentence adds valuable return-value context without waste. Every word earns its place.

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

  Completeness4/5

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

  For a simple 2-parameter tool with an output schema (which likely details return values), the description provides enough context: it states the action and explains why the return value is useful. It omits edge cases (e.g., behavior when machine is not running) but overall is adequate for its simplicity.

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

  Parameters3/5

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

  The schema provides only names and types (cycles: integer, session_id: string) with no descriptions. The description explains that `cycles` is in 'BBC cycles', adding unit context, but does not elaborate on valid ranges or behavior. session_id is left entirely to inference from its name. Since schema coverage is 0%, the description partially compensates but leaves gaps.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Advance the emulator by `cycles` BBC cycles.' This is a specific action on a specific resource, distinguishing it from siblings like run_basic or run_until_prompt. The addition of the return-value benefit (tracking session progress) further clarifies its unique role.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool by noting it avoids a separate `read_registers` round trip, which is useful for session progress tracking. However, it does not explicitly contrast with alternatives (e.g., 'use this instead of run_until_text') or state exclusions. The guidance is clear but not fully explicit.

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

• run_until_promptA
  4.2/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the burden. It discloses chunked execution, row-anchoring behavior, the default prompt value, and the return fields. However, it does not explain behavior on max_cycles exhaustion or error conditions, so it is 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.

  Conciseness5/5

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

  The description is four sentences, front-loaded with the core action, and every sentence adds value: behavior, use case, differentiation, default, and return values. No filler.

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

  Completeness4/5

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

  For a 4-parameter tool with an output schema, the description covers purpose, usage, key behavior, defaults, and return values. It omits edge-case handling (e.g., what happens if max_cycles is hit), but the essential context for correct invocation is present.

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

  Parameters3/5

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

  Schema coverage is 0%, so the description must compensate. It explains the `prompt` default and its matching behavior, and lists return fields, but provides no details on `max_cycles` or `chunk_cycles` beyond their names and defaults. Partial compensation only.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Run in chunks until `prompt` appears at the start of a MODE 7 row.' It clearly differentiates from the sibling `run_until_text` by anchoring to row start, making the tool's purpose unambiguous.

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

  Usage Guidelines4/5

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

  It explicitly identifies the common use case ('wait for BASIC to return to the `>` prompt') and contrasts with `run_until_text`, giving the agent clear guidance on when to use this tool. It does not enumerate every when-not scenario, but the distinction is sufficient.

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

• type_input_rawA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and discloses critical behavioral traits: the caps lock dependency, cold-boot default, and the consequence of case mismatches (wrong letter, no silent fallback). This goes beyond simple repetition of the tool name.

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

  Conciseness5/5

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

  Two concise sentences: the first states the core action, the second covers a critical prerequisite. No wasted words or redundant information.

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

  Completeness4/5

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

  The description sufficiently covers the main caveat and required setup for simple input tool. It does not mention return values, but an output schema exists, so that omission is acceptable. It could benefit from explaining session_id's role more fully.

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

  Parameters3/5

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

  Schema coverage is 0%, and the description only partially compensates: it clarifies that 'text' must be an ASCII string, but 'session_id' is only implicitly referenced in the example call to set_caps_lock, leaving its purpose and format unclear.

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

  Purpose5/5

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

  The description uses a specific verb ('Type') and resource ('ASCII string, preserving case'), clearly distinguishing it from sibling tools like type_input. The case-preservation detail adds specificity.

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

  Usage Guidelines4/5

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

  Explicitly states the prerequisite (CAPS LOCK OFF) and how to ensure it via set_caps_lock, providing clear when-to-use guidance. However, it does not explicitly contrast with alternative input tools or mention 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.

• boot_discA
  4.4/5.0
  Behavior5/5

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

  No annotations are present, so the description carries the full transparency burden. It discloses that the tool performs a soft reset, preserves the running BBC's state, blocks until the boot banner reappears, and returns only after `!BOOT` is running or finished. This is detailed, accurate, and gives strong expectations for behavior.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the core action. Each sentence adds necessary information: the equivalence, the workflow rationale, and the blocking/return behavior. No filler or redundant words.

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

  Completeness4/5

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

  The description richly covers purpose, equivalence, state preservation, blocking behavior, and return condition, which is substantial for a complex tool. An output schema exists, so return-value details are not required. The only clear gap is per-parameter explanation, and the description relies on the sibling `load_disc` for that, so it is not fully complete.

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

  Parameters2/5

  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 explain `disc`, `drive`, `mutable`, `writeable`, or `session_id`. The phrase 'same parameters as `load_disc`' delegates to a sibling tool rather than adding meaning within this description, leaving the agent to cross-reference.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Mount a disc and SHIFT+BREAK autoboot it in one call.' It further distinguishes itself from siblings by explicitly stating it is equivalent to `load_disc` followed by `reset(autoboot=True)`, so an agent can clearly tell what unique operation this tool performs.

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

  Usage Guidelines5/5

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

  The description states this is for the common 'load and run' workflow and names the alternative composition (`load_disc` followed by `reset(autoboot=True)`). It also notes 'same parameters as `load_disc`', giving clear guidance on when to choose this tool over related siblings.

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

• key_downA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description takes on full burden. It discloses key behaviors: the press stays held until key_up, single-character ASCII strings map to matrix positions, and longer strings route through SPECIAL_KEYS. These are behavioral traits beyond the schema. It does not mention potential effects like key repeat or error handling, but the essential statefulness is well covered.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action. Every sentence contributes: the first line states the purpose, the second explains key semantics, and the third warns about held state with an alternative. No filler, and the structure aids quick comprehension.

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

  Completeness4/5

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

  For a tool with only two parameters and an existing output schema, the description covers the essential semantics: what the tool does, how the key parameter behaves, and how it differs from type_input. It does not clarify session_id, but that is minor given the commonality and the presence of an output schema. Overall, the context is sufficiently complete for an agent to select and invoke the tool correctly.

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

  Parameters4/5

  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 thoroughly explains the 'key' parameter: accepts symbolic names or integer codes, with single-character strings treated as matrix positions and longer strings via SPECIAL_KEYS. The session_id parameter is left unexplained, but it is a common context parameter across sibling tools and self-explanatory. The key explanation adds significant meaning beyond the raw schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Inject a raw BBC keydown event into the matrix.' The verb is specific (inject), the resource is a keydown event, and it distinguishes from the sibling type_input by emphasizing 'raw' and the held behavior. The phrase 'raw' also sets it apart from higher-level input tools.

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

  Usage Guidelines4/5

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

  The description explicitly says to use type_input instead for a tap, providing a clear alternative. It also implies the tool is for held keys and pairs with key_up. However, it does not enumerate all sibling alternatives (e.g., press_caps_lock) or state when not to use it beyond the type_input case, though the provided guidance is strong.

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

• press_caps_lockA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It clearly states that the tool does not know or care about the pre-tap state, which is a crucial behavioral trait. It doesn't mention other potential constraints (e.g., machine must be running), but for a simple toggle this is sufficient.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the main purpose, and every sentence earns its place. It is concise and well-structured without any redundant information.

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

  Completeness5/5

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

  The tool is simple, the output schema covers returns, and the description provides the necessary behavioral details and alternative tool guidance. It is complete enough for an agent to select and invoke this tool correctly.

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

  Parameters2/5

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

  The schema has 0% description coverage (no parameter descriptions), and the description does not mention session_id at all. The parameter name is self-explanatory, but the description adds no semantic value beyond what the schema already shows. For a low-coverage schema, the description should compensate, and it doesn't.

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

  Purpose5/5

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

  The description clearly states the tool taps CAPS LOCK once to toggle the current state, using a specific verb and resource. It also distinguishes itself from the sibling tool set_caps_lock by calling out that it is a pure toggle, making it easy to differentiate.

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

  Usage Guidelines5/5

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

  The description explicitly provides an alternative: use set_caps_lock(session_id, on) when a deterministic final state is needed. This gives clear guidance on when to use this tool vs. the alternative, and why.

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

• set_caps_lockA
  4.4/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full responsibility. It discloses the exact mechanism: reads `&025A`, taps key 135 conditionally, and returns the resulting state and whether a tap was issued. It also explains side effects (physical key tap) and the return value, providing excellent transparency.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line summary followed by a concise explanation of the underlying logic. Every sentence adds value—what it does, how it works, and what it returns—without redundancy or fluff.

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

  Completeness4/5

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

  For a simple tool with only two parameters and an output schema, the description covers the essential behavior, return values, and side effects. It lacks details on potential error conditions or required permissions, but given the low complexity and presence of an output schema, it is nearly complete.

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

  Parameters4/5

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

  The input schema provides only types and names, with 0% coverage of descriptions. The description clarifies the `on` parameter by explaining that the tool compares the current state to `on` and taps only if different, giving it semantic meaning. The `session_id` is not described, but it is a standard parameter across sibling tools and likely needs no further explanation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Set CAPS LOCK to a specific state, tapping only if needed.' It specifies the action (set), the resource (CAPS LOCK), and the behavior (conditional tap). This distinguishes it from the sibling tool `press_caps_lock`, which likely just toggles the key without a defined end state.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool—when you need to assert a specific CAPS LOCK state—and mentions the benefit of not needing a follow-up `read_memory`. However, it does not explicitly state alternatives or when not to use it, nor does it compare itself to `press_caps_lock` or other input tools.

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

• resetA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses key behavioral aspects: the reset is equivalent to pressing BREAK, autoboot holds SHIFT, the session remains valid, and subsequent calls hit the same session. This adds value beyond the schema, though it does not mention all side effects like memory clearing, which is implied by 'reset'.

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

  Conciseness5/5

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

  The description is four sentences long, each earning its place. It uses clear formatting with line breaks and code spans, and no fluff. It is front-loaded with the core purpose and then adds nuance.

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

  Completeness5/5

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

  For a tool of this complexity, the description is thorough: it explains the reset semantics, the autoboot option, and session persistence. It covers the essential edge cases and clarifies what makes this reset different from a destructive one. The output schema exists, so return values need not be described.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It explains `autoboot` thoroughly (holds SHIFT, runs !BOOT). `session_id` is implicitly covered by stating it stays valid and identifies the session. While session_id is not explicitly defined as an identifier, the context makes it understandable.

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

  Purpose5/5

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

  The description clearly states the tool 'Hard-reset the BBC without destroying the session', providing a specific verb and resource. It distinguishes itself from sibling tools like destroy_machine by explicitly noting the session is preserved, and from run_basic etc. by describing the reset action.

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

  Usage Guidelines4/5

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

  The description implies when to use it: when a reset is needed but the session must remain intact. It explains the autoboot variant with SHIFT+BREAK behavior. However, it does not explicitly name alternatives (e.g., destroy_machine) or describe when NOT to use it, so it falls short of full alternative guidance.

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

• run_basicA
  4.5/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses key behaviors: issuing `NEW`, requiring line numbers, boot/settle cycle budgets, and returning rows/text. It does not detail error handling or timeout behavior, which is a gap.

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

  Conciseness5/5

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

  The description is compact and well-organized. It front-loads the core purpose, then explains parameters and return values in separate sentences. Every sentence contributes useful information without redundancy.

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

  Completeness4/5

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

  Given 4 parameters and an output schema, the description covers the main workflow, parameter meanings, and return format. It lacks explicit error/timeout behavior, but the overall completeness is high.

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

  Parameters5/5

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

  The description adds meaning to all key parameters: `program` (full source, no auto-numbering), `boot_cycles` (time for NEW-to-prompt), and `settle_cycles` (max execution budget). It also explains the output shape. The schema has 0% coverage, so this description is essential and thorough.

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

  Purpose5/5

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

  The description opens with a specific, actionable statement: 'Type a BBC BASIC program, RUN it, and return the final screen.' It clearly identifies the tool as a convenience wrapper around type_input and cycle runs, distinguishing it from sibling tools like type_input or run_for_cycles.

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

  Usage Guidelines4/5

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

  The description explains that this is a convenience wrapper around `type_input` + cycle runs, which implies the manual alternative. It does not explicitly list exclusions or when to prefer other run tools, but the context is clear.

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

• disassembleA
  4.7/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so effectively. It discloses the count cap, the return structure (list of dicts with addr, info, text), and the meaning of the info tag (beebjit's per-line tag). This goes beyond basic operational details.

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

  Conciseness5/5

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

  The description is concise and well-structured, with three sentences that deliver the essential information. It front-loads the primary action and then provides return format and usage nuance without unnecessary words.

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

  Completeness5/5

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

  For a tool of moderate complexity, the description is complete: it covers the operation, the return format, the count cap, and a looping strategy. An output schema is present, and the description complements it by explaining the semantics of the returned fields.

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

  Parameters4/5

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

  Despite 0% schema description coverage, the description explains the semantics of `addr` (starting address) and `count` (number of instructions, capped at 20). `session_id` is not explained but is likely a common parameter across siblings, so the description compensates reasonably for the most critical parameters.

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

  Purpose5/5

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

  The description clearly states the tool disassembles 6502 instructions starting at a given address, using a specific verb and resource. It distinguishes itself from sibling tools like read_memory by focusing on instruction disassembly rather than raw memory access.

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

  Usage Guidelines4/5

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

  The description explains the count cap and provides explicit guidance on how to loop for longer disassemblies by advancing to the address past the last instruction. It does not explicitly mention when not to use this tool, but the context is clear and practical.

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

• reload_moduleA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the reload is in-place ('the next tool call picks up the change'), and discloses the rejection of module types that would invalidate live session objects. This provides useful behavioral context, though it does not detail the success/failure return format beyond what an output schema might imply.

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

  Conciseness5/5

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

  The description is two short sentences, with the first sentence front-loading the core purpose and the second adding necessary usage and constraint context. Every word earns its place, with no redundancy or filler.

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

  Completeness5/5

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

  For a single-parameter tool with an output schema and no annotations, the description covers all relevant aspects: purpose, usage timing, constraints, and examples. It is sufficiently complete to allow an agent to select and invoke the tool correctly without additional information.

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

  Parameters4/5

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

  The input schema provides only the parameter name 'module_name' with no description, and schema coverage is 0%. The description compensates by giving specific examples of valid values ('keyboard.py', 'screen.py') and explicitly rejecting others ('driver', 'server'), effectively conveying the expected parameter values and constraints despite the barren schema.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Reload') and resource ('a pure beebjit_mcp module'), and immediately distinguishes it from any sibling by noting it works without restarting the server. It also provides an intended use case (in-session development) and concrete examples, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use context ('Intended for in-session development') and when-not-to-use guidance by specifying that only pure (IO-free) modules are supported and that reloading 'driver' or 'server' is rejected. This clearly delineates the tool's valid and invalid usage scenarios.

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

• create_machineA
  4.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the full responsibility for behavioral disclosure. It clearly states that the disc is mounted read-only, autobooted with SHIFT+BREAK, and that the model determines disc-image format compatibility. While it doesn't mention resource cleanup or side effects, the provided details are substantive and go well beyond a generic 'create' description.

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

  Conciseness5/5

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

  The description is four sentences, each serving a distinct purpose: main action, session_id importance, parameter behavior, and disc format compatibility. It is front-loaded with the primary purpose 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.

  Completeness5/5

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

  Given the tool's moderate complexity (2 params, output schema present), the description covers all crucial aspects: return value, parameter selection, mount behavior, and alternative tool usage. It also provides enough context to distinguish from siblings and for an agent to invoke it correctly in a multi-tool workflow.

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

  Parameters5/5

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

  The schema only provides bare property names and defaults with no descriptions. The description richly explains both parameters: `model` enumerates accepted values with model names (b, master, mos35, compact), and `disc` is described as an optional path with mounting, read-only, and format implications. This fully compensates for the 0% schema description coverage.

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

  Purpose5/5

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

  The description opens with 'Boot a BBC Micro session,' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like load_disc and boot_disc. It also states the return value (session_id) and its role as a prerequisite for subsequent tools, making its purpose unambiguous.

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

  Usage Guidelines5/5

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

  The description explicitly directs users to call `load_disc` directly for writeable or host-mutating mounts, contrasting with this tool's read-only mounting behavior. It also implies this should be used first by stating the returned session_id is required by every subsequent tool. This provides clear when-to-use and 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.

• load_discA
  4.9/5.0
  Behavior5/5

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

  No annotations are present, but the description details side effects: whether the host file is modified, the read-only default, and the lack of reset/autoboot. It also specifies valid drive values (0 or 1).

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

  Conciseness5/5

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

  The description is three focused paragraphs, each sentence contributing to usage, side effects, or alternatives. It is well-structured and free of redundant content.

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

  Completeness5/5

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

  Despite no annotations and zero schema descriptions, the description covers all critical behavioral traits, parameter semantics, and alternative tools, making it fully actionable for an AI agent.

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

  Parameters4/5

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

  The description explains the meaning of drive, writeable, and mutable, including defaults and the relationship between mutable and writeable. It does not explicitly detail disc or session_id, but the overall context and self-evident naming make them clear.

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

  Purpose5/5

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

  The description clearly states 'Mount a disc image into the named drive at runtime' with a specific verb and resource, and further distinguishes itself by noting it does not trigger reset/autoboot, contrasting with boot_disc.

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

  Usage Guidelines5/5

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

  It explicitly describes when to use this tool versus boot_disc, including a composed alternative with reset(autoboot=True). It also clarifies that mutable requires writeable, giving clear usage conditions.

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

• run_until_textA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses key behaviors: substring matching on the entire decoded screen (not row-anchored), early return on match, timeout with `found=False`, and the return object keys. It also explains the performance implications of chunk size, which is valuable context beyond the schema.

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

  Conciseness5/5

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

  The description is concise (~90 words) and front-loaded with the core purpose. Every sentence adds value: matching semantics, alternative usage, early return, timeout behavior, chunk trade-off, and return format. No redundancy or filler.

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

  Completeness5/5

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

  Despite having no annotations and 0% schema coverage, the description provides a complete operational picture. It covers behavior, termination conditions, return values, and gives actionable guidance. The presence of an output schema is supplemented by the explicit specification of return keys. The tool's complexity is well addressed.

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

  Parameters4/5

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

  Schema description coverage is 0%, but the description compensates by explaining the meaning of `needle` (the text to find), `max_cycles` (timeout), and `chunk_cycles` (chunk size). The `session_id` parameter is not explicitly described, but it is a common identifier likely inferred from context. This is strong compensation but not perfect coverage of all parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Run in chunks until `needle` appears anywhere in the MODE 7 screen.' It uses a specific verb (run), a specific resource (MODE 7 screen), and a condition. It also distinguishes itself from sibling tool `run_until_prompt` by explaining the difference in matching semantics.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: 'Use `run_until_prompt` when the marker must sit at the start of a row.' This directly addresses when to use an alternative. The description also explains the trade-off of chunk size, helping the agent choose appropriate values.

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

• type_inputA
  4.9/5.0
  Behavior5/5

  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 default keypress timings, uppercase transformation behavior, error raising (`UnsupportedCharError`), and the return value structure (`{"ok": true, "chars": N}`). This is comprehensive behavioral disclosure.

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

  Conciseness5/5

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

  The description is concise and well-structured. It starts with the core purpose, then covers timings, special characters, case behavior, error handling, and return format. Every sentence adds useful information without redundancy.

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

  Completeness5/5

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

  The tool has an output schema and the description covers input semantics, error conditions, and return shape. It correctly references the sibling alternative and prerequisites (e.g., `set_caps_lock`). For a simulation keyboard input tool, this description is fully complete.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It thoroughly explains the `text` parameter: ASCII string, newline submission, and case transformation. The `session_id` parameter is not explicitly described, but its meaning is self-evident from the name and sibling tools. Overall, meaningful value is added beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Type an ASCII string into the BBC keyboard.' It uses a specific verb and resource, and explicitly distinguishes itself from the sibling tool `type_input_raw` by mentioning case preservation differences.

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

  Usage Guidelines5/5

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

  Provides explicit guidance on when to use this tool versus `type_input_raw`: use `type_input_raw` after disabling caps lock when case must be preserved. It also explains how to submit lines with `\n`, giving clear operational context.

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