Does bitpull support MCP?

No. There is no MCP server exposed by the platform and no MCP client inside the agent, and no date is announced for either. Declared agent tools and the outbound webhook are the mechanisms that exist today.

Can I build an MCP server for bitpull myself?

Yes, for the session lifecycle. A thin MCP server wrapping the public REST endpoints can expose starting and ending a conversation as tools to your own assistant, with no cooperation needed from the platform.

MCP and AI voice agents - where bitpull stands

Where this stands

This page exists because people search for it and deserve a straight answer rather than a page implying support. There is no MCP server in the bitpull platform, no MCP client inside the agent, and no announced date for either. If you are evaluating bitpull specifically because you want to point an MCP client at it, that is not possible today.

What MCP would mean here, in both directions

bitpull as an MCP server

Planned

Your own AI tooling - an assistant, an IDE, an orchestrator - connecting to bitpull and being able to read conversations, start a call, or inspect an agent as tools it can use. This is the direction most people mean when they ask.

Blocked on: a scoped machine credential, which the account API does not have.

bitpull as an MCP client

Planned

A bitpull agent connecting to your MCP server and discovering the tools it exposes, instead of each tool being declared by hand on the agent. Fewer declarations, more moving parts inside a conversation with a latency budget.

Blocked on: latency, and on permissions during an unattended call.

The interesting problem is not the protocol

MCP in a chat assistant and MCP inside a live phone call are different engineering problems, and it is worth being clear about why:

Latency. A chat assistant can spend three seconds on a tool call. A caller hears it. Tool discovery, negotiation and a round trip inside a spoken turn is a budget problem before it is a protocol problem - the numbers are here.
Consent. An MCP client normally has a human approving what a tool may do. In an unattended phone call there is nobody to approve anything, and the "user" is an unverified stranger on the line.
Blast radius. A declared tool with a fixed JSON Schema is a narrow, reviewable surface. A discovered tool set is whatever the server offers today, reached with arguments extracted from speech.
Determinism. Support teams need to answer "what did the agent do on that call". A fixed tool list makes that answerable.

None of these are arguments against MCP. They are the reasons a voice platform adopts it later than a chat product does, and they are the questions worth asking any vendor who claims otherwise.

What to use today

What you wanted MCP for	What works now
The agent calling your systems during a conversation	Declared agent tools - a name, a description and a JSON Schema. The same idea with a fixed surface.
Getting conversations into your own tooling	The outbound webhook. One HTTPS POST per finished conversation.
Your own assistant starting a conversation	The session API. Wrapping those five endpoints in your own MCP server is a short afternoon.
Programmatic agent management	Nothing suitable. The account API authenticates a person, not an application - why that matters.

You can build the first half yourself

Nothing stops you writing an MCP server that wraps the public session API and exposes "start a conversation with agent X" as a tool to your own assistant. That is a thin wrapper over five documented endpoints, it needs no cooperation from the platform, and it gets you most of what people actually want from bitpull-as-an-MCP-server.

Research rather than roadmap

Agent protocols, tool discovery and what they do to realtime systems are worked on at neob.dev, the research side of the same company. Treat anything you read there as research and anything on this domain as a product statement - that separation is the point of having both.

This page will change when something ships. Until it does, it says no.