Server Quality Checklist

Tool Scores

• tv_menuA
  4/5.0
  Behavior3/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 a key limitation about the menu block requirement and suggests a non-destructive focus action. However, it does not mention that by default it also presses ENTER after focusing (via the `select` parameter), nor does it describe potential side effects or failure modes. It adds some context but is not rich.

  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 long, starting with the primary action and then covering the optional mode and prerequisite. Every sentence is informative and there is no filler or 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?

  For a tool with four optional parameters fully described in the schema and no output schema, the description provides enough context about the purpose, the optional modes, and the necessary app profile prerequisite. It could mention more about the use of the `menu` key or behavior when no menu block exists, but overall it is adequately complete.

  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 input schema has 100% parameter description coverage; each of the four parameters already has a meaningful explanation. The description adds no new parameter semantics beyond what is in the schema, so the baseline score of 3 is appropriate.

  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 with a specific verb and resource: 'Move focus into the app's main menu and pick a section by name.' It also explains the alternate use case (omitting `item` to just open the menu and list sections), and this distinguishes it from siblings like tv_press or tv_goto which are more generic navigation 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 provides clear context for when to use the tool (to interact with an app's main menu) and an explicit prerequisite: 'Requires a `menu` block in the app profile (apps/<app>.json)'. It also discloses a limitation ('the MCP itself knows nothing about any particular app's markup'). It does not explicitly name alternatives or exclusions, but the context is sufficient.

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

• tv_wait_forA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full behavioral burden. It explains stableMs semantics, the rationale about half-rendered frames, and the return value. However, it does not mention that waiting is bounded by timeoutMs or what happens on timeout, leaving a meaningful gap for an agent.

  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 short sentences, front-loaded with the purpose, and every sentence adds useful information. 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?

  For a tool with 11 optional parameters and no output schema, the description ties together the core behavior, the stability requirement, and the return format. It lacks timeout/error semantics, but the schema documents timeoutMs and defaults, making this fairly complete.

  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 already documents all 11 parameters with 100% coverage, so by the rubric the baseline is 3. The description adds the stableMs rationale and the 'exactly one condition' rule, but it does not provide substantial additional parameter-level meaning 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 a specific verb and resource: 'Wait until a condition holds, instead of sleeping.' It also distinguishes the tool from siblings by emphasizing conditional waiting rather than state inspection, and it notes the return value. This is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description gives clear context for when to use the tool ('instead of sleeping') and an important constraint ('Give exactly one condition'). However, it does not explicitly name alternative tools or define when-not-to-use scenarios beyond contrasting with sleeping.

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

• tv_consoleA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description discloses key behavioral details: it buffers since launch, includes uncaught exceptions and failed network requests, and reports dropped ring buffer entries. It does not mention return structure or pagination, but provides substantial behavioral context beyond trivial 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 a single sentence that front-loads the purpose, then adds filtering capability and output behavior. Every clause contributes meaningful information with 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?

  The description explains what data is buffered and mentions the dropped entry count, which is useful given there is no output schema. It does not fully describe the return format, but the tool is relatively simple and the schema covers parameters, so the description is adequately complete.

  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 100%, and the input schema already describes each parameter (limit, device, filter, levels). The description only summarizes 'filter by substring and/or level' without adding new semantic meaning, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool retrieves buffered console output, uncaught exceptions, and failed network requests. It specifies the resource (console/network logs) and the action (buffered since launch, filterable). This distinguishes it from sibling tools like tv_screenshot or tv_state.

  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: logs are buffered since launch, so the tool is for historical console data. It mentions filtering by substring and level, which tells the agent how to narrow results. However, it does not explicitly state when not to use this tool or point to alternatives.

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

• tv_gotoA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well: it discloses safety bounds (maxSteps, deadline) and two specific structural stop conditions (focus not moving, focus wrapping to a previously visited position). It does not describe failure/return semantics, which is a minor gap, but the core runtime behavior is 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?

  Three tight sentences: the first states purpose, the second lists stopping safeguards, and the third gives usage guidance. No filler, information is front-loaded, and every sentence 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?

  The tool has 7 parameters and no output schema, but the description plus schema explain what the tool does, how it stops, and when to use it. The only notable gap is lack of explicit return/failure behavior, but the core navigation semantics are well covered.

  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 already provides 100% parameter coverage with meaningful descriptions (target types, defaults, allowed directions). The description adds contextual use information but no new parameter-level semantics, so the baseline score of 3 is appropriate.

  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 action: pressing a direction repeatedly until the focused element matches a target (text/CSS selector/testid). It distinguishes itself from sibling tv_press by emphasizing repeated conditional navigation rather than a single fixed press, and the 'use this instead' phrasing makes its unique role obvious.

  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 recommends using this tool instead of guessing a fixed number of presses, which is actionable guidance for when to choose it. It does not enumerate all alternative sibling tools or explicit when-not cases, but the context is clear enough for an agent to make a reasonable choice.

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

• tv_stateA
  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 transparency burden. It explicitly discloses that the tool is read-only and returns a structured snapshot with specific fields. This is useful behavioral context beyond what the schema provides, though it does not discuss error conditions or prerequisites like whether the app must be running.

  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 long and front-loaded: the first sentence lists the snapshot contents, the second clarifies read-only usage. No filler words or redundant information; every phrase contributes meaning.

  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 has no output schema, so the description's enumeration of returned fields (url, title, visible scenes, focused element, popups, counts) provides essential return-value information. It is complete for a simple read-only snapshot tool, though it could mention prerequisites or error scenarios for full completeness.

  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 description coverage is 100% for the single optional 'device' parameter, so the schema fully explains it. The description adds no parameter-specific information, but the baseline of 3 is appropriate because the schema already documents the parameter adequately.

  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 ('snapshot') and resource ('the app'), and enumerates exact contents (url, title, visible scenes, focused element, popups, counts). It clearly distinguishes from sibling tv_video_state by focusing on app state, and the read-only qualifier further differentiates it from mutation 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 provides clear usage context: 'use it to assert a step without pressing anything.' This tells the agent when to use it (for assertions) and when not (when interaction is needed). However, it does not explicitly name alternative tools or provide exclusion scenarios, so it falls slightly 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.

• tv_video_stateA
  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 disclosure. It explains the sampling behavior (two samples to determine if currentTime is advancing) and lists the return fields. It does not mention prerequisites (e.g., a video element must exist) or failure modes, but covers the core behavior well.

  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 a single, front-loaded sentence that packs all essential information without waste. Every phrase contributes: the resource, the output fields, and the use case.

  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 there is no output schema, the description compensates by listing the return fields. It also explains the two-sample methodology. It lacks a bit of detail on return value structure or edge cases, but for a simple snapshot tool with 2 optional params, it is largely complete.

  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 100%, so the baseline is 3. The description mentions 'two samples' which relates to sampleGapMs, but does not add meaningful detail beyond what the schema already provides for device and sampleGapMs.

  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 ('snapshot') and resource ('<video>') and clearly lists the exact fields returned (currentTime advancing, readyState, size, muted, src, MediaError code). It distinguishes itself from sibling tools like tv_screenshot by positioning itself as the reliable way to confirm playback when a screenshot would be black.

  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 provides a clear use case: confirming playback when a screenshot would be black. This implies when to use it over tv_screenshot, though it does not explicitly name alternatives or state when not to use it. The guidance is present but not exhaustive.

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

• tv_devicesA
  4.4/5.0
  Behavior4/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 explicitly states that the tool lists devices and their reachability/operations, implying a read-only inventory behavior with no side effects. This is transparent and sufficient for a list tool, though it doesn't explicitly state 'read-only'.

  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 extremely concise, using two short sentences. The first front-loads the verb and resource, and the second adds directional guidance ('Start here') without wasted words. Every sentence 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 list tool with no parameters and no output schema, the description adequately covers what it does and how it fits into the broader toolset. It states the output content and positions itself as the starting point. While it doesn't detail return format, that's not necessary for a list operation.

  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 has zero parameters, so the schema fully covers the input side (empty object). The description adds meaning beyond the schema by explaining what will be listed, which is relevant context. Given the 0-parameter baseline of 4, this is appropriately scored.

  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 identifies the tool's purpose with a specific verb ('List') and resource ('configured TVs'), and specifies the exact output content: reachability (sdb/ares) and supported operations. This distinguishes it from sibling tools that perform actions on individual TVs.

  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 phrase 'Start here to see the park' provides clear contextual guidance that this is the entry point for discovering available TVs and their capabilities. While it doesn't explicitly mention alternatives or exclusions, the instruction to start here implicitly tells the agent to use this tool before engaging with device-specific operations.

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

• tv_evaluateA
  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. It discloses the arbitrary JavaScript execution nature and 'escape hatch' status, indicating a powerful and potentially side-effectful operation. It also adds the ES5 compatibility constraint for old TVs, which affects how expressions must be written.

  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 concise sentences front-loaded with the primary function, followed by use cases and a constraint. It contains no filler and every sentence contributes necessary 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 tool is complex (arbitrary code execution) with three parameters and no output schema. The description covers the main purpose, usage contexts, and an important environmental constraint, which is enough for an agent to select and invoke it correctly. It doesn't detail error behavior, but that is not critical for selection.

  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 100%, so the baseline is 3. The description adds value by noting the ES5 constraint for the expression parameter and giving concrete use cases (e.g., localStorage restoration) that clarify expected expression semantics, going beyond the bare schema descriptions.

  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 runs arbitrary JavaScript in the app page and returns the value, positioning it as an 'escape hatch.' This verb+resource+output structure distinguishes it from sibling tools like tv_state or tv_console, which focus on other actions.

  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 lists use cases: 'custom assertions, reading app state, or restoring localStorage after a debug relaunch.' It frames the tool as an escape hatch, implying use when standard tools don't suffice, though it doesn't name specific alternatives or exclusions.

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

• tv_installA
  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 safety burden. It discloses the mutating nature of install, the file type requirements, and the conditional uninstall behavior with a specific reason ('Author certificate not match'). Missing details like error handling or device state are minor for this 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 sentences, front-loaded with the main action. No redundant text; every phrase carries meaningful information or a practical instruction.

  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 three-parameter tool with no output schema and no annotations, the description covers the essential behavioral nuances. It could mention missing details like prerequisites (e.g., device on) but the schema and description together are sufficient for basic usage.

  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 100%, so parameters are already documented. The description adds value by explaining when to set uninstallFirst (different certificate case) and reinforcing the absolute path requirement, going 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 starts with a specific verb and resource: 'Install an app package on a TV', and further distinguishes platforms (.wgt for Tizen, .ipk for webOS). This clearly differentiates the tool from siblings like tv_launch or tv_state.

  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 concrete usage instructions: provide an absolute path, and set uninstallFirst:true when a certificate mismatch is expected. It does not explicitly mention when not to use the tool or alternatives, but the usage context is clear enough.

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

• tv_launchA
  4.4/5.0
  Behavior4/5

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

  With no annotations to fall back on, the description covers the key side effects: the default kill-and-relaunch for a fresh start, state preservation on reload, and inspector reuse on attach. This goes well beyond the schema in explaining behavioral nuances.

  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 a tight paragraph of five sentences, front-loading the core purpose and then efficiently explaining each mode. Every sentence contributes value without 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?

  For a tool with no output schema and four optional parameters, it covers the essential behavior, the default destructive start, and the three modes. It omits details about return values or readiness signaling, but these are not critical for tool selection.

  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?

  Though schema coverage is 100%, the description adds extra meaning—e.g., 'attach' reuses the inspector and keeps the app's state, and 'reload' happens in the same process. These details are not present in the schema's parameter descriptions.

  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 identifies a specific action ('Debug-launch the app and attach over CDP') and a unique role ('Establishes the session used by all other tools'), clearly distinguishing it from sibling tools that operate after launch.

  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 explains the primary usage context (starting the session) and gives explicit guidance on when to use each mode (reload, relaunch, attach). It does not explicitly name alternatives, but the session-establishing role makes the intended order clear.

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

• tv_sequenceA
  4.4/5.0
  Behavior4/5

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

  Describes the lock behavior, step failure semantics for expect/wait, and the result format (verdict, elapsed time, result per step). This goes beyond the schema and provides useful 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?

  The description is long but information-dense, with each sentence contributing to understanding. The step examples are structured and easy to parse, though a more compact summary could reduce verbosity.

  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 complex sequence runner with no output schema, the description covers step types, failure behavior, output summary, and locking. Given the sibling tools list, it gives enough context to invoke 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?

  The schema covers device and stopOnFail clearly, and the steps parameter is thoroughly explained with concrete object shapes and semantics. The description adds substantial meaning to the steps array, while the other parameters are already self-explanatory.

  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 runs a sequence of steps in one call and produces a verdict, elapsed time, and per-step results. The detailed step format distinguishes it from the single-action sibling 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 phrase 'Run a whole case body in ONE call' implies use for multi-step scenarios instead of invoking individual tools. It also references tv_wait_for for condition semantics, giving a clear tie-in to existing alternatives.

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

• tv_screenshotA
  4.5/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. It discloses the meaningful risk that captureScreenshot can hang or return black on Samsung/Tizen due to the secure video/overlay plane, and clarifies that UI screens are generally safe. This goes well beyond a bare 'take a screenshot' statement, though it could mention error codes or recovery 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?

  Two sentences: the first states the action and output; the second delivers the crucial caveat and alternative usage. No filler, information is front-loaded and immediately actionable.

  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 no annotations and no output schema, the description is complete: it explains the primary purpose, the failure modes, the safe use cases, and points to an alternative for video playback checks. All parameters are already fully documented in the schema, so no additional param context is necessary.

  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 100%, so the baseline is 3. The description doesn't add extra detail about path, device, or timeout beyond what the schema already provides, but it confirms the tool saves a PNG and gives a sense of intended output.

  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?

  Description uses a specific verb ('Capture') and clearly identifies the resource ('app frame via CDP') and output (PNG). It also distinguishes itself from the sibling tv_video_state by advising that for playback verdicts, tv_video_state and a human glance are preferred.

  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?

  Explicitly states when to use the tool ('UI screens, menus, focus, tiles usually capture fine') and when not to ('for playback verdicts prefer tv_video_state and a human glance at the physical TV'). Names the alternative tool and provides contextual reasoning about Samsung/Tizen limitations.

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

• tv_pressA
  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 transparency burden and does so well. It discloses that durationMs causes a long-press, that repeat+intervalMs sends a burst, and that the tool returns the focused element after the press. These are valuable behavioral details beyond basic 'send a key'.

  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?

  Three concise sentences with the main action front-loaded. The key list is compact and the burst/long-press explanation is efficient. No filler or redundancy with the schema; every clause adds value.

  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 description is complete for a tool of this complexity: it covers the input format, timing behaviors, and return value. The output schema is absent, but the description explicitly states what the call returns (focused element), making the tool self-contained. Sibling tools are many, but the description's clarity prevents confusion.

  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 already describes all 5 parameters (100% coverage), so the baseline is 3. The description adds meaning by explaining the combo effect of repeat+intervalMs as a burst and giving a concrete use case ('move several tiles'). It also clarifies that durationMs 'holds' the key, reinforcing the schema's long-press semantics.

  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?

  Clear verb+resource: 'Send a remote key.' It explicitly lists supported key names and raw numeric keyCodes, distinguishing this generic key-press tool from sibling tools like tv_menu or tv_goto. The description's scope (remote key press with timing options) leaves no ambiguity about what the tool does.

  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 clear context for when to use the options: durationMs for long-press, repeat+intervalMs for bursts (e.g., moving several tiles). It doesn't explicitly name alternatives or exclusion criteria, but the description's focus on raw key presses implies it's the tool for direct input, while other tools like tv_sequence or tv_goto handle higher-level actions.

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

• tv_heapA
  4.8/5.0
  Behavior5/5

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

  No annotations exist, so the description carries the full burden. It discloses side effects (full GC, long V8 pause, can take a minute on TV), refusal while a profile runs, platform compatibility (tizen55/webos7/pc, best-effort on webOS 3), and what is deliberately NOT computed (retainer paths, retained/dominator sizes). This is exemplary transparency.

  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 description is longer than typical but every sentence carries valuable information: purpose, workflow, output, limitations, platform support, and operational constraints. It is front-loaded with the main purpose and then logically structured. It could be slightly tighter, but the density is justified for a complex tool.

  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 output schema, the description explains exactly what the return values are (Summary view numbers, diff deltas with topGrowth/topShrink). It covers prerequisites (HeapProfiler domain), edge cases (diff is pure file operation with no device needed), and performance caveats. This is complete enough for an agent to decide when and how to invoke 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 100%, so baseline is 3. The description adds workflow context (snapshot before/after, diff with two paths), clarifies the output of each action, and disambiguates the 'path' default ('Defaults to a scratch path') and 'topN' semantics. It enriches the schema's bare descriptions with meaningful usage context.

  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: 'Take a heap snapshot on the device and/or compare two of them'. It clearly distinguishes from sibling tools (e.g., tv_profile, tv_console) by focusing on heap analysis. It also explains the two actions (snapshot/diff) and their outputs.

  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 an explicit leak-hunting workflow with before/after steps, names sibling tools (tv_press/tv_menu/tv_sequence) as part of the scenario, and explicitly states when NOT to use it (refused during tv_profile recording). It also directs users to DevTools for retainer paths, covering alternatives.

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

• tv_profileA
  5/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 discloses side effects (writes a .cpuprofile file), failure behavior on unsupported platforms (metrics fails with a clear message, start/stop return metrics:null with a warning), GC side effects, and degradation of sourceMap handling. No contradictions with structured data.

  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 long but every sentence earns its place: overview front-loads the purpose, then action behavior, output format, sourceMap handling, platform caveats, and parameter advice. There is no redundancy or filler; the structure follows a logical flow from what → how → edge cases.

  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?

  With no output schema, the description fully covers return values: the top-N self-time summary, before/after/diff metrics, and the metrics:null + warning case. It also covers error modes, parameter interactions, and usage patterns, making the tool fully understandable without external references.

  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?

  Even though the schema covers 100% of parameters, the description adds substantial context beyond the schema: the action enum values are explained in narrative, path/topN/sourceMap are tied to the stop action, collectGarbage is recommended for leak hunting with a GC-pause tradeoff, and samplingIntervalUs is advised for weak devices. This exceeds the schema's basic descriptions.

  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 pair: 'Record a JS CPU profile on the device, and/or read memory & layout metrics.' It clearly distinguishes from sibling tools like tv_heap by focusing on CPU profiling and Performance metrics, and the three actions (start/stop/metrics) are precisely defined.

  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 workflow is given: 'action:"start" begins sampling, then do the thing you want to measure (tv_press / tv_goto / a scroll), then action:"stop"'. It also explains when to use the metrics action to catch growth invisible to CPU profiles, and provides platform-compatibility guidance for when metrics will fail.

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