Skip to main content
Glama

terminal_create_or_get

Idempotent

Create new terminal windows or access existing ones by name for direct user interaction and command execution. Specify a working directory to control where commands run.

Instructions

Create a new visible terminal window or get an existing one by name.

The terminal opens in a visible window that the user can interact with directly.
Commands sent to this terminal will be executed in that visible window.

Args:
    name: Optional name for the terminal. If a terminal with this name
          already exists and is still alive, it will be returned instead
          of creating a new one.
    working_dir: Optional working directory for the terminal.
                 If not specified, uses the current working directory.

Returns:
    dict: Contains session_id, name, platform, and a status message.
          Use the session_id for subsequent operations.

Examples:
    - Create unnamed terminal: terminal_create_or_get()
    - Create named terminal: terminal_create_or_get(name="dev-server")
    - Get existing terminal: terminal_create_or_get(name="dev-server")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
working_dirNo

Implementation Reference

  • The handler function for 'terminal_create_or_get' which triggers session creation via the SessionManager.
    async def terminal_create_or_get(
        name: Optional[str] = None, working_dir: Optional[str] = None
    ) -> dict:
        """Create a new visible terminal window or get an existing one by name.
    
        The terminal opens in a visible window that the user can interact with directly.
        Commands sent to this terminal will be executed in that visible window.
    
        Args:
            name: Optional name for the terminal. If a terminal with this name
                  already exists and is still alive, it will be returned instead
                  of creating a new one.
            working_dir: Optional working directory for the terminal.
                         If not specified, uses the current working directory.
    
        Returns:
            dict: Contains session_id, name, platform, and a status message.
                  Use the session_id for subsequent operations.
    
        Examples:
            - Create unnamed terminal: terminal_create_or_get()
            - Create named terminal: terminal_create_or_get(name="dev-server")
            - Get existing terminal: terminal_create_or_get(name="dev-server")
        """
        manager = SessionManager.get_instance()
        session = await manager.create_or_get_terminal(name, working_dir)
        web_url = get_web_url(session.id)
        session.web_url = web_url
        webbrowser.open(web_url)
        return {
            "session_id": session.id,
            "name": session.name,
            "platform": session.platform,
            "web_url": web_url,
            "message": f"Terminal '{session.name}' is ready (session: {session.id})",
        }
  • Registration of 'terminal_create_or_get' using the @mcp.tool decorator.
    @mcp.tool(
        name="terminal_create_or_get",
        annotations={
            "title": "Create or Get Terminal",
            "readOnlyHint": False,
            "destructiveHint": False,
            "idempotentHint": True,
            "openWorldHint": True,
        },
    )
  • The logic in SessionManager that handles creating or retrieving an existing terminal session.
    async def create_or_get_terminal(
        self, name: Optional[str] = None, working_dir: Optional[str] = None
    ) -> TerminalSession:
        """Create a new terminal or get an existing one by name.
    
        Args:
            name: Optional terminal name. If specified and exists, returns existing session.
            working_dir: Optional working directory for the terminal.
    
        Returns:
            TerminalSession for the created or existing terminal.
        """
        async with self._lock:
            # If name specified, try to find existing session
            if name:
                for session in self._sessions.values():
                    if session.name == name:
                        if await self._terminal.is_session_alive(session):
                            return session
                        else:
                            # Clean up dead session
                            await self._terminal.close_terminal(session)
                            del self._sessions[session.id]
Behavior4/5

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

The description adds valuable behavioral context beyond annotations. Annotations indicate readOnlyHint=false (mutation), openWorldHint=true (can create new resources), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description elaborates on behavior: terminals are 'visible' and user-interactive, commands execute in that window, and it explains the idempotent behavior (returns existing terminal if alive). It does not mention rate limits or auth needs, but provides useful operational details.

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: the first sentence states the purpose, followed by behavioral details, parameter explanations, return info, and examples. Each sentence earns its place by adding value (e.g., explaining visibility, idempotency, parameter defaults, usage of session_id). No wasted words.

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 moderate complexity (mutation with idempotency), rich annotations, and no output schema, the description is largely complete. It covers purpose, behavior, parameters, returns, and examples. However, it lacks explicit error handling or edge cases (e.g., what happens if terminal name conflicts or working_dir is invalid), and the return dict fields are listed but not fully explained (e.g., what 'platform' means).

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 (schema only has titles 'Name' and 'Working Dir'), the description fully compensates by explaining both parameters. It clarifies that 'name' is optional and used for idempotent retrieval, and 'working_dir' is optional with a default (current directory). This adds essential meaning beyond the bare schema, though it could specify format constraints (e.g., path syntax).

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: 'Create a new visible terminal window or get an existing one by name.' It specifies the verb (create/get), resource (terminal window), and distinguishes it from siblings like terminal_close (closing), terminal_get_output (reading output), terminal_list (listing), and terminal_send_input (sending input).

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 provides clear context for when to use this tool: to open or retrieve a visible terminal window. It implies usage through examples (e.g., creating unnamed/named terminals, getting existing ones) but does not explicitly state when to use alternatives like terminal_list for listing or terminal_close for closing, nor does it mention exclusions (e.g., when not to create a new terminal).

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