Type text into the currently focused input, supporting Unicode and multiline content with automatic clipboard fallback. Typed content is not logged.
Type text at the currently focused input. Handles Unicode and multiline text (clipboard fallback used automatically). The typed content is never logged.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| verify | No |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does well by disclosing Unicode/multiline support, automatic clipboard fallback, and that typed content is never logged. These are non-obvious behavioral details not inferable from the schema, though the behavior of the verify parameter and failure modes remain 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?
Two sentences with no wasted words: the core action is front-loaded, and the supporting behavioral facts are packed efficiently. Every sentence earns its place without repeating schema information.
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 description covers the core typing semantics well, but it omits the verify parameter and does not state what happens when no input is focused or whether the tool will attempt to focus one itself. Given the sibling context (click, focus_window), an agent can infer prerequisites, but the description alone is not fully self-sufficient.
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 needed to compensate and clarify both parameters. It adds useful meaning for 'text' by describing Unicode/multiline support and no-logging, but it says nothing about the 'verify' parameter, leaving its meaning and effect completely opaque to the agent.
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 action ('Type text') and the target ('at the currently focused input'), and emphasizes Unicode/multiline handling, which distinguishes it from sibling key-press tools like computer.press and computer.hotkey. This is a specific, non-tautological definition that an agent can understand immediately.
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 phrase 'currently focused input' establishes the precondition that an input must already be focused, and the Unicode/multiline support signals when this tool is preferable for text entry. It does not explicitly name alternatives or exclusion cases, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.