Skip to main content
Glama

tv_launch

Launch a discovered Android or Google TV app by package and confirm whether it appears in the foreground.

Instructions

Launch a discovered package's resolved activity and report whether its foreground was observed.

Input Schema

NameRequiredDescriptionDefault
packageYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world mutation. The description adds that it reports whether the foreground was observed, which is useful outcome context beyond the annotations, but it does not say whether the call blocks, what happens if the package is missing, or what a negative observation means.

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 well-formed sentence that front-loads the action and its scoping condition. 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 one-parameter tool with full annotations and an output schema, this covers the essentials: what it launches, where the package comes from, and the observation result. Only edge-case behavior (failure, timing) is left unaddressed.

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?

With one parameter at 0% schema description coverage, the description does the work of implying 'package' is an identifier of an already-discovered package and that no activity name is needed. It still gives no format or example for the package string, so the meaning added is partial.

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?

States a specific verb ('Launch') and resource ('a discovered package's resolved activity'), and clarifies that the activity is resolved from the package rather than supplied separately. It is distinguishable from tv_navigate and tv_playback, though it does not name those siblings explicitly.

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 word 'discovered' implies the package must first come from tv_packages, giving an implicit prerequisite ordering. There is no explicit when-to-use vs tv_navigate/tv_playback guidance and no statement of failure conditions.

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