Wire LM Studio to MCP Servers for Files, GitHub and a Browser

Models that run entirely on your own machine can now call real tools instead of just talking about them. Connecting a local model to something like GitHub used to mean creating a personal access token by hand and hoping it landed in the right JSON field. Most of that friction has gone. LM Studio can be connected to three MCP servers, for the filesystem, GitHub and browser control, with a working config for each.

What to have ready

A few things need to be in place before mcp.json gets touched.

LM Studio 0.4.10 or newer. That's the release that added OAuth for MCP servers, and it comfortably covers 0.3.17, where LM Studio first became an MCP host. Updates arrive often, with several point releases a month lately, so grabbing the current version is simplest.

A model that can emit tool calls. Not every local model does it reliably. For a GPU with 20GB of video memory, there are three solid choices:

• Qwen3-Coder-30B-A3B-Instruct has 30B total parameters but only about 3.3B active per token because of its MoE design. In 4-bit it needs roughly 17 to 20GB and offers a 262K context window.
• gpt-oss-20b has a smaller footprint of about 14GB and is noticeably faster, which helps when the card is shared with something else.
• Qwen3.5-9B is the lightest, a dense 9B model needing around 6GB in 4-bit, so a mid-range card has plenty of headroom. It shares the Coder model's 262K native context, calls tools natively with a respectable BFCL-V4 score and is the model loaded in the screenshots here. It's the right place to start if it's unclear whether the card can handle the bigger two.

Base models without instruct or chat tuning mostly won't produce structured tool calls at all. If a model card says nothing about tool use or function calling, pick an instruct variant instead.

Node.js 18 or newer. Both the filesystem server and the browser-control server launch through npx. Check the version first:

node --version

Anything beginning with v18 or higher works. If the command isn't found, Node isn't installed, and npx won't exist either. A second quick check covers npx itself:

npx --version

It ships with Node, so it nearly always passes when the first check did, but it's a cheap sanity test before relying on it for the filesystem and browser configs.

None of that confirms LM Studio's own version. The title bar at the top of the app shows it, and it should read 0.4.10 or later.

The screenshot above shows an installation reporting 0.4.23 in the title bar, the current release at the time.

Opening the config file

Open the Integrations tab in LM Studio's right sidebar, click Install, then Edit mcp.json. That's the editor where each server gets its entry.

Config 1: filesystem

With this entry, finding out what a folder contains stops being a copy-paste chore and becomes a single prompt. The official filesystem server lets the model read, write, search and list directories, but only inside the paths you grant.

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

Swap /Users/you/projects for the folder the model should explore. More paths can be added. Anything outside them is hidden from it, and that restriction is the point. Two parts of the entry matter:

• command and args amount to running npx -y @modelcontextprotocol/server-filesystem followed by the allowed directory, as a subprocess LM Studio manages.
• The allowed-directory argument defines the full boundary of what the model can reach. A project that spans several folders can list them one after another.

After saving, LM Studio detects the new entry. Load a model that supports tool calls (Qwen 3.5 9B is fine), begin a fresh chat and switch on mcp/filesystem in the sidebar.

A good first test is a request to find a TODO.md file under the projects folder and summarize the remaining work. The model runs list_directory and read_file by itself. Before each call executes, LM Studio raises a confirmation dialog, and it's wise to keep reading those, because a local model holding write access to a disk shouldn't run unattended.

Config 2: GitHub

This config requires LM Studio 0.4.10 or later. GitHub's remote MCP endpoint lacks Dynamic Client Registration, which is how a client would normally register itself for OAuth on its own. The consequence is that an OAuth app must be created by hand first. LM Studio isn't special in this respect, as VS Code and GitHub's Copilot CLI face the identical limit. Setup runs about two minutes:

1. Open github.com/settings/developers, choose OAuth Apps and click New OAuth App.
2. Enter any name and homepage URL, since they don't matter here. Set the Redirect URI to exactly http://127.0.0.1:33389/mcp-oauth-callback.
3. Press Register application and then generate a new client secret on the next page. Keep the Client ID and the secret somewhere safe, since the secret is displayed a single time.

With both values in hand, the config looks like this:

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/",
      "auth": {
        "CLIENT_ID": "<your Client ID>",
        "CLIENT_SECRET": "<your client secret>"
      }
    }
  }
}

Save the file, enable the server, then press Authenticate followed by Trust, and Open in Browser. A browser window opens on GitHub's OAuth page. Once access is granted with Authorize <username> at the page bottom, the token is stored like it would be for any other OAuth-backed server.

The GitHub consent page offers only approve or deny, with no scope picker. Finer control lives inside LM Studio instead. Open the Integrations panel and find the Tools list belonging to the mcp/github server. Each tool it exposes is listed on its own, among them create_pull_request, delete_file, push_files and merge_pull_request, with dozens beyond, and each one has a checkbox and an Ask or Allow switch.

That list deserves a minute. Uncheck anything the model shouldn't touch, with delete_file and push_files the obvious first candidates if the goal is only reading and summarizing.

In the final screenshot of this group, get_me was invoked once and search_repositories twice against live GitHub, with correct filtering on creation and update dates. Read-only tools and the model's own repos remain ticked, while destructive tools such as delete_file and push_files are unticked.

Config 3: browser control

This config gives a local model the ability to inspect a live web page rather than guess from training data. The Playwright MCP server runs a real browser and supplies structured page content in place of screenshots, which lets even a small local model navigate and extract text dependably.

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

Two things to know before pasting it in. The server opens a visible browser window by default, called headed mode, and the --headless flag in the config turns that off. On a machine with a display, removing the flag lets you follow the model's clicks live, handy when a selector acts up. Node 18 or newer applies here too, as with Config 1, and the first run may offer to download browser binaries through npx playwright install if they're missing.

A simple test is asking the model to open the Hacker News front page and summarize the five top stories. It runs browser_navigate, then reads the page's accessibility tree for titles and links, with no vision model or screenshot parsing in the loop.

Browser automation that deliberately resists fingerprinting, for research or OSINT-style work, is a different job. Camoufox-based servers such as Camofox-MCP cover it. This config is the generic baseline.

Troubleshooting

These are the likeliest problems, roughly from most to least common.

The model never makes tool calls. The usual cause is a base or completion model loaded where an instruct or chat-tuned one belongs. Read the model card, and if tool use or function calling isn't mentioned, replace it. Qwen 3.5 9B is a strong local pick for tool calling.

The server doesn't appear in the chat sidebar after an mcp.json edit. Reload the server list from the Program tab first, and if that doesn't help, restart LM Studio fully. A file edited directly on disk, and not in the in-app editor, seems more prone to needing that restart.

Broken tool-call JSON or invented arguments. Lower the sampling temperature, as tool calling is among the few tasks where a creative setting hurts. Confirm too that the context length is at least 4096 tokens. Tool schemas consume context quickly, GitHub's large toolset most of all, and a tight window is a common hidden reason for truncated calls.

What you end up with

The result is three servers, no API calls and a local model able to read the filesystem, work on a real GitHub repo and drive a live browser, with every call checked and approved in LM Studio's confirmation dialogs and none running unsupervised.

On its own that's a useful local agent, and it forms the base for a full autonomous workflow. The sensible next move is joining the three servers into one agent loop, rather than driving each with separate prompts.

Reference docs

The LM Studio docs on using MCP servers and on MCP integrations with OAuth define the command, args, url and auth shapes used throughout. The GitHub MCP server repo and GitHub's setup documentation cover Config 2, the official modelcontextprotocol filesystem server covers Config 1, and the microsoft/playwright-mcp repo documents the headed-by-default behavior and flags for Config 3.