GenOffice app launch (CDP)

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

With no annotations provided, the description carries the full disclosure burden, and it delivers: it reveals that a non-CDP running instance is terminated first ('single-instance lock would otherwise swallow the relaunch'), that killExisting controls this destructive behavior, that auto-updater relaunches are handled via retry-until-port-answers, and platform-specific launch mechanics. This is rich, honest behavioral disclosure beyond what any annotation would provide.

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 dense and front-loaded with purpose, then covers the critical destructive behavior, the retry logic, and platform details—all in four sentences with zero wasted words. Slightly longer than strictly necessary, but every clause earns its place given the nuanced CDP/auto-updater/kill behavior it must convey. Minor deduction for the parenthetical redundancy on killExisting.

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 tool's single boolean parameter, the absence of an output schema, and complex runtime behavior (CDP port, single-instance lock, auto-updater relaunch), the description covers all essential facets: what happens on launch, when termination occurs, how the retry loop works, and platform differences. An agent would have everything needed to invoke this tool correctly and predict its side effects.

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 coverage is 100% and the single parameter (killExisting) has a descriptive schema entry ('Kill a running instance without CDP first (default true)'). The description reinforces this by mentioning killExisting=false as an abort option. There's a slight duplication of schema info in the description, but the description adds context on WHY this matters (single-instance lock swallowing relaunch), providing marginal value on top of the schema.

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+resource ('Launch the installed GenOffice app with the CDP debug port open') and clearly states its purpose—enabling the agent to drive the app via screenshots and DOM evaluation. It distinguishes itself from sibling tools by being the sole launch tool; siblings like genoffice_app_screenshot and genoffice_app_eval assume the app is already running, while genoffice_app_status checks state.

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 explicitly explains when to use it (to start the app so it can be driven) and key behavioral context: if the app runs without CDP, it's terminated, with killExisting=false as an escape hatch. It also covers platform differences (macOS `open -a` vs binary launch). While it doesn't name alternative sibling tools explicitly, the context makes the use case unambiguous.

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