send_chat

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

No annotations are provided, so the description carries full behavioral disclosure burden. It describes GUI automation steps (focus, open, paste, submit), implying it interacts with a desktop application, but doesn't disclose side effects (e.g., does the message persist in the input box if send=false? Does it overwrite the current draft?), timing/speed, or whether it can fail verification steps. The send/backend parameter behaviors are entirely unexplained.

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, reasonably short sentence and is front-loaded with the verb action. However, it compresses too much behavioral nuance into one clause and omits important clarifications about parameters, so brevity here sacrifices useful detail rather than achieving efficiency.

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?

With an output schema present but zero description coverage of parameters and no annotations, this tool is underspecified for reliable autonomous invocation. The GUI-automation nature (focus window, paste, submit) carries real risks (wrong window focus, missed steps) that aren't disclosed. Sibling overlap with open_chat and type_text further complicates correct selection. There's enough written to guess at the intent but not to execute reliably.

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 0%, so the description must compensate, but only the message content is implied by 'paste a message'. The send boolean and backend enum are completely unexplained—the agent can't know what 'backend' means functionally or what tradeoffs between pydirectinput/pyautogui/auto are. The maxLength=240 constraint on message is also not called out despite being a meaningful limit the agent should know.

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 a clear action ('Focus Sky, open chat, paste a message, and optionally submit it') with a specific resource (Sky chat) and verb sequence. However, it's somewhat ambiguous—'Focus Sky' implies activating a window but doesn't clearly distinguish whether this creates a new message or replies to an existing thread. Sibling tools like open_chat and type_text overlap considerably, so it's unclear what unique job this performs vs those.

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?

No guidance on when to use this vs alternatives. With siblings open_chat, type_text, press_key, and read_screen, the description doesn't clarify whether this is a combined convenience tool, when one would prefer it over calling open_chat + type_text individually, or any prerequisites (e.g., must a chat be already open?). The 'optionally submit it' phrasing hints at the send=false behavior but no explicit guidance is given.

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