Skip to main content
Glama

Computer Type

computer_type

Types text into the focused control via clipboard paste, supports Arabic-safe input, and requires a fresh consent file before sending text to the active app.

Instructions

Type text into the focused control via clipboard paste (Arabic-safe). Outbound gate: requires fresh CONSENT.txt (ALLOW line, <10 min old) — typing sends text into an app the user may not see being typed into.

Input Schema

NameRequiredDescriptionDefault
textYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the clipboard-paste mechanism, the Arabic-safe intent, a hard consent-file gate with a 10-minute freshness window, and the risk that text lands in an app the user cannot see. It omits failure behavior (what happens when consent is stale) and whether the system clipboard is clobbered as a side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, the operation and mechanism first, then the gate and the reason behind it. No filler and nothing important buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the description covers the remaining essentials for a single-parameter input tool: mechanism, encoding caveat, consent prerequisite, and the blind-typing hazard. What an agent needs to call this correctly is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single parameter has no description in the schema, so the description must compensate. It does reasonably: 'text' is clearly the string to be typed, and the 'Arabic-safe' note signals that non-Latin/mixed-direction content is supported and passes through clipboard paste rather than simulated keystrokes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('type text') plus the target ('the focused control') and the mechanism ('via clipboard paste'), which implicitly separates it from sibling computer_key (keystroke-level input) and computer_clipboard (clipboard manipulation). An agent can tell what this does and roughly how it differs from the other input tools without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete precondition ('requires fresh CONSENT.txt with an ALLOW line, <10 min old') and a rationale for caution, so the agent knows when it may call it. It does not explicitly route to alternatives (e.g. use computer_key for shortcuts/hotkeys, computer_clipboard + key combo for paste), which keeps it below a 5.

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