Server Quality Checklist

Tool Scores

• mission_startA
  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 meaningful behavior: state is persisted in the server's database, only one mission may be active, a conflicting start is refused, and the reply is a status block. It does not cover auth requirements or failure modes beyond the concurrency conflict, but the state-machine disclosure is substantive.

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

  Conciseness3/5

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

  The content is dense and mostly earns its place, but the framing is deliberately narrative ('before you lose it', 'a confident recollection of it'), and the context-window motivation sentence spends prose on why rather than what to do. The actionable verb is not front-loaded; the workflow and constraints arrive well into the text.

  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 stateful, multi-step tool with a weak schema and an output schema present, the description supplies the missing nested parameter structure, the concurrency constraint, the reply composition, and the surrounding workflow. Nothing an agent needs to call it correctly is absent.

  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?

  Schema description coverage is 0% and the nested item structure is undefined in the schema, so the description fully compensates: goal is defined as the purpose of the whole run, and items is defined as an ordered checklist of {title, intent, acceptance} with each field's meaning. It further specifies that all three are required and none may be blank — meaning the description adds information the schema does not.

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

  Purpose4/5

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

  Once parsed, the description clearly states it creates a persistent mission record holding the run's goal and an ordered checklist. It names the resource (mission) and the workflow verb framing ('write down'), and differentiates from siblings by describing the loop through execute_plan, mission_replay, and mission_finish. The core verb is somewhat buried under the 'long run' metaphor, which slightly muddies the first read.

  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 gives a clear trigger (before a long run / before you lose the plan) and an explicit workflow ordering all related siblings. It also states a hard constraint: one mission active at a time, and a second start is refused naming the mission to finish or abandon. No explicit 'when not to use' beyond that, so it stops just short of a 5.

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

• mission_finishA
  4.3/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 does well: it discloses the slot lifecycle effect, that nothing is deleted, that items retain recipes and reasons, and what the response contains. It omits error/permission behavior (e.g. calling with no active mission), which is the main remaining gap.

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

  Conciseness4/5

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

  Front-loaded with the core action and every sentence adds information (parameter meaning, slot consequence, non-destruction). The sentences are long and clause-heavy, but there is little pure 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?

  An output schema exists, so return values need not be documented, yet the description still characterizes the reply as the full checklist record. Combined with the slot-freeing and non-destructive semantics, this is nearly complete for a one-parameter mutation tool; only the no-active-mission failure case is unaddressed.

  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% and the single status parameter has no description or enum, so the description must supply meaning — and it does, defining 'done' and 'abandoned' semantics and clarifying that failure counts do not determine status. It stops short of enumerating whether other values are accepted.

  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?

  States a specific verb and resource ('Close the active mission') and immediately ties it to the sibling relationship — closing frees the slot that mission_start needs — so an agent can separate it from mission_start, mission_status, and mission_mark without opening a schema.

  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?

  Gives clear conditions for the required parameter choice (done vs abandoned) and explicitly addresses the ambiguous case of failed items, telling the agent it is a judgement call rather than a server rule. It does not, however, name a sibling alternative or say what to do if no mission is active.

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

• mission_markA
  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 and does substantial work: failed REQUIRES reason, reason is refused on other statuses, and the reply format is the status block. It omits idempotency/re-marking behavior and error handling, but the mutation constraints are unusually well disclosed.

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

  Conciseness4/5

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

  Purpose is front-loaded and each clause largely earns its place (status semantics, reason rule, skipped definition). It is on the long side and the 'asserts two contradictory things' clause is rhetorically verbose, but nothing is truly redundant.

  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?

  An output schema exists and the description notes the reply is the status block, so return values needn't be expanded. Coverage of status semantics, reason validity, and sibling routing is strong; only item_id mechanics and re-marking/error behavior are left uncovered.

  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 fully defines the status enum (passed/failed/skipped) and the conditional requirement on reason, including the rationale. item_id is left to inference from 'checklist item,' but the two non-obvious parameters are well covered.

  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?

  States a specific verb+resource ('Mark a checklist item yourself') and immediately scopes it to acceptance criteria only the agent can check. Explicitly distinguishes itself from the sibling execute_plan, so an agent can select between them without opening either schema.

  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?

  Gives an explicit routing rule: runs mark their own items via execute_plan with mission_item_id, so use this 'when there was nothing to execute or when the executor's verdict was not the point.' It also defines when each status applies, including what skipped means and when it is not a defect.

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

• mission_statusA
  4.6/5.0
  Behavior4/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, and it does substantial work: it enumerates the default return content (goal, progress, current item in full, failures) and discloses that the full mode scales with the checklist. It does not explicitly state that this is a safe read-only call or describe cost/latency beyond the implicit 'not after every run', leaving a small gap given zero annotation coverage.

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

  Conciseness4/5

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

  Front-loads the purpose, then handles usage and the parameter in a tight sequence. The closing clause ('which is why it is a separate call') is somewhat self-justifying filler, but overall the length is proportionate to the information conveyed.

  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 one-optional-param read tool with an output schema, the description supplies everything an agent needs: what the two modes return, when to invoke each, and how the tool relates to execute_plan. Nothing required for correct invocation is missing.

  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% for the single boolean 'full', but the description compensates well, explaining that default yields the compact block while full=true returns every item with id and status and is the only mode that grows with the list. Meaning beyond the bare boolean is clearly added.

  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?

  Opening sentence names the resource and scope ('where the active mission stands') with a concrete read verb implied, and the description explicitly distinguishes it from execute_plan by noting the default output is the same compact block that tool already returns. An agent can tell this apart from mission_start/mission_mark/mission_finish without any schema lookup.

  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?

  Gives explicit when-to-use ('call it when you have lost the thread'), explicit when-not ('not after every run'), and a separate condition for the full=true mode ('before deciding a mission is done'). Alternative-driven reasoning is fully spelled out.

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

• annotate_iconsA
  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 behavioral burden and does so: crops come from memory, nothing is captured or clicked, it is safe to call while the user is working, the sheet is capped, and the reply reports remaining counts. It even explains why one sheet covers exactly one app.

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

  Conciseness3/5

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

  The opening sentence ('Ask what the wordless icons of an app are called...') is indirect framing rather than a direct statement of what is returned, so the key payload arrives late. The rationale sentence about glyphs meaning whatever the drawing program says adds color but is not strictly needed for correct invocation.

  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?

  No output schema or annotations exist, yet the description fully covers the return format (picture plus legend fields: app, window, position, size, nearby texts, other windows), edge cases, and the next step. An agent has everything needed to call and interpret it.

  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% for the single app_name parameter, so the description must compensate, and it does: app_name is optional and, when omitted, the app with the most-drawn unnamed glyph is selected and named in the reply. It does not, however, specify accepted name formats or how matching is performed.

  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?

  States a specific action and concrete return artifact: a numbered-grid picture of every unnamed glyph of one application plus a text legend with per-cell context. It also explicitly distinguishes itself from siblings observe and submit_icon_labels by naming them in the round trip.

  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?

  Gives explicit when-to-use (after observe reports 'icons: K labeled, M unlabeled'), the paired follow-up tool (submit_icon_labels), the sequencing loop, and the app_name-omitted behavior. It also states the terminal case (all glyphs named) and the cap with a hint to call again.

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

• submit_icon_labelsA
  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: it discloses the wide-reaching persistence ('written onto the glyph AND onto every place it is already drawn on the map, and every future sighting'), the atomicity guarantee ('applied whole or not at all'), and the failure mode (invalid key, blank name, or missing app_name returns a sentence rather than a partial write). These are exactly the side-effect and error semantics an agent needs for a mutation tool.

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

  Conciseness4/5

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

  Front-loaded with purpose, then parameter semantics, then persistence/atomicity/error behavior, then the reply — every clause adds information. It is a dense single paragraph with some run-on sentences and no visual structure, which costs a point but nothing is wasted.

  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?

  An output schema exists, so return values need not be spelled out, yet the description still frames them usefully ('how many glyphs and places were named and how many of that app's icons are still unnamed'). For a 2-param mutation tool with zero annotations and zero schema coverage, all decision-relevant context — sequencing, key semantics, persistence, atomicity, errors — is present.

  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?

  Schema coverage is 0%, so the description must compensate, and it does: it defines the labels key as 'the string annotate_icons printed for that cell, NOT the cell number' and the value as 'the name of the control, in the words a user would use for it' with concrete examples, plus app_name as 'the application annotate_icons reported'. This resolves the most likely ambiguity (key vs. cell index) that the bare object schema leaves open.

  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?

  States a specific verb+resource ('send back what the icons on an annotate_icons sheet are called') and explicitly positions itself as 'the second half of the round trip' relative to the annotate_icons sibling. An agent can distinguish this from annotate_icons and from the other siblings without opening either schema.

  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 sequencing guidance is explicit: this is the return half of the annotate_icons round trip, and the description even shows the downstream step ('target it by the name you gave it: {action:'click', target:{text:'Share'}}'). It does not state an explicit when-not-to-use or a named alternative for submitting labels differently, so it stops just short of a 5.

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

• focus_appA
  4.8/5.0
  Behavior5/5

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

  With no annotations to lean on, the description carries the full burden and does so well: launch-on-demand, window reopening, case-insensitive matching with exact-then-substring precedence, and the precise success/error reply contract including ambiguous-name candidate listing and unconfirmed activation. This is exactly the behavioral detail an agent needs before invoking a state-changing 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?

  Two dense sentences, front-loaded with the action and matching/return semantics, with the error enumeration deferred to the end. No sentence is filler; every clause conveys a distinct behavior or constraint.

  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 one required parameter, an output schema, and no annotations, and the description covers activation behavior, matching rules, and the reply contract. Nothing an agent needs in order to call it correctly is missing.

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

  Parameters5/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, and it does: it explains that app_name is matched case-insensitively, resolved exact-first then by unique prefix or substring, and gives concrete examples ('System Settings', 'Safari', 'Telegram' → 'Telegram Lite'). This is meaning well beyond the bare string type.

  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 ('Bring an application to the front by its name') along with the side effects (launch if not running, reopen a window if none). An agent can immediately distinguish this activation tool from read-oriented siblings like observe and probe_tooltips.

  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 gives an explicit trigger condition: 'Use before observing or acting on an app you are not sure is frontmost,' which links it to the observe/act workflow. It does not name a when-not case or an alternative tool for the already-frontmost situation, so it stops short of full alternative routing.

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

• mission_replayA
  4.8/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, and it does: preflight world comparison aborts before any step runs, no re-planning or screenshots, route held against the recorded route after success with a warning on divergence, stored fingerprint deliberately left unchanged, and a failed replay fails the item. This is behavior an agent could not infer from 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.

  Conciseness4/5

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

  Front-loaded with the core action and then layered with preflight, post-run and failure semantics in roughly the order the agent needs them. It is long and occasionally editorializes ('only you can tell which'), but nearly every sentence carries real behavioral 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?

  Complete for a complex, side-effecting replay tool with no annotations and no output schema: it documents preconditions, abort behavior, route verification, fingerprint persistence, failure semantics, and what the reply contains. An agent has everything needed to call it and interpret the outcome.

  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% and neither property has a description, so the description must compensate — it does for llm_version_tag (the model driving this replay, compared against the one stored on the recipe). item_id is only implied through the surrounding references to mission_item_id=N, leaving a small naming ambiguity between the two calls.

  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?

  States a specific verb+resource: replaying the exact recorded recipe that previously succeeded for one checklist item. It explicitly distinguishes itself from re-planning and from execute_plan, which the sibling list confirms is a real alternative. An agent can tell mission_replay apart from execute_plan without opening either schema.

  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?

  Gives the condition for use (an item that passed through execute_plan(mission_item_id=N)) and names the alternatives explicitly: run deliberately via execute_plan to record a new truth, or mark the item by hand. It also tells the agent what a preflight mismatch means and that the decision is theirs.

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

• observeA
  4.8/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 delivers: it discloses the two labelled surfaces, that background-window text is deliberately excluded and untargetable, that the chrome block prints even when empty (M=0) with a reason, that off-surface text is counted but not listed, and that coordinates are pixels (elements) versus logical points (clicks). This is unusually rich 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.

  Conciseness4/5

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

  It is long and dense, but the length is justified given there is no output schema to carry the reply structure. It is front-loaded (purpose, then usage, then surfaces, then reply contents) and uses explicit labels, though a few sentences are packed with multiple clauses that slow scanning.

  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?

  No output schema exists, so the description must describe the return values, and it does so comprehensively: app name, window, open_windows, known_window, pixel vs point screen size, single_character_scan, off_surface, element format, and the attached PNG. Combined with zero parameters and no annotations, nothing an agent needs to call it correctly is missing.

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

  Parameters4/5

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

  The tool takes zero parameters, so the baseline is 4 per the rubric. The description spends its detail budget on the reply contract and targeting semantics rather than on parameters, which is the correct allocation here.

  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 first sentence gives a precise verb and resource: capture the frontmost window and return a screenshot plus a textual listing of text elements. It also clarifies scope (frontmost window, not all windows) and the two output surfaces, so an agent can distinguish it from execute_plan or focus_app without opening anything else.

  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 when-to-use guidance: 'Use this once before planning a batch of actions.' It also explains the relationship to downstream calls by defining which surface a step can search and how chrome is reached via target.scope='chrome', including the non-obvious case of a just-opened menu.

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

• probe_tooltipsA
  4.8/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 thoroughly: it moves the mouse and is the only icon tool that touches the screen, ~1.5s per icon (tens of seconds per call), pointer restored afterward, frontmost-window-only, early-stop conditions (top-left corner, stop button, window switch/move), and nothing is clicked or typed. Names are written globally across the app, which is important durable side-effect disclosure.

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

  Conciseness4/5

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

  Front-loaded with purpose and the routing decision, then caveats; every sentence adds information and the 'THIS ONE MOVES THE MOUSE' emphasis is functional. It is long and slightly dense, but there is little true waste.

  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 with meaningful side effects and an output schema, the description covers invocation, safety, timing, stopping behavior, and even the shape of the reply reports. Nothing an agent needs to call it correctly is missing.

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

  Parameters4/5

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

  Schema coverage is 0%, but the description documents the single parameter well: 'limit (default 12, max 40) caps how many icons one call visits', adding the undocumented max of 40 beyond the schema's default. Minor gap only in that no other semantics exist to explain.

  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 concrete verb+resource ('hover each unnamed icon of the FRONTMOST window and keep the tooltip it shows') and explicitly distinguishes itself from both annotate_icons ('asks you what a drawing is') and submit_icon_labels ('writes yours'). An agent can tell exactly what this tool does and how it differs from its siblings.

  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 gives explicit routing: 'try it first' on windows whose observe reply shows unlabeled icons, 'bring the app forward with focus_app first', and directs controls with no tooltip to annotate_icons. When-to-use, prerequisites, and the alternative are all stated.

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

• execute_planA
  4.9/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: escalation vs abort semantics (mouse to top-left), action budgets, scroll_to_find side effects, drag's irreversibility ('no generic undo'), the clipboard being overwritten by the user's copy, expect retries within timeout_ms default 5000, and the standing 'windows seen during this run' tail on every reply. Nothing material about behavior is left implicit.

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

  Conciseness4/5

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

  Front-loaded with the step schema and core actions, then organized into clearly headed sections (STEPS THAT MAY NOT BE THERE, GESTURES, SURFACES, OFF-SCREEN TARGETS, WORKING A MISSION). Dense and mostly earning its place, but it is very long and some points (scope/scroll side effects) recur across sections rather than being stated once.

  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 with a nested, undocumented schema and no output schema, the description covers both inputs and returns thoroughly — the journey, 'extracted (step N, window ...)' read blocks, never-truncated reads, escalation payload (failed step, screenshot, element listing, nearest texts) and the mission status block. Nothing an agent needs to call it correctly is missing.

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

  Parameters5/5

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

  Schema coverage is 0% and the schema documents nothing, so the description must compensate — and it does exhaustively: the full step object shape, each action's required fields, target/scope/window/region semantics, modifiers, until_readout watch/value/tolerance, expect fields, and the meaning of mission_item_id and llm_version_tag ('leave both out for an ordinary run').

  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?

  States a specific verb and resource up front: 'Execute a batch of semantic UI steps and return a compact journey.' The batch/plan framing (multiple steps, one journey, escalation) clearly separates it from single-action siblings like observe and focus_app.

  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?

  Gives explicit when/when-not for each sub-capability: scroll:true for 'a long page, a chat history, a log' but 'leave it off (the default) for a pane that is fully visible'; read_clipboard when an app won't show text in full; skip_if_absent only 'where both branches end on the same screen'; drag 'for what a click cannot express.' It also names the cheap alternative path (a short focus_app/click/wait plan) for exploration.

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

• recallA
  4.9/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 behavioral burden and does so thoroughly: it discloses the memory model (by-window only, chrome never remembered), freshness semantics (absolute UTC plus relative ages, STALE marking), explicit absence/coverage semantics ('N of M known control(s) ever clicked', 'not found' means 'never seen here'), size-capping behavior, and cycle handling ('[shown above]'). This is rich context an agent could not get from 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.

  Conciseness4/5

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

  The critical guidance is front-loaded in the first two sentences, and nearly every sentence carries decision-relevant information (token economics, chrome exclusion, route syntax, staleness policy). It is, however, an unusually long single block of prose for a five-parameter tool, so structure suffers even though little is pure padding.

  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?

  An output schema exists, so return values needn't be explained, yet the description still covers reply shape: timestamps, route notation in execute_plan terms, coverage footers, and truncation notices. For a high-complexity memory-lookup tool with zero annotation coverage, nothing an agent needs to call it correctly appears to be missing.

  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?

  Schema description coverage is 0%, so the description must compensate and it does: it explains the three-step widening of focus (no args = all apps, app_name = that app, app_name+window = one window), that window is a title fragment or '#id', that app_name matches exactly-then-substring, depth defaults to 1 with max 3, and what from_window does.

  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 concrete verb+resource: 'Ask what Choto already remembers about an interface, as text.' It immediately positions the tool against siblings by telling the agent to call it BEFORE observing or planning and contrasting its token cost with a screenshot, so an agent can tell it apart from observe/execute_plan without opening a schema.

  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 names when to use it ('BEFORE observing or planning'), when not to bother re-looking ('a window that has been visited before does not have to be looked at again'), and which alternatives cover the gap (target.scope='chrome' in execute_plan, or observe). It also routes the agent to a verification step when data is stale.

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