pty_write

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that enter:true appends the Enter key — but says nothing about whether the write blocks, whether it can fail if the PTY is dead, or how it interacts with pty_read buffering.

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?

Two terse sentences, front-loaded with the action and followed by the one non-obvious parameter behavior. Nothing is wasted, though the brevity is partly a symptom of under-specification rather than discipline.

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, non-idempotent 3-parameter tool with no output schema and zero schema coverage, the description is thin. It omits the lifecycle dependency on pty_start, the meaning of 'id', and how the caller observes the effect — the agent is left to guess at the basic usage loop.

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 carries the full burden. It explains only the optional 'enter' flag; the required 'id' (presumably a PTY session identifier) and 'data' (payload semantics, encoding, newline handling) are entirely undocumented in both schema and description.

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 ('Write to an interactive PTY'), which clearly separates it from pty_read, pty_start, and pty_stop. It does not, however, clarify what 'id' refers to or how this differs from process_input, so differentiation from the broader process family is left implicit.

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 versus pty_read, process_input, or browser_type. The description never states that a PTY must already exist (via pty_start) or that output must be retrieved with pty_read, both of which an agent needs to invoke this correctly.

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