Server Quality Checklist

Tool Scores

• gtv_set_deviceA
  3.6/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. Does not disclose behavioral traits beyond the basic selection action, such as whether it overwrites a previous device, requires prior pairing, or echoes any confirmation. Minimal 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?

  Single sentence, no superfluous words. Clearly front-loaded with the action and resource. 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 context-setting tool with one parameter and no output schema, the description is largely complete. It could mention that the device must be paired and that subsequent commands will use this selection, but overall it suffices for basic usage.

  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 100% for the single parameter, so baseline is 3. Description adds an example ('e.g. 192.168.1.42') but largely restates the schema description ('Device host (IP) or name'). No significant additional meaning.

  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?

  Clearly states the action (select), resource (paired device), and method (by host or name). Distinguishes from sibling tools like gtv_list_devices (listing) and gtv_send_key (sending keys) by specifying that it sets a target for subsequent commands.

  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?

  Implies when to use (before other commands that need a target), but lacks explicit guidance on when not to use or alternatives. For example, if a command already accepts a device parameter, this tool might be unnecessary, but no such context is provided.

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

• gtv_launch_appA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must compensate. It minimally describes the input format but omits behaviors like error handling (e.g., what if app not found?), permissions, or side effects (e.g., does it change focus?). For an action tool, this lack of behavioral detail impairs correct invocation.

  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?

  Single sentence with clear structure: action, target, input format. No unnecessary words, front-loads the core functionality.

  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?

  Given the simple interface (one required parameter, no output schema), the description covers the input and action adequately. However, it lacks details on expected outcomes, error states, or device requirements, leaving gaps in completeness for an agent to handle edge cases.

  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 100%, baseline is 3. The tool description adds examples (netflix, youtube) and clarifies the dual nature (catalog name vs. deep-link URI), which adds meaningful context beyond the schema field description. However, it does not introduce new parameter details.

  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: 'Launch an app on the current device'. It specifies input types with examples (catalog name/id like netflix, or deep-link URI), and the purpose is distinct from sibling tools which handle device listing, key sending, device setting, and text typing.

  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?

  No explicit guidance on when to use this vs siblings or prerequisites (e.g., device must be set). The implication that it works on the 'current device' hints at a precondition, but it's not spelled out. Sibling names suggest context, but no exclusions or alternatives are mentioned.

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

• gtv_send_keyA
  3.7/5.0
  Behavior2/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 mentions 'current device' but does not disclose error states, side effects, or whether the press is reliably delivered. Minimal 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.

  Conciseness5/5

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

  Single sentence, no redundant words, front-loads the core action. Every word contributes to clarity.

  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?

  Given the tool's simplicity (1 enum param, no output schema), the description is adequate but lacks information about return value, error handling, or device state requirements. Could be more self-contained.

  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% with enum values and a brief description. The description adds value by grouping keys into categories (navigation, media, volume, power), enriching the meaning beyond the raw list.

  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 verb 'send' and resource 'remote key press', specifying the scope to the current device and listing key categories (navigation, media, volume, power). It distinguishes from sibling tools like gtv_type_text and gtv_launch_app.

  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 remote key press is needed) but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it.

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

• gtv_type_textA
  4/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 IME method and lack of keycode mapping, but does not specify behavior when no field is focused, supported character sets, or potential side effects. It adds moderate behavioral context but lacks completeness.

  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, concise sentence that front-loads the essential information (action, target, method). 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.

  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 (one parameter, no output schema) and lack of annotations, the description adequately covers the tool's purpose and behavior. It does not mention error handling or fallbacks, but for a straightforward text input tool, it is sufficiently 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% coverage for the single 'text' parameter, already describing it as 'Text to type into the focused field'. The description adds no extra parameter-specific meaning beyond the schema, so baseline 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 action ('Type arbitrary text'), the target ('into the focused field'), and the method ('via IME'). It also distinguishes from sibling tool 'gtv_send_key' by noting 'no keycode mapping', making the purpose precise and unique.

  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 (for direct text input) versus alternatives like gtv_send_key (for key presses). It does not explicitly state exclusions or name the sibling, but the context is clear enough for an agent to differentiate.

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

• gtv_list_devicesA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description clearly states it lists devices and marks the current one, implying a read-only operation. No hidden side effects mentioned; however, no disclosure of potential timeouts or network requirements, but suitable for a simple list.

  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?

  A single sentence that is front-loaded and contains no extraneous information. Every word earns its place.

  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 zero parameters, no output schema, and a simple operation, the description fully informs the agent. No additional information is necessary for correct invocation.

  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?

  No parameters exist, so baseline is 4. The description adds meaning beyond schema by explaining the tool's function (list + mark current device), which is helpful for an agent even with zero params.

  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 specific verbs ('List') and resource ('Google TV devices already paired via the gtv CLI'), and distinguishes from siblings (other gtv tools like launch, send key, set device, type text). It also adds a unique behavior: marking the current device.

  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?

  No explicit guidance on when to use versus alternatives, but for a zero-parameter listing tool, the context of sibling tools (e.g., gtv_set_device) implies this is for viewing paired devices before selecting one. The minimal guidance is adequate given simplicity.

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