Overview
What is pty-mcp-server?
pty-mcp-server is a Haskell implementation of the Model Context Protocol (MCP) that enables AI agents to acquire and control pseudo-terminal (PTY) connections dynamically. It communicates with MCP clients exclusively via stdio, allowing AI to interact with external CLI-based tools in a structured, automated way.
How to use pty-mcp-server?
Install with cabal install pty-mcp-server, then run with pty-mcp-server -y config.yaml. The server is typically launched by development tools like Visual Studio Code via a .vscode/mcp.json configuration. The config.yaml file specifies logging, script directories, and prompt detection strings.
Key features of pty-mcp-server
- Launches commands through PTY interfaces with optional arguments
- Provides tools for interactive Bash, SSH, cabal, stack, and GHCi sessions
- Supports scriptable CLI integration via
tools-list.jsonand shell scripts - Dynamically resolves tools by name without recompilation
- Operates exclusively in stdio transport mode
- Follows a modular, onion-architecture package design
Use cases of pty-mcp-server
- Performing interactive REPL operations (e.g., GHCi) for Haskell development
- Interactive debugging of Haskell applications
- System diagnostics through bash scripting
- Remote server management via SSH
- Dynamic execution of CLI tools in PTY environments
FAQ from pty-mcp-server
What are the runtime requirements?
GHC >= 9.12 and a Linux environment with PTY support. On Windows, use within WSL.
How do I add a new tool without recompiling?
Create a shell script named your-tool.sh in the configured scripts/ directory, then add an entry in tools-list.json with the tool name and metadata. The server dynamically resolves tools by name.
What transport mode does pty-mcp-server use?
It operates strictly in stdio mode, communicating with MCP clients exclusively via standard input and output.
Is there any caution about AI control?
Yes. The README explicitly warns against granting unrestricted control to AI. All AI systems must remain under human oversight, and use is at the user’s own risk.
What logging and configuration options are available?
The config.yaml file supports logDir (log file directory), logLevel (e.g., "Debug", "Info", "Error"), scriptsDir (containing tools-list.json and scripts), and prompts (list of strings to detect interactive command prompts).