Search "ollama mcp server" and you get a page of GitHub repositories with nearly identical names. MCPHost. ollama-mcp-bridge. ollama-mcp. Some of them do one thing, some do the exact opposite, and none of them come from Ollama.
That last part is the answer to the question. It is also why the rest of the list exists. Ollama does not ship an MCP server, so people wrote their own, and they wrote them pointing in two different directions depending on which side of the connection they needed. Picking the wrong direction is the most common way to lose an afternoon here, because both directions are described with the same four words.
Does Ollama have an MCP server?
Ollama ships no MCP server of its own. Nothing inside Ollama exposes its models as MCP tools to Claude Code or any other MCP client, and the first-party feature request, issue #7865, has been open since November 2024. Bridging Ollama into MCP works today, but it means running a third-party project alongside it.
Issue #7865 was filed on 27 November 2024, labeled a feature request, and assigned to an Ollama maintainer. It is still open. No pull request is attached to it. Nothing in the CLI, nothing in the REST API on port 11434, and nothing in the desktop app advertises MCP tools, and nothing in Ollama consumes them either.
What Ollama does have is a stable REST API that anything can wrap. That is exactly what the bridge projects do, and it is the reason they were possible to write without Ollama's involvement.
Which direction do you need, client or server?
MCP has two sides and Ollama sits on neither by default. Getting a local Ollama model to call tools means running a host program that acts as the MCP client, and getting Claude Code or Cursor to call an Ollama model means running a wrapper that exposes Ollama as an MCP server.
Sort the repositories by direction and the list stops being confusing.
You want your Ollama model to use tools. You are running Qwen or Llama locally and you want it to read files, search the web, or hit an API. Here Ollama is the model, and something else has to be the MCP client that discovers tools, hands them to the model, parses the tool call back out, and runs it. That something is a host program. MCPHost and the ollama-mcp-bridge projects live here.
You want Claude Code to use Ollama. You already have an MCP client you like and you want a local model reachable from inside it, maybe to run a cheap summarization step without a round trip to a cloud API. Here Ollama is the tool provider, and something has to translate its REST API into MCP. That is a server, and rawveg/ollama-mcp is the one that fits the literal search query.
Both are legitimate. They are also not substitutes for each other, and installing the first when you needed the second produces a setup where everything starts cleanly and no tools ever appear.
What do the Ollama MCP bridges actually do?
Each one is a separate process that translates between Ollama's REST API and MCP. MCPHost and the two ollama-mcp-bridge implementations act as hosts, giving a local Ollama model access to MCP tools, while rawveg/ollama-mcp runs the other way and exposes Ollama to an MCP client as 14 tools over the Ollama SDK.
MCPHost is a Go CLI host from mark3labs. You install it with go install github.com/mark3labs/mcphost@latest, it writes a config at ~/.mcp.json, and you pick a model with a flag that looks like -m ollama:qwen2.5:3b. It connects to several MCP servers at once and gives you an interactive conversation in the terminal with all their tools available. It was the first thing most people found, and it worked. Active development on it has since stopped, and the author points users at a successor project called Kit.
ollama-mcp-bridge is two different projects sharing a name. The patruff version is TypeScript and translates a model's tool-call output into MCP JSON-RPC, wiring local models up to filesystem, search, and GitHub servers. The jonigl version is Python, installable from PyPI, and takes a smarter angle. It sits in front of the Ollama API and adds tools to it, so any client already pointed at Ollama inherits the tools without knowing MCP exists. If you have an app that speaks the Ollama API and you want it to gain tools without touching the app, that is the one to read first.
rawveg/ollama-mcp is the actual server. You add it to your MCP client config as npx @rawveg/ollama-mcp, it comes up on port 3456, and it exposes 14 tools covering the Ollama SDK: listing installed models, pulling new ones, running chat and completion calls, generating embeddings. It is AGPL-3.0. Point Claude Code at it and your assistant can drive your local Ollama install directly. This is a real MCP server and it does the job it claims.
What all three cost you is the same, and it is worth being concrete about it. Each one is a separate process you have to start and keep running. Each one has its own config file that lives somewhere other than your MCP client's config, so a broken tool means checking two places. Each one is a dependency you now maintain against two moving targets, Ollama's API and the MCP spec, with no coordination between them. And the tool-calling quality is bounded by the model you loaded, which is a real constraint on the client-side bridges: a 3B model with fourteen tools in its context makes worse choices than the same model with three.
None of this is a knock on the projects. They are doing work that has been sitting in an open issue since November 2024, and they are the reason Ollama models get used through MCP clients every day.
What changes when the MCP server is first-party?
A first-party MCP server is part of the application rather than a wrapper around it, so there is one process to run, one config entry to add, and one project shipping both halves. ToolPiper is a native macOS app whose MCP server exposes over 420 tools on the free tier, with no account and no separate bridge process.
The difference is not that a wrapper is badly built. It is that a wrapper can only expose what the API underneath it already returns. rawveg/ollama-mcp has 14 tools because Ollama's REST API has roughly that many useful endpoints, and no amount of work on the wrapper changes that ceiling.
ToolPiper's MCP server is not wrapping an inference API. It is the same app that does the inference, the speech, the vision, and the browser control, so the tools it serves are the app's whole surface rather than one API's endpoint list. Local chat and embeddings are there, and so are transcription, text to speech, voice cloning, Apple Vision, CDP browser automation, desktop control, and file operations. All of that is in the free tier, no account. We wrote up the full catalog and the Claude Code setup in Local MCP Server on Mac, and if you are still comparing options, the ranked roundup puts it next to everything else available on macOS.
Serving a large catalog raises its own problem, which is that a small local model handed hundreds of tools chooses badly. That is a real engineering concern and we wrote about how we handle it in local AI tool routing. If you would rather assemble the pieces yourself, the DIY server stack comparison lays out what that path costs.
If you are keeping Ollama, that stays workable. ToolPiper can point at an existing Ollama install as a backend, and it also answers the Ollama wire API itself, which we cover in the Ollama-compatible API post.
What are the honest limits?
A first-party MCP server replaces the wrapper, not the host. ToolPiper serves tools to an MCP client and runs on Apple Silicon Macs only, so getting a model inside Ollama to make the tool calls still needs a host program, and anyone on Linux or Windows is better served by the bridge projects.
That first half is the one people hit. If what you specifically want is the model running inside Ollama making the tool calls, that is the client side of MCP, and a host program is still the piece that does it. MCPHost's successor or the jonigl bridge is the right tool for that job and ToolPiper is not.
The platform half is simpler. The bridge projects run on Linux and Windows and ToolPiper does not, so off the Mac the answer to "ollama mcp server" stays rawveg/ollama-mcp for the server direction and one of the bridges for the client direction.
Switching is also not free even when it is easy. Your MCP client config changes, your models come down again as ordinary GGUF files rather than blobs, and any script that shells out to ollama needs a look. The compatibility listener covers most of that, but "most" is the honest word.
And the bridges work. If you have MCPHost configured the way you like it and it has not broken on you, there is no technical emergency here.
Getting a local MCP server running
Download ToolPiper at modelpiper.com, open it, and add it to Claude Code with a single MCP config entry. The tools are available immediately, and the models you pull are plain GGUF files in a folder you can open.
This is part of a series on local-first AI workflows on macOS. Next up: Local MCP Server on Mac, the full tool catalog and the Claude Code setup.