Best MCP Servers for LM Studio (2026)
Add three MCP servers to LM Studio, not thirteen — here's the shortlist and the config path that makes them work.

The best MCP servers for LM Studio are the ones a local model can actually drive without drowning in tools: GitHub MCP Server, Anyquery, and GitMCP cover code, data, and docs for most people. LM Studio added MCP support in 0.3.17, so any server you already run in Claude Desktop or Cursor works here too. The catch is that local models are worse at tool selection than frontier models, so your job is to add fewer servers, not more.
This is a shortlist, not a catalog. Every server below is grounded in what it actually does, with the trade-off spelled out and a note on what to skip. If you want the broader ranked list across all clients, see the best MCP servers roundup.
Where LM Studio keeps its MCP config
LM Studio stores MCP servers in a file called mcp.json, editable straight from the app. Open the Program tab in the right-hand sidebar, click Edit mcp.json, and add servers under an mcpServers key — the same shape Claude Desktop uses.
A minimal local (stdio) entry looks like this:
{
"mcpServers": {
"anyquery": {
"command": "anyquery",
"args": ["mcp", "--stdio"]
}
}
}
Remote servers use a url field instead of command. LM Studio prompts you to confirm each tool call the first time, which matters because a local model with filesystem access can do real damage — treat that prompt as a firewall, not a nuisance. If you'd rather not hand-write JSON, our config generator emits the right block per client.
Mind the tool budget before you add anything
Add servers conservatively: most local models degrade past roughly 40 exposed tools, and a single big server can eat half that alone. Every tool definition is tokens in the context window and one more option the model can pick wrong. A 7B or 8B model running locally is far more likely to call the wrong tool than GPT-class models, so tool sprawl hurts you twice — accuracy and latency.
The GitHub MCP Server alone exposes dozens of tools across repos, issues, PRs, and Actions. Enable its toolsets selectively rather than loading everything. This is the same math we work through in the Cursor tool-limit breakdown — the reasoning is identical for a local client.
Rule of thumb: two or three focused servers beat one everything-server. If a model starts calling tools that don't exist or looping, you're over budget.
The three servers worth adding first
Start with code, structured data, and live docs — that trio covers the majority of real local-model workflows.
- GitHub MCP Server — GitHub's official server for repos, issues, PRs, and Actions. Run it as a local Docker container or point at the hosted remote. Turn on only the toolsets you need; the full surface is large.
- Anyquery — runs SQL over your files, local databases, and 40+ apps (GitHub, Notion, Chrome, Todoist), then exposes them to the model over MCP. It's the single best way to give a local model structured data without writing a bespoke server. Ships as a native binary, no runtime to babysit.
- GitMCP — a free remote server that turns any GitHub repo into a live documentation source. This is the cheapest fix for the biggest local-model failure mode: hallucinated APIs. Point it at a library's repo and the model reads real docs instead of guessing.
Official-vs-community matters here. GitHub's server is maintained by GitHub; the others are community or vendor-built but active. Prefer official when it exists, and read the source before granting write access.
Situational picks — add only if you need them
These earn a slot when your workflow demands it, not by default. Each one is genuinely good, but each one also spends tool budget you may not have.
| Server | Best for | Transport | Watch out for |
|---|---|---|---|
| Octocode | Deep code research across GitHub, local FS, and LSP | stdio (local) | Tool-heavy; overkill for small repos |
| Package Registry MCP | Current versions across NPM, PyPI, crates.io, NuGet, Go + security advisories | stdio (local) | Narrow; only useful mid-dependency-work |
| Graphlit MCP Server | RAG over Slack, Drive, Jira, Linear, GitHub | remote / hosted | Requires a Graphlit account and cloud data |
Octocode is the pick if you do a lot of cross-repo reading — it wires GitHub, your local filesystem, and LSP intelligence into one research surface. Package Registry MCP is worth it only while you're actively managing dependencies, when the model needs current version numbers and Security Advisories instead of stale training data. Graphlit is the one to add if your knowledge lives in Slack and Drive, but it sends data to a hosted service — a real trade-off for a setup you chose specifically to run locally.
What to skip
Skip anything with a huge tool surface you won't use, and skip remote servers if the whole point of LM Studio was keeping data local. Roughly 90% of MCP servers run locally over stdio, so you rarely need a remote one — the exceptions above (GitMCP, Graphlit) earn it by being remote-only or truly hosted.
Also skip the temptation to install five coding servers at once. GitHub, Octocode, and Package Registry overlap; pick the one that matches how you actually work. For a client-agnostic view of the strongest coding options, see the best MCP servers for coding agents.
Finally, skip write-enabled servers until you trust the model's tool selection on your setup. Read-only first, writes later.