app_key

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

With no annotations, the description carries the full behavioral burden. It discloses the action, supported special keys, modifier combinations, and case-insensitive partial title matching. It does not mention focus requirements, window-not-found behavior, or whether the window is activated first, which are meaningful for a window automation tool.

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 well-structured and front-loaded: purpose first, then supported inputs, then parameter details. Every line adds useful information, with no filler or repetition of schema fields.

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 simple two-parameter tool with an output schema, the description covers the platform, key formats, modifier syntax, and window title matching semantics. It is largely complete, though it could improve by noting what happens if no matching window is found or if multiple windows match.

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 0%, but the description fully compensates by explaining both parameters: window_title supports full or partial case-insensitive titles, and key accepts named keys or modifier combinations with concrete examples like 'enter', 'ctrl+a', and 'f5'. This adds substantial meaning beyond the bare string 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 clearly states the tool sends a key or keyboard shortcut to a Windows application window, using a specific verb and resource. It distinguishes itself from Android-targeted siblings like adb_key by specifying Windows, but does not explicitly differentiate from app_type or app_click.

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 gives useful context that this targets Windows application windows and lists supported special keys and modifier combinations. However, it does not explicitly state when to use this tool instead of related siblings such as app_type or adb_key, so usage guidance is implied rather than explicit.

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