Skip to main content
Glama
KevinBuettner

docent-terminal-mcp

expect

Script predictable terminal interactions in one call: answer matching prompts, send lines or keys, and stop on unanswered questions.

Instructions

Script predictable interactions in one call: optionally type input (+ Enter), then answer each prompt that matches a respond rule, in whatever order the prompts appear. The interactive form of yes |, echo y |, gdb's -batch and an expect script: the program gets a real terminal, and only the questions you foresaw are answered. Rules that never match are fine -- use them for questions only sometimes asked.

Ends when the command finishes (bash), the program is back at its prompt (prompt_pattern, default as for run), until (a regex) matches, a stop rule matches, or -- the important case -- output stops at a question no rule answers: that returns at once as "unanswered" instead of waiting for the timeout, so a surprise comes back to you rather than being guessed at.

Example, gdb's optional questions: input="gdb -q -ex 'break lib_fn' -ex run ./prog", respond=[{"pattern": "Make breakpoint pending", "line": "y"}, {"pattern": "Enable debuginfod", "line": "n"}] Example, ssh, handing any password prompt to the human: input="ssh host", respond=[{"pattern": "continue connecting", "line": "yes"}, {"pattern": "[Pp]assword:", "stop": true}] Without input, the rules apply to a question already waiting at the cursor (one a run came back "waiting" at).

Returns a transcript (what matched, what was sent), rules that never fired, and the resulting region(s) as run does.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNotype even over someone else's unsubmitted line at the prompt, discarding it first; only for a line you know is stale
inputNoa line to type first (Enter added), e.g. the command that will ask the questions; without it the rules are applied to a question already waiting at the cursor
untilNoregex: return as soon as the output matches it, the command still running (status "until"; `wait` resumes); not a prompt pattern
respondYesthe rules: each fires when its `pattern` appears, doing its one action (line, text, keys or stop); a question no rule covers ends the call as "unanswered"
sessionYesthe session's name (from session_create or session_list)
max_linesNolines of output shown in the reply; longer output is clipped in the middle, led by its summary lines (test results, compiler errors, make's failure) when the middle holds them; all of it stays readable with `read`/`search`
timeout_sNoseconds to wait before giving up (the command keeps running; `wait` resumes); at most 1500
prompt_patternNoregex that marks the program's prompt at the end of the cursor line; rarely needed, the default knows shell, gdb, pdb, lldb and python prompts and any ending in $ # % >; pass one only after a reply came back "waiting" at a prompt it did not know (it offers the pattern); make it cover a part that changes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it explains termination conditions (command finishes, prompt, `until`, `stop`, or unanswered question), the immediate `unanswered` return, timeout behavior, transcript output, secret masking, and `force` discarding stale input. It also warns about password prompts and handing control back to the human.

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?

Despite being longer than average, the description is front-loaded and every paragraph earns its place: purpose first, then termination behavior, then examples, then the no-`input` case, then return details. The examples and edge-case notes are dense but directly useful for invoking such a complex tool.

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?

Given the tool's complexity, lack of annotations, and rich output schema, the description is complete enough for correct selection and invocation. It covers purpose, alternatives, termination, return shape, rule behavior, and edge cases without needing to re-explain return fields that the output schema already documents.

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 100%, so the schema establishes a strong baseline, but the description adds meaningful usage semantics through concrete examples for `input` and `respond`, clarifying how rule order works and how `stop` combines with an answer. It is not fully redundant, though much of the per-parameter detail already lives in the schema.

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?

The description states a specific verb and resource: scripting predictable interactions in one call, with optional input and rule-based prompt answering. It clearly contrasts this with related operations such as `run`, `send`, and `wait`, making its unique role identifiable without opening schemas.

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

Usage Guidelines5/5

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

It gives explicit when-to-use context: the interactive form of `yes |`, `echo y |`, gdb's `-batch`, and an expect script, and explains that rules can cover questions only sometimes asked. It also explains the no-`input` case, where rules apply to a question already waiting from a `run`, directly routing the agent between siblings.

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