terminal_send

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

No annotations are provided, so the description alone must disclose behavioral traits. It mentions keystokes and named sessions, but does not say that input is sent without reading output, whether failed sends produce errors, or what side effects occur. For a tool that can execute commands, this lack of behavioral disclosure is a material gap.

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 short and front-loaded, stating the action first and use cases second. Every sentence earns some place, but the 'or send signals' clause is redundant with the sibling terminal_send_signal and introduces ambiguity, so it is not perfectly tight.

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 is simple and has a fully documented schema, but there is no output schema and no annotations. The description does not clarify how to coordinate with terminal_read, how to handle the default Enter behavior in practice, or how sending signals via this tool differs from terminal_send_signal. It is adequate but not complete.

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?

Input schema coverage is 100%, so each parameter is already described in the schema. The description adds some semantic context by mentioning typing commands and answering prompts, which helps clarify the `input` parameter, but it does not add significant meaning beyond the schema.

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 uses a specific verb-resource pair: 'Send input (keystrokes) to a named terminal session.' It clearly conveys the core action and distinguishes the tool from read, spawn, close, and resize siblings. However, the phrase 'or send signals' blurs the boundary with the sibling tool terminal_send_signal, preventing a full 5.

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 offers use cases such as typing commands, answering prompts, or sending signals, which gives an agent some context for when to invoke it. It does not explicitly state when to choose terminal_send_signal instead, despite that sibling existing, so the guidance is incomplete and slightly misleading.

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