Local models are private but can only chat until you attach tools. This article ranks seven MCP servers for Ollama, LM Studio and Open WebUI, shows the config for each client, suggests models that call tools reliably, and lists the safety rules that keep a local agent in check.
Local models are private and cheap to run, but out of the box they can only talk. They can't read your project folder, check a git diff or open a web page. MCP, the Model Context Protocol, closes that gap by giving any compatible app a standard way to hand a model real tools. The catch is that a local setup has two problems a cloud chatbot doesn't: a smaller context window, and a smaller model that fumbles tool calls more often. So the best MCP servers for local LLMs are not the biggest catalogs. They are the few that are lightweight, predictable and safe to leave running on your own machine.
Below you'll find seven servers that fit that bar, three ways to connect them to Ollama, LM Studio and Open WebUI, and the mistakes that make local agents slow or risky.
An MCP server is a small program that advertises a list of tools: read a file, run a git command, fetch a page. An MCP client, such as LM Studio or Open WebUI, shows that list to your model. When the model wants a tool, it emits a structured call, the client runs it on the server, and the result goes back into the conversation.
That split suits local use. The model stays on your hardware, the server runs next to it, and nothing leaves your network unless a tool itself reaches out to the web. Two transports show up everywhere:
A model with 7 to 20 billion parameters can call tools, but it is less forgiving than a frontier model. It may pick the wrong tool, invent an argument or loop on the same call. Every tool a server exposes is described in the prompt, so ten servers can swallow a large share of a modest context window before you type a word.
💡 Rule of thumb: enable three or four servers per chat, not twelve. LM Studio's own docs warn that servers built for Claude or ChatGPT can burn through tokens and drag a local model down.
The client decides which servers you can use and how much setup you face. Three options account for most local stacks, and each one treats MCP differently.
LM Studio added MCP support in version 0.3.17 and handles both local and remote servers. Open the Program tab in the right sidebar, choose Install, then Edit mcp.json. The file follows Cursor's notation, so configs copied from other tools usually paste straight in.
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/notes"]
}
}
}
Remote servers use a url and optional headers instead of a command. When you paste a config found online, copy only the content inside "mcpServers": { ... }, otherwise the nested braces break the file.
💡 Servers launched with
npxneed Node.js, and servers launched withuvxneeduv. A missing runtime is easy to overlook when a freshly added server shows no tools.
Ollama runs models and supports tool calling, but it does not speak MCP by itself. You need a client in the middle that lists the tools and translates them into Ollama's tool format. Your options:
uv tool install --upgrade ollmcp.Pick ollmcp if you live in the terminal. Leave its confirmation prompts on while you test. Not every Ollama model supports tools, and the Ollama library tags the ones that do, so filter for that tag before you download a model.
Open WebUI supports MCP natively from version 0.6.31, but only over Streamable HTTP, because it is a web app for several users rather than a desktop process. An admin adds a server under Settings > Admin > Integrations, picks + Add Connection, and sets the type to MCP (Streamable HTTP). Regular users can't register their own servers, a deliberate safety choice.
For stdio servers, run them behind mcpo, a proxy that turns stdio or SSE servers into OpenAPI endpoints:
uvx mcpo --port 8000 -- npx -y @modelcontextprotocol/server-memory
Then add the resulting URL as an OpenAPI tool server. If you run Open WebUI in Docker, set the WEBUI_SECRET_KEY environment variable. Without it, OAuth-connected tools break whenever the container restarts.
These seven are ordered by how much they add to a typical local setup for each token of context they use. Six come from the official reference collection, which currently maintains Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking and Time. The seventh, Playwright, is Microsoft's.
The one almost everyone installs first. It gives the model tools to read, write, list and search files, limited to the folders you pass as arguments. Point it at a notes vault, a docs folder or a single repo, never at your whole home directory. It handles jobs like summarizing meeting notes, renaming a batch of files or drafting a README from source code.
Run with uvx mcp-server-git, it lets a model read status, diffs and history, and create commits. It is compact and well behaved, which makes it a good match for 8B-class models. Ask for a commit message based on the staged diff and the model has everything it needs in a single call.
Fetch pulls a URL and converts the page to markdown so it fits in a context window. For many local setups it is the only route to the live web that needs no account or token. Treat every fetched page as untrusted text. A page can contain instructions aimed at your model, a problem known as prompt injection.
A knowledge-graph memory that stores entities, relations and observations in a local file, so the model can recall facts between chats. It is one of the cheapest ways to make a small model feel consistent. Back that file up and skim it now and then, because the model decides what gets stored. A short system prompt that says when to store a fact and when to recall one helps, since small models tend to save everything or nothing.
Microsoft's @playwright/mcp drives a real browser through accessibility snapshots instead of screenshots, so a text-only local model can click and type without a vision model. It is the heaviest server on the list and the riskiest, since a browser can reach anything your network can. Use a dedicated browser profile and keep confirmations on.
It gives the model a structured way to break a problem into numbered thoughts, revise them and branch. That can hand a smaller model a scaffold for multi-step tasks. Models that already reason natively may not need it, so test with and without.
The seventh pick, Time, is a tiny server for the current time and timezone conversion. It matters more than it sounds, since a local model has no clock.
| Server | Best for | Launch command | Risk |
|---|---|---|---|
| Filesystem | Reading and editing notes, docs and code | npx -y @modelcontextprotocol/server-filesystem <folder> | Medium |
| Git | Status, diffs, history and commits | uvx mcp-server-git | Medium |
| Fetch | Pulling web pages as markdown | uvx mcp-server-fetch | Medium |
| Memory | Facts that persist between chats | npx -y @modelcontextprotocol/server-memory | Low |
| Playwright | Driving a real browser | npx @playwright/mcp@latest | High |
| Sequential Thinking | Step-by-step problem breakdown | npx -y @modelcontextprotocol/server-sequential-thinking | Low |
| Time | Current time and timezones | uvx mcp-server-time | Low |
Which three to enable first? For coding, try Filesystem, Git and Sequential Thinking. For research and notes, pair Fetch with Memory and Time. For browser automation, run Playwright on its own so its tool list has the context window to itself.
💡 Servers for SQLite, PostgreSQL, GitHub, Brave Search and Puppeteer used to sit in the reference collection but now live in an archive. Look for a maintained alternative before you depend on one.
A great server is wasted on a model that can't format a tool call. Families people commonly recommend for local tool calling include Qwen, Llama 3.1 and newer, and Codestral. Two more are worth testing. GPT OSS 20B is an open-weight model that OpenAI built with agentic work like function calling in mind, and OpenAI says it runs in 16 GB of memory. Granite 4.1 8B is IBM's compact option for mid-range GPUs.
Both are available as hosted models on PicassoIA, which means you can rehearse prompts there before pulling any weights. Those hosted runs happen on PicassoIA's servers, not on your machine.
Before downloading anything, you can check how a model formats tool calls. This takes about two minutes.
You can call these tools. Reply with JSON only.
read_file(path), list_directory(path), git_diff(repo)
Task: show me what changed in the notes folder today.
💡 This tests how a model formats calls. It doesn't connect to your MCP servers, so treat it as a rehearsal, not a replacement for a local run.
An MCP server can run code, read files and use your network. That is exactly why it is useful, and why LM Studio's docs say never to install MCPs from untrusted sources.
Check how many tokens your tool descriptions use before you blame the model. If it starts ignoring instructions after you add servers, remove servers first. Three well-chosen servers beat a dozen that crowd out the conversation.
Local models can't draw, but an MCP client can attach a hosted image server next to your local ones. The local model writes the prompt and a hosted model renders it. PicassoIA offers an API and an MCP connection for this. The API lives at api.picassoia.com/v1 and uses Bearer tokens, and the MCP connection exposes four models: PicassoIA Image for text-to-image, PicassoIA Image Editor Pro for edits, and two video models.
You set up the connection from your account's MCP page. In LM Studio, a remote server goes into mcp.json as a url plus headers, the same pattern the docs show for other remote servers.
Two caveats apply:
You don't need a full agent to benefit from this setup. Ask your local model for three image prompts that describe the same scene from different angles, a low shot, an overhead shot and a close-up. Paste them into PicassoIA Image and compare the results side by side.
Then pick your favorite and open it in PicassoIA Image Editor Pro to adjust the lighting, swap an object or clean up a detail. Short prompts with a clear subject, a light direction and a lens choice tend to give the sharpest photographic results.
Try it with your next blog header, product mockup or desktop wallpaper. The more you experiment with prompts your local model drafts, the faster you'll find a wording that works, and PicassoIA makes each round cheap to repeat.
