Skip to main content
Glama

terminal_send_input

Destructive

Execute commands in a visible terminal window by sending text input to a specified session, allowing real-time command execution and interaction with the terminal environment.

Instructions

Send input (command or text) to a terminal.

The input is sent to the visible terminal window and executed there.
The user can see the command being executed in real-time.

Args:
    session_id: The terminal session ID returned by terminal_create_or_get.
    text: The text/command to send. This will be executed as a shell command.

Returns:
    dict: Contains success status, session_id, and the sent text.

Examples:
    - Run a command: terminal_send_input(session_id="abc123", text="ls -la")
    - Start a server: terminal_send_input(session_id="abc123", text="npm start")
    - Run Python: terminal_send_input(session_id="abc123", text="python script.py")

Note:
    The command is executed asynchronously. Use terminal_get_output to
    retrieve the results after the command completes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYes
textYes

Implementation Reference

  • The implementation of the terminal_send_input tool handler. It validates the session and delegates to the session manager.
    async def terminal_send_input(session_id: str, text: str) -> dict:
        """Send input (command or text) to a terminal.
    
        The input is sent to the visible terminal window and executed there.
        The user can see the command being executed in real-time.
    
        Args:
            session_id: The terminal session ID returned by terminal_create_or_get.
            text: The text/command to send. This will be executed as a shell command.
    
        Returns:
            dict: Contains success status, session_id, and the sent text.
    
        Examples:
            - Run a command: terminal_send_input(session_id="abc123", text="ls -la")
            - Start a server: terminal_send_input(session_id="abc123", text="npm start")
            - Run Python: terminal_send_input(session_id="abc123", text="python script.py")
    
        Note:
            The command is executed asynchronously. Use terminal_get_output to
            retrieve the results after the command completes.
        """
        manager = SessionManager.get_instance()
        session = await manager.get_session(session_id)
    
        if not session:
            return {
                "success": False,
                "error": f"Session '{session_id}' not found. It may have been closed or never existed.",
                "suggestion": "Use terminal_create_or_get to create a new terminal.",
            }
    
        success = await manager.send_input(session_id, text)
        if success:
            return {
                "success": True,
                "session_id": session_id,
                "sent_text": text,
                "message": f"Command sent to terminal '{session.name}'",
            }
        else:
            return {
                "success": False,
                "session_id": session_id,
                "error": "Failed to send input. The terminal may have been closed.",
            }
  • The tool registration using the @mcp.tool decorator.
    @mcp.tool(
        name="terminal_send_input",
        annotations={
            "title": "Send Input to Terminal",
            "readOnlyHint": False,
            "destructiveHint": True,
            "idempotentHint": False,
            "openWorldHint": True,
        },
    )
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it notes that commands execute asynchronously, users can see execution in real-time, and results must be retrieved with terminal_get_output. Annotations indicate destructiveHint=true (mutation) and readOnlyHint=false (write operation), which align with the description's 'send' and 'execute' actions, with no contradiction.

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?

The description is well-structured and front-loaded, starting with a clear purpose, followed by usage notes, args, returns, examples, and a critical note. Each sentence adds value without redundancy, such as explaining asynchronous execution and result retrieval, making it efficient and easy to parse.

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?

Given the tool's complexity (destructive, asynchronous execution) and lack of output schema, the description is largely complete: it covers purpose, usage, parameters, returns, and key behavioral notes. However, it doesn't explicitly address error handling or security implications (e.g., command injection risks), leaving minor gaps.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: session_id is 'returned by terminal_create_or_get' and text is 'the text/command to send' that 'will be executed as a shell command'. This adds meaningful semantics beyond the bare schema, though it doesn't detail constraints like text length or session_id format.

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 clearly states the tool's purpose with a specific verb ('send') and resource ('input to a terminal'), distinguishing it from siblings like terminal_close (closes sessions), terminal_create_or_get (creates/retrieves sessions), terminal_get_output (retrieves results), and terminal_list (lists sessions). It specifies that input is sent to a visible terminal window for execution.

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?

The description provides explicit guidance on when to use this tool (e.g., to run commands, start servers, or execute Python scripts) and when not to use it (e.g., use terminal_get_output to retrieve results after command completion). It also references terminal_create_or_get as a prerequisite for obtaining session_id, effectively distinguishing it from alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hor1zonZzz/terminal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server