kde_input_key

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

Annotations already declare openWorldHint=true and destructiveHint=true, so the risk profile is partly covered. The description adds a genuinely useful behavioral fact beyond them: no implicit window activation occurs, so the keystroke lands wherever focus currently is. It still omits failure behavior (window id invalid or unfocused), whether input is queued or synchronous, and why key input is destructive.

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?

A single front-loaded sentence with the action first and the crucial constraint second; nothing is padded. The only redundancy is that "no implicit activation" restates part of "already-active," but the emphasis is arguably deliberate.

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 destructive, open-world input-injection tool with no output schema and undocumented chord syntax, the description is too thin. An agent can tell roughly what happens but not how to format the chord, where the window id comes from, or what occurs when the target isn't focused.

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 only 33% – only `session` carries a description – yet the description adds no parameter meaning at all. The most consequential gap is `chord`: its syntax (modifier+key format, max 128 chars) is undocumented in both schema and description, and `window_id`'s provenance (presumably from kde_window_list/find) is unexplained.

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?

States a specific verb+resource ("Send a key chord") and the object ("an already-active target window"), which separates it from a text-typing sibling like kde_input_type and from activation tools. It doesn't name the sibling it pairs with, so the differentiation is implied rather than explicit.

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 phrase "already-active target window; no implicit activation" implies the caller must first bring the window to the foreground (likely via kde_window_activate), which is useful implied guidance. However, it never states that prerequisite as a rule, gives no alternative for typing text versus pressing keys, and doesn't say what to do if the window is not focused.

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