Snap this agent's own window to a corner

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 transparently lists the actions (float, pin, resize, position) and adds that it 'verifies the result' and 'targets by address' with 'no focus stealing'. This goes beyond the basic names and provides operational details. However, it does not discuss potential side effects, error handling, or permission requirements, which would make it more complete.

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 concise but its structure is somewhat disjointed. The phrase 'corner: tl=tr/bl=br or center' is cryptic and appears to be a shorthand that may confuse agents (e.g., 'tr/bl' suggests a range rather than a list). While it front-loads the primary action, the ambiguous notation and abrupt shift to behavioral notes reduce clarity. It is not bloated, but it could be better organized.

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 with 5 parameters and no output schema, the description is incomplete. It explains the overall workflow but does not cover defaults (e.g., width 1300, height 900, margin 0), the meaning of 'verify the result', or what happens if the target window cannot be found. Given the complexity and the need to guide an agent on successful invocation, this level of detail is insufficient.

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 description coverage is 40%, with only 'pin' and 'corner' having descriptions; width, height, and margin are undocumented. The description repeats corner values ('tl=tr/bl=br or center') but adds little beyond the schema. It mentions resizing but does not explain the dimensions or margin behavior, leaving these parameters under-specified even though the description should compensate for the low schema coverage.

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: to float, pin, resize, and position the agent's own host window to a corner of a monitor. It explicitly identifies the resource as 'OUR OWN host window (found via PID lock)', distinguishing it from general window snapping. The verb sequence and resource make the tool's function unambiguous.

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 implies usage by focusing on 'OUR OWN host window', but it does not explicitly state when to use this tool versus alternatives like 'window_snap' or other layout tools. No direct comparison or exclusion is provided. While the context signals the intended use case, explicit guidance on when not to use it or when a sibling tool would be preferable is missing.

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