window_post

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

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that 'uia' routing focuses the window, which is a key side effect. It also implies background operation, but it does not explain what 'background' means in terms of window visibility or input capture, nor does it describe side effects for actions like click or scroll. The behavior is partially transparent but lacks detail on edge cases or requirements.

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 a single, compact paragraph that front-loads the core purpose and then lists the key enums. It uses a clear 'action: ...' and 'mode: ...' format, and the note about uia routing is placed at the end as an important caveat. The structure is logical and efficient, with no filler.

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?

The tool has 8 parameters, 2 required, and an output schema exists, but the description is insufficient for an agent to use it correctly. It omits parameter meanings, prerequisites (e.g., whether the window must be visible or minimized), and concrete examples. The note about uia routing is helpful but not enough. While the output schema may describe return values, the input side is under-specified.

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 schema description coverage is 0%, so the description must compensate for the 8 parameters. It explains the 'action' and 'mode' enums, but leaves x, y, key, keys, text, and hwnd entirely unexplained. For instance, x and y are likely coordinates for click/scroll, and key/keys/text are input payloads, but the description provides no such meaning. This is a significant gap that forces the agent to guess or inspect the schema further.

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's purpose: 'Send input to a window in the background.' It lists the supported action types (type, key, hotkey, click, scroll), giving a concrete sense of what the tool does. However, it does not explicitly differentiate itself from sibling tools like mouse, keyboard, or focus_window, so an agent must infer that this is specifically for targeting a window handle (hwnd) rather than global input.

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 provides some usage guidance by explaining mode options and recommending 'auto' for WinUI/UWP apps, and notes that 'uia' routing forces focus. However, it does not explicitly state when to use this tool versus alternatives like mouse or keyboard, nor does it clarify the trade-offs between background and focused modes beyond the note. The guidance is partial, leaving the agent to infer the appropriate context.

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