LM Studio MCP Setup: Connect Tools to Your Local Models

LM Studio has native MCP support — no plugins, no wrappers. Update to 0.3.17 or newer (the current release is 0.4.20), open the Program tab in the right sidebar, click Install > Edit mcp.json, paste a server entry in Cursor's notation, and save. LM Studio loads the server immediately. Pair it with a model that can actually call tools: gpt-oss-20b on 16GB of RAM/VRAM, Qwen3-30B-A3B-Instruct-2507 on 24GB+. Total cost: $0.

That is the entire setup, and it takes about five minutes. The rest of this guide is the part that saves you an evening: three working mcp.json configs (filesystem access, GitHub, and Playwright browser control), the confirmation flow that decides whether tools feel safe or annoying, how to use MCP servers through LM Studio's API from your own code, and — the section most tutorials skip — why some models loop or ignore tools entirely, and which ones don't.

If MCP itself is new to you, our MCP servers explained primer covers the protocol; this page assumes you know roughly what an MCP server is and just want it working in LM Studio.

---

What You Need

Three things: LM Studio 0.3.17 or newer, a tool-capable model that fits your memory, and Node.js 18+ if you want to run local npx-based servers. Everything below was verified against the official LM Studio docs and each server's own repository in August 2026.

Version gates, so you know what your build can do:

The current release line (0.4.20 as we publish) clears all four bars — only the last row, the native-API route, needs a 0.4.x build. It is still worth staying current: LM Studio ships tool-calling fixes for specific model families almost every release — GLM 4.5 tool calling in 0.3.32, MiniMax M2 in 0.3.31, Olmo-3 in 0.3.33, LFM2 in 0.3.37, per the release notes. Tool reliability is partly an app-version property, not just a model property.

Hardware-wise there is nothing exotic here: if your machine runs a model in LM Studio today, it runs that model with MCP tools attached. The constraint is context memory, not compute — more on that in the limitations section.

---

How MCP Works in LM Studio

LM Studio acts as an MCP host: one mcp.json file declares your servers, the app launches or connects to them, and their tools appear in chat for any loaded model. The file lives at ~/.lmstudio/mcp.json (macOS/Linux) or %USERPROFILE%\.lmstudio\mcp.json (Windows), and the format is deliberately borrowed from Cursor, so nearly every MCP server README on GitHub already shows you a compatible snippet.

You almost never touch the raw file path. In the app:

1. Open the Program tab in the right sidebar.
2. Click Install > Edit mcp.json.
3. Add servers inside the single top-level mcpServers object and save.

Per the official announcement, LM Studio automatically loads the servers defined in the file the moment you save — no restart. Two kinds of entries work:

• Local servers — a command plus args; LM Studio spawns the process on your machine. This is the fully-local path.
• Remote servers — a url plus optional headers (for auth tokens). Your prompts stay local, but tool calls hit that remote endpoint.

One editing gotcha that trips people up: mcp.json holds exactly one mcpServers object. Server READMEs usually print a complete file, wrapper and all — when adding your second and third server, merge the inner entries into the object you already have rather than pasting whole files after each other. Invalid JSON means no servers load.

And take the official security warning at face value, because it is unusually blunt for vendor docs: "Some MCP servers can run arbitrary code, access your local files, and use your network connection." Install servers the way you would install a shell script from the internet — only from sources you trust.

Now the three servers worth installing first.

---

Server 1: Filesystem — Let the Model Read and Write Files

The reference filesystem server from the official modelcontextprotocol/servers repo gives your model scoped file access — read, write, search, list — restricted to directories you name in the config. It is the best first server: entirely local, no accounts, no tokens, and you see the value in the first prompt.

Add this to your mcpServers object (requires Node 18+, since it runs via npx):

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/you/projects/sandbox"
      ]
    }
  }
}

The trailing path arguments are the allow-list — the server refuses operations outside them, per its README. Start with one scratch directory, not your home folder. On Windows, the README says to wrap the command with a cmd /c prefix.

Save, load a tool-capable model, and test with something concrete: "List the files in the sandbox directory, then read notes.txt and summarize it." You'll see LM Studio ask for confirmation before each tool runs (covered below), then the model's answer built on real file contents. That round trip — model, tool call, your approval, result, answer — is the whole MCP loop.

---

Server 2: GitHub — Issues, PRs, and Repos

Use GitHub's official remote MCP server at https://api.githubcopilot.com/mcp/ with a personal access token — the README calls the remote server the easiest way to get running. One warning first: the old @modelcontextprotocol/server-github npm package you'll still find in tutorials was moved to the archived-servers repo. Don't install it; GitHub's own server replaced it.

The remote config is just a URL and a header — this is where LM Studio's remote-server support earns its keep:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer <YOUR_GITHUB_PAT>"
      }
    }
  }
}

Create the token in GitHub under developer settings, scoped to the repos you want the model touching. If a remote endpoint doesn't fit your threat model, the README's local alternative is Docker: command: "docker", args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"], with the token passed in env — same tools, running on your machine.

What you get in chat: "Summarize the open issues on my repo labeled bug and draft a comment for the oldest one." The model searches, reads, and drafts — with your confirmation gate in front of anything that writes. This is the config that turns a local model into a genuinely useful repo assistant.

Privacy note, stated plainly: with the remote server, your inference stays on your machine but tool calls (and whatever the model puts in them) go to GitHub's endpoint. That's the trade for zero-install convenience. The Docker route keeps the server local; the API calls to github.com happen either way, because that is the point of the server.

---

Server 3: Playwright — Browser Control

Microsoft's Playwright MCP server gives your local model a real browser: navigate, click, type, take screenshots, manage tabs, even save pages as PDF — via npx @playwright/mcp@latest, Node 18+ required. This is the demo that convinces people MCP is more than a party trick, because the model can go get information that isn't in its weights.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Useful flags from the README: add "--headless" to the args if you don't want a browser window popping up, and "--browser", "chrome" (or firefox, webkit, msedge) to pick the engine.

Try: "Open example.com, take a screenshot, and tell me the main heading." Watch the tool sequence in the chat — navigate, snapshot, answer. Then temper your ambitions slightly: multi-step browsing is where mid-size local models start dropping the thread, because each page snapshot is enormous in tokens. Single-page lookups and form-filling work well; "research this topic across ten sites" is frontier-agent territory. If agentic workflows are your actual goal, our guide to the best local models for agents covers which models sustain longer chains.

---

Using Tools in Chat

Every tool call goes through a confirmation dialog: you see the tool name and its exact arguments, can edit them before running, and can allow a tool once or permanently. Permissions are managed in App Settings, per the LM Studio announcement. This is the single best safety feature in the whole stack — a model cannot delete a file or post a comment without showing you the arguments first.

Practical habits that make this pleasant instead of naggy:

• Grant always-allow to read-only tools (list, read, search, screenshot) and keep per-call confirmation on anything that writes, posts, or deletes. You'll approve one prompt's worth of writes per session instead of clicking through every read.
• Enable only the servers a chat needs. Every active server's tool catalog is injected into the model's context — three chatty servers can eat a small model's entire context window before you type a word. The official docs explicitly warn that servers designed for Claude, ChatGPT, or Gemini "may consume excessive tokens" on local models.
• Watch the arguments the first few times. Local models occasionally hallucinate paths or repo names; the edit-before-run dialog is where you catch it.

One more install path worth knowing: some projects ship an "Add to LM Studio" button — a lmstudio://add_mcp?name=...&config=... deeplink with the config Base64-encoded. Clicking it opens LM Studio with the server pre-filled and asks you to confirm. Convenient, but it is the same trust decision as pasting JSON, so read what you're approving.

---

MCP Through the API

Two routes. Since 0.3.29, LM Studio's OpenAI-compatible /v1/responses endpoint accepts a tool of type mcp with a server_url, and the local model calls that server's tools mid-request; since 0.4.0, the native REST API adds /api/v1/chat with an integrations field that can also reach the servers in your mcp.json. The /v1/responses route is off by default: enable "Allow MCP > Remote" in Developer settings first, per the release notes.

The shape, straight from the 0.3.29 announcement (LM Studio's server listens on 127.0.0.1:1234 by default):

curl http://127.0.0.1:1234/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-oss-20b",
    "tools": [{
      "type": "mcp",
      "server_label": "tiktoken",
      "server_url": "https://gitmcp.io/openai/tiktoken",
      "allowed_tools": ["fetch_tiktoken_documentation"]
    }],
    "input": "What is the first sentence of the tiktoken documentation?"
  }'

Two details that matter in practice. allowed_tools is your scoping mechanism — list only the tools the request should reach, rather than exposing a server's whole catalog. And the response stream includes the tool discovery and tool call events before the assistant's reply, so your code can log exactly what the model did — the API equivalent of the chat confirmation dialog, except there is no confirmation: API tool calls run without a human gate, which is why the opt-in exists. Point scripts only at MCP endpoints you'd trust with the request's contents.

On 0.4.0 or newer there is a second, more capable route: the native REST API. POST to /api/v1/chat with an integrations array — this is the example shape from the official "Using MCP via API" docs:

POST http://127.0.0.1:1234/api/v1/chat

{
  "model": "ibm/granite-4-micro",
  "input": "What is the top trending model on hugging face?",
  "integrations": [
    {
      "type": "ephemeral_mcp",
      "server_label": "huggingface",
      "server_url": "https://huggingface.co/mcp",
      "allowed_tools": ["model_search"]
    }
  ],
  "context_length": 8000
}

The practical difference from /v1/responses: besides ephemeral_mcp entries declared inline (custom auth headers supported), the integrations array can reference servers you already configured in mcp.json — "type": "plugin" with an ID like mcp/playwright, or just the ID string on its own. Treat that as a native-endpoint feature: the OpenAI-compatible /v1/responses route documents only inline remote MCP tools, not references to your configured servers. And the same scoping rule applies double here: allowed_tools is the only gate on an autonomous request, so list exactly the tools each call needs and nothing more.

Either way, this turns LM Studio into a local agent backend: familiar request shapes, zero per-token cost, nothing leaving your machine except the MCP calls you explicitly allow.

---

Models That Handle Tools

Model choice decides whether MCP feels magical or broken. The two picks that hold up, by memory budget:

Specs from each model card; memory for the Qwen MoE is our estimate for common 4-bit GGUF builds and varies with quant and context settings.

gpt-oss-20b is the 16GB pick because tool use isn't bolted on: OpenAI's card states native function-calling capability outright, and the within-16GB claim is the vendor's own. It is also the model LM Studio used in its 0.3.29 MCP-over-API examples, which tells you what the developers test against. Qwen3-30B-A3B-Instruct-2507 is the 24GB pick: its card leads with tool-calling strength, and the 262K native context means a stack of MCP tool definitions doesn't crowd out your actual conversation. Both are MoE designs with ~3.3-3.6B active parameters, so they generate fast for their size.

Below 16GB, be honest with yourself: 7-8B models will emit tool calls, and for a single simple server they can be fine, but reliability degrades quickly as tool catalogs grow — wrong arguments, ignored tools, loops. The same models behave the same way on other hosts, which is why our tool-calling model rankings transfer directly to LM Studio. For what your card can hold overall, match against the best LLMs for 16GB VRAM or 24GB VRAM pages.

Whatever you pick, load it with at least 16K context — 32K if you run multiple servers. LM Studio lets you set context length when loading the model, and this single setting fixes most "MCP is broken" complaints. Tool definitions, tool results, and page snapshots are all context; starve the model and it forgets its own tools mid-chat.

---

Honest Limitations

MCP in LM Studio works, today, on normal hardware — but four limits are worth knowing before you architect anything around it.

1. Context is the real cost. Every enabled server injects its tool catalog; every tool result comes back into context; a Playwright page snapshot alone can be thousands of tokens. LM Studio's docs warn specifically about servers built for frontier hosts overwhelming local models. Mitigations: fewer servers per chat, bigger context at load time, models with large native windows.

2. Local models are competent tool users, not agents. One or two tool calls to answer a question: reliable with the models above. Ten-step autonomous chains: expect dropped threads and loops. If you want long chains, that's a harness problem as much as a model problem — see our local agent models guide for what's realistic.

3. "Local" has an asterisk with remote servers. The GitHub remote endpoint, Hugging Face's hosted server, anything with a url — your prompts stay home, but tool traffic doesn't. Fully air-gapped means command-based servers only.

4. UI drifts; the file doesn't. LM Studio's interface around MCP has been reorganized more than once since 0.3.17, so menus in screenshots (including any you find elsewhere) go stale. The stable interface is mcp.json itself — Cursor notation hasn't changed since launch. When in doubt, trust the official docs over any tutorial, including this one. We re-verify this page against them quarterly.

If you're choosing a host rather than committed to LM Studio: the same servers work with Ollama's MCP integration and even llama.cpp directly, and our Jan vs LM Studio vs Ollama comparison covers where each shines. LM Studio's edge here is the confirmation UI and the zero-config server loading — it is currently the most beginner-friendly MCP host that runs entirely on your machine.

---

Sources

• LM Studio docs: Use MCP Servers — MCP host since 0.3.17, Program tab flow, Cursor notation, security warnings (checked August 2026)
• LM Studio blog: MCP announcement — release date, mcp.json file locations, auto-load on save, tool confirmation dialog and permissions
• LM Studio 0.3.29 release notes — /v1/responses, remote MCP in the API, the opt-in setting, and the curl example
• LM Studio docs: Using MCP via API — the native /api/v1/chat integrations field, ephemeral_mcp and plugin types (plugin IDs reference servers from your mcp.json), allowed_tools (0.4.0+)
• LM Studio docs: Add to LM Studio button — lmstudio://add_mcp deeplink format
• modelcontextprotocol/servers — filesystem server package, npx config, Windows cmd /c note, archived-servers list
• github/github-mcp-server — remote endpoint URL, PAT auth, Docker config
• microsoft/playwright-mcp — config, Node 18+ requirement, tool list, --headless/--browser flags
• openai/gpt-oss-20b and Qwen/Qwen3-30B-A3B-Instruct-2507 model cards — parameters, context, memory and tool-use claims

---

FAQ