MCP Server

agentty speaks the Model Context Protocol both ways: it can serve its native tools to any MCP client, and consume tools from other MCP servers inside a thread.

Serving agentty's tools (mcp-serve)

agentty mcp-serve runs headless — no terminal UI — and exposes agentty's native toolset over MCP on stdio. An external MCP client (Claude Desktop, an IDE, another agent) drives tools/list and tools/call over stdin/stdout; diagnostics go to stderr.

agentty mcp-serve⧉

The served tools are the same ones the TUI uses: file read/write/edit, shell bash, code search (grep/glob/find_definition), web_fetch/web_search, diagnostics, and the git_* family. Filesystem tools stay sandboxed to the workspace boundary and shell calls run inside the OS sandbox, exactly as they do interactively.

Point a client at it

Any MCP client can launch agentty as a stdio server. For a client that reads a JSON config (Claude Desktop shown here):

{
  "mcpServers": {
    "agentty": {
      "command": "agentty",
      "args": ["mcp-serve"]
    }
  }
}⧉

Consuming other MCP servers

The reverse also works: drop a .agentty/mcp.json in your project and agentty connects to those servers on startup, appending their tools to its own registry. The model can't tell an MCP tool from a native one — and tools/list_changed is honoured live, so a server that adds a tool mid-session becomes callable on the next turn.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}⧉