Skip to main content
Glama
Sign In
computer-agent-labs

terminal-use

by computer-agent-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Type into terminal

terminal_type
Destructive

Types literal characters into a terminal session as human-like keystrokes and sends Enter for embedded newlines, then waits briefly for the buffer to settle; use terminal_wait for slow commands.

Instructions

Type literal characters into the terminal as if a human were pressing keys. Embedded \n is normalized to \r so "git push\n" actually submits. Always waits for the buffer to settle (or to time out) before returning. The wait is capped at 10s; for anything slower (builds, installs, test runs) follow up with terminal_wait, which blocks until the command actually finishes.

Input Schema

NameRequiredDescriptionDefault
textYesCharacters to type. Embedded \n becomes Enter.
pasteNoDeliver the text as a single paste instead of keystrokes. Use it for multi-line text going into an editor, a REPL or a shell prompt: programs that support bracketed paste insert it verbatim (no auto-indent, lines are not run one by one), and nothing is submitted until you press Enter. Programs that do not support it receive the plain characters. Default false.
idleMsNoSettle window: silence this long after the last byte counts as settled. Default 200.
maxWaitMsNoOverall cap on the settle wait. Default 5000, clamped to 10000. Use terminal_wait for longer.
sessionIdYesNumeric id of the session to target. Get one by calling terminal_create. Use terminal_list to enumerate currently-known ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the newline normalization quirk (\n -> \r, with a worked example), the settle-wait blocking behavior, and the hard 10s cap on the wait. These are exactly the traits an agent needs to avoid mis-timing follow-up calls, and none of them appear in the structured fields.

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?

Four sentences, front-loaded with the core action, then the normalization rule, then the blocking semantics, then the escape hatch. No filler and nothing buried.

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

Completeness4/5

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

With no output schema and a destructive, non-idempotent annotation profile, the description covers the key behavioral risks (blocking, timeout, follow-up tool). It stops short of saying what the call actually returns (settled buffer output vs. nothing), which is a minor remaining gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents text, paste, idleMs, maxWaitMs and sessionId. The description only adds the \r-vs-Enter nuance for `text` and reinforces the wait cap; it does not expand meaning on paste, idleMs or sessionId. Baseline 3 is appropriate.

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 and resource ('Type literal characters into the terminal') and immediately scopes it against the alternative keystroke/settle behavior, naming terminal_wait as the escalation path. An agent can distinguish it from terminal_press and terminal_batch from the text alone.

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?

Gives clear when-to-use context for the slow-command case ('for anything slower (builds, installs, test runs) follow up with terminal_wait') and for paste mode (multi-line into editor/REPL/shell). It does not state when NOT to use it versus siblings like terminal_press or terminal_batch, so it stops short of explicit exclusions.

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

Deploy Server

Other Tools