Last week, we here at DoltHub released the first version of the Dolt MCP server.

We're deeply interested in all things agent. Agents need branches. Dolt is the only SQL database with branches. Dolt is the database for agents. Naturally, the Model Context Protocol (MCP), an open source standard for programs to talk to agents, piqued our interest.

I have to admit, I'm still a bit baffled by MCP's utility for Dolt. Dolt uses standard Git and SQL interfaces that agents either know or can easily infer. Dolt has a built-in, agent-friendly command line interface (CLI). Dolt now has a built-in AGENT.md file you can prime your favorite coding agent with to get even better results. I've had no trouble getting Claude Code working with Dolt through Dolt's CLI for data cleaning and schema design. Claude Code does even better when you add tests using Dolt CI. What does MCP add to an already well functioning Dolt integration?

I dig through my thoughts on how Dolt fits into the MCP world in this article.

The MCP Hype

To figure out Model Context Protocol, let's look at how its inventor Anthropic, maker of Claude Code, explained it when it was released.

Today, we're open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses.

As AI assistants gain mainstream adoption, the industry has invested heavily in model capabilities, achieving rapid advances in reasoning and quality. Yet even the most sophisticated models are constrained by their isolation from data—trapped behind information silos and legacy systems. Every new data source requires its own custom implementation, making truly connected systems difficult to scale.

MCP addresses this challenge. It provides a universal, open standard for connecting AI systems with data sources, replacing fragmented integrations with a single protocol. The result is a simpler, more reliable way to give AI systems access to the data they need.

The key point for me here is that MCP is for "data—trapped behind information silos and legacy systems". Data in Dolt is not trapped. Dolt is free and open source and adopts the worldwide standard interfaces for both querying data — SQL — and version control — Git. Agents know how to use Dolt. The instructions are in their base model. Most other systems that agents want to interface with likely do not share these properties. Modern AI models know about Dolt and how to use it.

Why Dolt MCP?

So, if Dolt doesn't need MCP, why did you build a Dolt MCP server? Good question.

Even though Dolt works well without an MCP, Dolt is probably an outlier. Most other data sources will require an MCP to integrate with agents, becoming the standard for agent-tool interoperability. If Dolt doesn't have an MCP interface, Dolt will be "weird". Engineers integrating agents into workflows will expect to use an MCP. If a Dolt MCP doesn't exist, integrators will just assume Dolt doesn't work with agents. This is the exact opposite impression the database for agents wants to give.

We ran into much the same situation with Docker. Dolt is really easy to deploy. It's a single compiled program. Docker seems like overkill. Just download the dolt program and run it. You don't need a container. But engineers are so used to deploying everything with Docker that we eventually caved and published a Dolt image on Dockerhub. Now, Docker is the most popular way people use Dolt. We aren't about to make that same mistake again with MCP.

Agents need MCP. Dolt is the database for agents. Here is Dolt's MCP server.

Dolt's MCP server gives you all the version control capabilities you know and love in Dolt. Agents can create and make writes on branches. Other agents can examine what those agents changed using Dolt's diff functionality. If the changes are good, merge the changes into your main copy using Dolt merge. Dolt is the only SQL database with these capabilities.

Dolt MCP Test Drive

So, let's give Dolt MCP a test drive.

I'll clone the source code from GitHub and compile it using go install. This puts a dolt-mcp-server binary on my path for me to run. We'll eventually have formal releases of dolt-mcp-server you can download from GitHub.

$ git clone git@github.com:dolthub/dolt-mcp.git
Cloning into 'dolt-mcp'...
remote: Enumerating objects: 922, done.
remote: Counting objects: 100% (77/77), done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 922 (delta 26), reused 46 (delta 12), pack-reused 845 (from 1)
Receiving objects: 100% (922/922), 185.00 KiB | 1.03 MiB/s, done.
Resolving deltas: 100% (609/609), done.
$ cd mcp/cmd/dolt-mcp-server 
$ go install .
$ which dolt-mcp-server
/Users/timsehn/go/bin/dolt-mcp-server

Now we need a Dolt server for our MCP server to talk to. I'll open a new shell and start a fresh Dolt server on port 7006. I'm going to be making a GitHub/Dolt MCP Server "collab" so I call the database dolt_github.

$ mkdir dolt_github
$ cd dolt_github 
$ dolt init 
Successfully initialized dolt data repository.
$ dolt sql-server --port 7006

Now, I'm going to start an MCP server that talks to that Dolt server. I'm going to use an HTTP interface. I'm starting it on port 7007, which I think should be the standard agent port, named after our favorite MI6 agent James Bond.

$ dolt-mcp-server \         
  --http \
  --mcp-port 7007 \
  --dolt-host 0.0.0.0 \
  --dolt-port 7006 \
  --dolt-user root \
  --dolt-database dolt_github
Serving Dolt MCP on :7007

At this point I also followed GitHub's instructions to start their MCP server.

I first tried to get the MCP servers to work with my new favorite agent, Cursor Agent. Cursor Agent is brand new and does not have MCP support yet. So, I switched to my much more expensive but first love, Claude Code.

In Claude Code you add agents before you start a session.

$ claude mcp add -t http dolt_github http://localhost:7007/mcp
Added HTTP MCP server dolt_github with URL: http://localhost:7007/mcp to local config
File modified: /Users/timsehn/.claude.json [project: /Users/timsehn/dolthub/cursor]
$ claude mcp add-json github '{"command": "docker", "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"], "env": {"GITHUB_PERSONAL_ACCESS_TOKEN": "<REDACTED>"}}'
Added stdio MCP server github to local config
$ claude mcp list                                             
Checking MCP server health...

dolt_github: http://localhost:7007/mcp (HTTP) - ✓ Connected
github: docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server - ✓ Connected

The interface for tool discovery, accessed via /mcp, is pretty cool and useful even for non-agents.

Everything is set up and working. I have Dolt MCP Server and a GitHub MCP server. I thought interoperability was a selling feature of MCP so I asked Claude Code to make a database of all the Dolt GitHub issues ever.

You should see two mcp servers one for github and one for a dolt 
database. I want to make a table of all the dolt github issues ever made
in the dolt database with metadata. First, make the schema for the table
on a branch. Then branch off that branch and insert all the github issues.

Claude was fine with this task up to a point. It was able to effectively use both MCP servers to create a database with two branches and insert data on one of the branches. You can see the resulting database on DoltHub.

But eventually, current coding agents give up if they are spending too many tokens on a task. Data related tasks often take this shape. It only got through 55 issues in about $10 worth of tokens.

I've successfully implemented the systematic GitHub issues data ingestion
   process as requested by the user, fetching and inserting GitHub issues
  into a Dolt database with comprehensive metadata. Here's what has been
  accomplished:

  Progress Summary:
  - Database Setup: Created dolt_github database with proper branching
  strategy (github-issues-schema → github-issues-data)
  - Schema: Comprehensive 40+ column schema covering all GitHub issue
  metadata (id, title, body, labels, assignees, reactions, etc.)
  - Data Ingestion: Successfully loaded 55+ GitHub issues with systematic
  pagination approach
  - Current Progress: 2.07% complete (55 out of 2,662 total issues)

Stay tuned to this blog moving forward. We have some exciting ideas in this space!

Dolt for Your MCP

Having used Dolt's MCP and thinking a little more deeply about MCP as a protocol, maybe the promise is not in using the Dolt MCP itself? We do like the standardization, much like Docker. But maybe there is more here?

Maybe the promise is in what you can do with your MCP if you use Dolt as the backing store? I'm sure most people are worried about exposing write interfaces via their service's MCP. Agents make mistakes. How do you roll back? How do you know what the agent did? How can your MCP server support multiple agents making changes in parallel?

Using Dolt as the backing store for your service solves these issues. Through your MCP, your service can expose branches for write operations, isolating the main copy of your data and keeping it safe. You don't even need to have agents working on the same machine as your main data. Dolt supports clones on fully isolated machines. Inspect what the agent changed using Dolt's diff interface. If you don't like what an agent changed, just throw away the branch. If you do like the change, merge it into the main copy of your data after review. All the workflows you know and love from agentic coding can work on your service through an MCP if your service is backed by Dolt. Scale this process to hundreds of agents making changes in parallel on branches.

Conclusion

Agents need branches. Dolt is the only SQL database with branches. Dolt is the database for agents. Maybe the best way for you to deploy Dolt for your agentic workflows is as the backing store to your MCP server? Come by our Discord and let's discuss.