ui_send_keys_focused

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

The annotations only include openWorldHint: false, so the description carries the burden of explaining behavior. It does so well by detailing key syntax, modifiers, and special keys. It explains that modifiers are prefix characters and gives examples. No contradictions with annotations. However, it does not mention potential side effects like state changes or whether the key sending is synchronous, which keeps it from a perfect score.

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 moderately long but well-structured, with a clear workflow section and a detailed key reference. Every sentence adds value, though the key syntax section could be slightly more compact. Still, it is efficient and front-loaded with the core usage instruction.

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 tool that sends keyboard input to a focused element, the description covers everything needed: when to use (after ui_set_focus), the key syntax comprehensively, and an example workflow. No output schema exists, but the tool's return is implicit (performs action). The description is complete given the tool's 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?

The input schema has one parameter 'keys' with no description (0% coverage). The description compensates fully by providing an extensive key syntax guide, including modifier prefixes (^%=Ctrl/Alt/Shift), special keys in braces, and examples. This adds essential meaning that the schema alone lacks.

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 states 'Send keyboard input to the currently focused element,' clearly identifying the verb 'send' and resource 'keyboard input.' It distinguishes from sibling tools like ui_send_keys by emphasizing that it targets the currently focused element and should be used after ui_set_focus, which avoids re-searching for elements.

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 instructs to use this tool after ui_set_focus to avoid re-searching for complex elements that may timeout. It provides a workflow with steps and examples. While it doesn't explicitly state when not to use it, the context implies it is for cases where focus has already been set, which is sufficient.

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