GenOffice app open file

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

The description discloses key behaviors: it launches the app normally via macOS open, registers certain document types, doesn't need CDP. Since there are no annotations, this carries the transparency burden. It covers the launch mechanism and platform constraint but doesn't mention what happens if the file is already open, error behavior, or whether it returns any status. Adequate but 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.

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

Three sentences, each carrying value: what it does, the CDP note, and platform constraint. Efficient and front-loaded with the verb+object. Slightly verbose with the parenthetical about registered document types, but overall no waste.

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?

For a single-parameter launch tool with full schema coverage, the description covers the essential context: mechanism, platform, no-CDP requirement, and supported file types. It doesn't explain return behavior or error cases, but for a straightforward launch action this is reasonably complete relative to complexity.

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% with a single 'path' parameter already well-described as 'Absolute path to the file to open'. The description reinforces that the file types are Office/PDF set. Baseline 3 is appropriate since the schema fully documents the parameter and the description adds marginal context about file type compatibility.

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?

Specific verb+resource: 'Open an Office/PDF file... via the macOS open command'. It specifies the exact file types (.docx/.xlsx/.pptx/.pdf) and mechanism (macOS open command). The purpose clearly distinguishes it from sibling tools like genoffice_extract_text or genoffice_docx_patch, which operate on file content rather than launching the app.

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?

States when to use it: to open a file in the desktop app. It explicitly notes the app doesn't need CDP running and is macOS only, providing clear context. However, it doesn't explicitly say when NOT to use it or name alternative tools (e.g., when to prefer genoffice_extract_text for content operations). The context is clear but exclusions are missing.

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