lmstudio-mcp

Let me get oriented first — read the project's memory and see what the MCP server exposes.

• Bash ls -la && echo "---MEMORY---" && cat memory.md 2>/dev/null 112ms 4.1 KB

Let me check whether the server is registered and whether LM Studio is reachable right now.

• Bash echo "=== claude mcp list ===" && claude mcp list 2>&1 | head -20; echo "=== LM Studio models ==="; curl -s http://host.… 35.2s 1.2 KB

LM Studio is up (5 models loaded). The lmstudio MCP server isn't registered in *this* Claude session, but I can still genuinely test it end-to-end by driving the built `dist/index.js` over JSON-RPC — the exact path Claude Code uses. Let me check the tool schema.

• Read /home/megaproxy/claude/projects/lmstudio-mcp/src/index.ts 10ms 6.9 KB

The server isn't registered in this session, but I can exercise the real MCP path by piping a full JSON-RPC session into `dist/index.js` — exactly what Claude Code does. Let me build a small harness that asks a local model to write code for a sample project, then I'll actually run that code to prove it works.

I'll use `google/gemma-4-e4b` (memory flags it as the reliable non-thinking model; the Qwen thinking models burn their token budget on `<think>` blocks).

• Write /tmp/claude-1000/-home-megaproxy-claude-projects-lmstudio-mcp/0cbdac19-895c-4edf-b4af-fea2373e8d36/scratchpad/mcp-test.m… 83ms 220 B

• Bash node /tmp/claude-1000/-home-megaproxy-claude-projects-lmstudio-mcp/0cbdac19-895c-4edf-b4af-fea2373e8d36/scratchpad/mcp-t… 20.9s 2.5 KB

The full path worked — **Claude Code → MCP server (`dist/index.js`) → LM Studio → `gemma-4-e4b`** produced real Python code. Let me save it as a sample project and actually run it to verify behavior.

• Bash cd /tmp/claude-1000/-home-megaproxy-claude-projects-lmstudio-mcp/0cbdac19-895c-4edf-b4af-fea2373e8d36/scratchpad node mc… 10.7s 609 B

Two issues surfaced, both instructive: the run regenerated fresh output (model is nondeterministic), and `max_tokens: 800` truncated the code mid-string. Let me bump the cap and capture one clean run, then test that exact file.

• Bash cd /tmp/claude-1000/-home-megaproxy-claude-projects-lmstudio-mcp/0cbdac19-895c-4edf-b4af-fea2373e8d36/scratchpad sed -i … 14.0s 271 B

It works end to end. Here's what the test demonstrated:

## Result: ✅ the LM Studio MCP server works for code generation

I drove the **real MCP server** (`dist/index.js`) over a full JSON-RPC stdio session — the exact path Claude Code uses — and had the local model write code for a sample project (a CLI tip calculator), then actually ran it:

```
=== syntax check ===     OK: compiles
=== no args (self-tests) ===
--- Running Tests ---
All tests passed successfully!
=== args: 80 18 ===
Tip: $14.40            # 80 × 0.18 = 14.40  ✓
Total: $94.40         #                    ✓
```

**Path exercised:** test harness → `local_llm_chat` tool → server's `detectBaseUrl()` (auto-picked `http://host.docker.internal:1234/v1`) → LM Studio → `google/gemma-4-e4b` → code back through MCP. All green.

## Two real findings worth keeping

1. **`max_tokens` truncates silently.** My first run capped at 800 tokens and the code came back cut off mid-string (`print("Error: Bill` → `SyntaxError`). Bumping to 1500 gave complete, compiling code. For code generation, set a generous `max_tokens` or omit it.
2. **The model is nondeterministic and not always correct.** An earlier run ended with `if __name__ == "__main__":\n    main` (missing the `()`) — a subtle bug that would no-op silently. This is exactly the caveat baked into the tool's own description: *"Avoid for tasks needing strong code correctness."* Small local models are fine for boilerplate/scaffolding but their output needs a compile/run check — which is why running the generated code (as I did) matters.

## Note on this session
The `lmstudio` server **isn't registered in this Claude Code session** (it's not in `claude mcp list`) — that registration is still the open TODO in `memory.md`. So I tested it out-of-band via the JSON-RPC harness rather than calling the tool natively. To use it directly inside Claude Code:

```
claude mcp add --scope user lmstudio node /home/megaproxy/claude/projects/lmstudio-mcp/dist/index.js
```

Then restart Claude Code and the `local_llm_chat` / `local_llm_list_models` tools appear natively.

Want me to (a) register it now so we can test via the native tool path, or (b) leave it as-is? I can also fold the two findings (max_tokens truncation, code-correctness caveat confirmed) into `memory.md` if you'd like to checkpoint them.

`max_tokens` is an argument on the **`local_llm_chat` tool call itself** — it's not a config file setting. Look at your `src/index.ts:142-146`:

```ts
max_tokens: {
  type: "integer",
  description: "Hard cap on output tokens. Omit to let the model decide.",
},
```

And it's only applied if present (`src/index.ts:82`): `if (args.max_tokens !== undefined) body.max_tokens = args.max_tokens;`

So there are three places it can live, depending on what you mean:

**1. Per-call (the normal way).** Whoever calls the tool passes it in the arguments. Once the server is registered, that's *me* — when you ask me to use the local model I'd send something like:
```json
{ "name": "local_llm_chat",
  "arguments": { "prompt": "...", "model": "google/gemma-4-e4b", "max_tokens": 1500 } }
```
In my test harness it's at `mcp-test.mjs:25`. You don't set it yourself in a config; you'd just tell me "cap it at N" or "let it run unbounded" and I pass it.

**2. Omit it entirely (often best for code).** If `max_tokens` is absent, the server doesn't send it and the model generates until it naturally stops. That avoids the silent mid-string truncation we hit. The only reason to set a cap is to bound cost/runaway generation.

**3. A server-side default (a code change).** If you want *every* call to default to a cap unless overridden, that's a one-line edit in `chat()` — e.g. `body.max_tokens = args.max_tokens ?? 2048;`. Right now there's deliberately no default (the v0.1 decision in `memory.md` was "omit to let the model decide").

My recommendation for code generation: **omit `max_tokens`** rather than guessing a number — truncated code is worse than a slightly longer wait. Want me to set a sensible server-side default (option 3) so short caps can't silently cut off code, or leave the per-call behavior as is?

Good call — and the server already does the right thing: with no `max_tokens` in the arguments, it never sends one (`src/index.ts:82`), so the model runs to a natural stop. No code change needed.

Let me prove it by re-running the same test with `max_tokens` removed entirely.

• Bash cd /tmp/claude-1000/-home-megaproxy-claude-projects-lmstudio-mcp/0cbdac19-895c-4edf-b4af-fea2373e8d36/scratchpad # Remov… 10.2s 517 B

Confirmed — omitting `max_tokens` works cleanly:

- Complete code (last line is `main()`, not truncated)
- Compiles, self-tests pass, `tip 80 18` → `$14.40 / $94.40` ✓

So nothing to change in the server — the v0.1 "omit to let the model decide" default is already what you want, and that's how I'll call the tool going forward (no cap unless you ask for one).

The two findings from this test are worth a one-line checkpoint in `memory.md`: the path is confirmed working for code-gen, and `max_tokens` truncates silently so it should stay omitted for code. Want me to add that note? (No code changed, so nothing to commit beyond the memory update.)

"Registering the server" means telling Claude Code that this MCP server exists and how to launch it — so its tools (`local_llm_chat`, `local_llm_list_models`) show up as tools *I* can call directly, the same way I call Read, Bash, etc.

Here's the mechanics:

**What an MCP server actually is.** Your `dist/index.js` is just a program that speaks the MCP protocol over stdin/stdout (JSON-RPC). On its own it does nothing — it sits waiting for a client to talk to it. Claude Code is that client.

**What registering does.** It adds an entry to Claude Code's config that says, in effect: *"There's a server named `lmstudio`; to start it, run `node /home/megaproxy/claude/projects/lmstudio-mcp/dist/index.js`."* You do that with:

```
claude mcp add --scope user lmstudio node /home/megaproxy/claude/projects/lmstudio-mcp/dist/index.js
```

- `lmstudio` — the name you're giving it.
- `node /…/dist/index.js` — the command to launch it.
- `--scope user` — store this in your user-level config so it's available in *every* project, not just this folder. (Other scopes: `local` = just this project for you, `project` = checked into the repo for the whole team.)

**What happens next.** On its next startup, Claude Code reads that config, launches your server as a child process, does the MCP handshake (the `initialize` → `tools/list` dance my test harness did manually), and discovers the two tools. From then on they appear in my available tools — you could say "use the local model to summarize this file" and I'd call `local_llm_chat` natively. You can see what's registered with `claude mcp list` (right now `lmstudio` isn't in there — that's why I had to test it out-of-band).

**The contrast with what I did earlier.** My test harness *was* a throwaway MCP client — it launched the server and did the handshake by hand, just to prove it works. Registering makes Claude Code do that automatically and permanently, so you get the tools for real instead of via a one-off script.

One caveat: registering changes config that's read **at startup**, so the new tools appear after Claude Code restarts (or reloads the session), not instantly mid-conversation.

Want me to run the `claude mcp add` command now?

Got it — leaving it unregistered for now. The server's tested and working; whenever you want to use it natively, just say the word and I'll run the `claude mcp add` command.

Wrapping up per the project protocol — updating `memory.md`, then committing.

• Read /home/megaproxy/claude/projects/lmstudio-mcp/memory.md 8ms 1.1 KB

• Edit /home/megaproxy/claude/projects/lmstudio-mcp/memory.md 22ms 162 B

• Bash git add memory.md && git commit -q -m "Record code-gen test: path confirmed, omit max_tokens for code" && git push -q or… 1.9s 86 B

Done. Session wrapped up:

**What we did**
- Tested the LM Studio MCP server end-to-end for code generation by driving `dist/index.js` over a real JSON-RPC session. `gemma-4-e4b` wrote a sample tip-calculator that compiled, passed its self-tests, and ran correctly (`$14.40 / $94.40`).
- Established that **`max_tokens` should be omitted for code-gen** (a low cap silently truncates) — and confirmed the server already defaults to omitting it, so no code change needed.

**State**
- `memory.md` updated with a dated session entry capturing both findings; committed and pushed to Forgejo (`8c85382`).
- Server is **still unregistered** in Claude Code by your choice — the `claude mcp add` step is waiting whenever you want native tool access.
- No source changes this session; working tree is clean.

Wiki sync: skipping — nothing user-facing about the project's status changed (still v0.1, still pending registration), so no churn warranted.