launch_app

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

With no annotations provided, the description carries the behavioral burden. It discloses two key behaviors: the MCP bridge is injected and the tool waits until UI readiness before returning. This is meaningful beyond what the name alone conveys. However, it does not mention process lifecycle details such as whether the app runs in the background, what happens on timeout (schema covers timeout but not the failure mode), or port conflict behavior.

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

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

The description is a single, front-loaded sentence. It states the action, the target, the key injection detail, and the completion condition with zero filler. Every word earns its place.

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

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

Given the rich input schema, the presence of an output schema, and the sibling tools context, the description is largely sufficient. It covers the essential launch-and-wait behavior. It could add a brief note about when not to use it or how it relates to wait_until_ready, but that gap is more about usage guidelines than completeness for a launch operation.

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

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 itself adds no parameter information, but the input schema provides rich details for every parameter including cwd, script, timeout, and app_args. The description's lack of param info is acceptable because the schema already does the heavy lifting.

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

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

The description uses a specific verb ('Launch') with a clear resource ('pywebview app') and adds meaningful qualifiers ('with MCP bridge injected, then wait until the UI is ready'). It clearly distinguishes launch_app from sibling tools like wait_until_ready, get_app_status, and stop_app, which perform different lifecycle phases.

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

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

The description implies that launch_app is the entry point to start the app and includes a readiness wait, but it does not explicitly state when to use this tool versus alternatives. For example, it doesn't mention that wait_until_ready may be redundant after launch_app or what to do if the app is already running. The context is clear but exclusions and alternatives are not addressed.

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