Overview
pipecat-mcp-transport serves your Pipecat bot as an MCP server, so any agent with an MCP client, for example Claude Code, talks to the bot. The bot keeps its pipeline, its tools and its history. This is the server side of MCP. To call MCP tools from a bot, see MCPClient. The server exposes two tools, start and chat, over Streamable HTTP. start runs your bot function and returns a session handle. chat appends a line to that session’s context, runs the LLM, and returns the whole reply as one text block.
One handle is one session: one pipeline, one context, one history. The transport pushes LLMConfigureOutputFrame(skip_tts=True) when the pipeline starts, so every turn costs no TTS request and a voice bot needs no second code path.
Source Repository
Transport, server, example bot and tests
PyPI Package
The
pipecat-mcp-transport package on PyPIStreamable HTTP
The MCP transport this server speaks
Installation
Prerequisites
MCP client
Any client that speaks MCP over Streamable HTTP, for example Claude Code. The transport needs no account and no API key of its own.Required Environment Variables
None for the transport. The services in your bot keep their own keys, for exampleOPENAI_API_KEY for the OpenAI services in the example bot.
Configuration
McpBotServer takes your bot function and serves it.
Usage
Your bot takes its transport from the runner arguments. That branch is the only line the transport adds.Tools
An empty
line starts no turn and returns the reply of the turn in flight. A turn that one call read is gone, so the next empty line returns an empty block.
Limitations
- The reply arrives as one text block after the turn, with no token streaming.
- A
chatcall carries no audio block and no image block. - A session lives in one process. A second replica needs sticky routing on the handle.
- The server binds
127.0.0.1by default and the handle is a bearer secret. Put an authenticating proxy in front of an open bind.
transport_security setting and the full list of limits.