A
licenseB
qualityF
maintenanceBridges Claude AI with Xcode, enabling AI-powered code assistance, project management, and automated development tasks securely on your local machine.
76
234
385
MIT
mlx-mcp-server
Allows using Ollama as a backend for local LLM inference, supporting chat and diagnostic tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mlx-mcp-serverask my local model to summarize this article"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Mlx Mcp Server
MCP server bridging Claude to local MLX LM (and any OpenAI-compatible backend)
AI automation consulting — I help businesses replace painful manual processes with LLM-powered pipelines and workflow automation.
Overview
mlx-mcp-server is a Model Context Protocol server that bridges Claude to a local LLM (MLX LM on Apple Silicon, or any OpenAI-compatible /v1 backend) so Claude can hand off eligible work to a free, private model instead of spending paid tokens.
Rather than a plain pass-through, it enforces an offload-first policy: its headline iterate tool runs a self-correcting escalation ladder — retry locally against a gate, step up to a bigger local model, and only escalate to Claude when the local rungs are exhausted. The result is lower token cost and more privacy for routine work (summarizing, extracting, classifying, boilerplate, single-file review), while Claude stays focused on multi-file reasoning and judgment calls.
Related MCP server: LMStudio-MCP
Features
Offload-first, token-thrift — routes eligible work (summarize, extract, classify, boilerplate, single-file review, first drafts) to a free, private local model before spending paid Claude tokens.
Self-correcting
iterateladder — retries locally, then a bigger local model, then escalates to Claude; free rungs are exhausted before any paid work.Gated retries — structural gates (
require_json/schema_keys/contains/regex/min_len) and an executable gate (run a linter or test against$CANDIDATE_FILE) let the local model fix its own output.Runtime model switching — swap the active model by name or fuzzy fragment with no Claude restart; choice persists across restarts.
Work-hours guard — optionally blocks large (>22 GB RAM) models during work hours to avoid swap thrashing.
One-step install — wires the MCP server and slash commands (
/switch-model,/mlx-help) into Claude Code or Claude Desktop.Backend-agnostic — works with MLX LM or any OpenAI-compatible
/v1endpoint; content-free usage metrics, MIT licensed, tested and CI'd.
Getting Started
Requires Python 3.11+ and a running OpenAI-compatible LLM backend (MLX LM on Apple Silicon is recommended).
pip install mlx-mcp-server
mlx-mcp-server install --claude-code --with-commands # wire into Claude Code, then restart ClaudeSee Usage for backend setup, configuration, and the full tool reference.
Usage
1. Start a local LLM backend
The server talks to any OpenAI-compatible /v1 endpoint. On Apple Silicon, MLX LM is recommended:
pip install mlx-lm
mlx_lm.server --model mlx-community/Qwen2.5-Coder-14B-Instruct-4bit # serves on http://localhost:8080Any other OpenAI-compatible backend works too (e.g. Ollama on Linux/Intel — point MLX_BASE_URL at http://localhost:11434).
2. Install and wire it into Claude
pip install mlx-mcp-server
# One-step setup for Claude Code (also installs the /switch-model + /mlx-help slash commands)
mlx-mcp-server install --claude-code --with-commands
# ...or Claude Desktop
mlx-mcp-server install --with-commands
# Preview the config without writing anything
mlx-mcp-server install --claude-code --dry-runThe installer writes an mlx entry into your Claude config (~/.claude/settings.json for Claude Code, or the Claude Desktop config). Restart Claude afterward to load the server. Verify the backend is reachable with the health_check tool, or run mlx-mcp-server help for the full CLI reference.
3. How Claude uses it — offload-first
The whole point is token thrift: Claude routes eligible work (summarize, extract, classify, reformat, boilerplate, single-file review, simple refactors, first drafts) to your free, private local model before spending paid tokens. The headline tool is iterate, which runs a self-correcting escalation ladder:
local model retries (feeding each gate failure back in) → a bigger local model → escalate to Claude
Free rungs are exhausted before any paid work happens. You attach a gate so the local model can self-correct:
Structural gates (cheap, content-free):
require_json,schema_keys,contains,regex,min_lenExecutable gate:
check_command— a shell command that sees the candidate at$CANDIDATE_FILEand exits0to pass (e.g. a linter or test)
With no gate, iterate runs a single local attempt and asks Claude to verify.
# Generate boilerplate, gated by a linter — retries locally until ruff is happy
iterate(message="write a Python slugify() function",
category="boilerplate",
check_command="ruff check $CANDIDATE_FILE")
# Extract structured data, gated on valid JSON with required keys
iterate(message="extract name, email, company from this signature: ...",
category="extract",
require_json=true,
schema_keys=["name", "email", "company"])
# Quick one-off to the local model, no iteration
chat(message="explain what this regex does: ^\\d{3}-\\d{4}$")Tools
Tool | What it does |
| Offload a task with a gate; retries locally, then a bigger local model, then escalates to Claude |
| Send a single prompt to the local model and get the response + token usage |
| Run a canned diagnostic ( |
| List loaded models with speed/quality descriptions and the active marker |
| Switch the active model at runtime by name or fuzzy fragment — no restart needed |
| Confirm the backend is reachable |
| Block large (>22 GB RAM) models Mon–Fri 8am–5pm MT to avoid swap thrashing |
| Show current config (URL, active model, guard state) — resource |
Inside Claude Code, the bundled slash commands give you /switch-model (interactive model picker) and /mlx-help (this reference).
Configuration
Set as env vars in the MCP server entry (the installer scaffolds these):
Variable | Default | Notes |
|
| Backend |
| (empty) | Optional — auto-detected from |
| (empty) | Optional, for secured backends |
|
| Request timeout in seconds |
Development
# Install dev dependencies
pip install -r requirements-dev.txt # if present
# Run tests
pytest -qLicense
MIT — see LICENSE.
Built and maintained by Brice — Observability Engineer at Grafana Labs / AI Automation Consultant. See more at github.com/deresolution20.
Available Tools
4 toolschatB
Send a message to the local LLM and return the response with token usage.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| system_prompt | No | ||
| temperature | No | ||
| max_tokens | No | ||
| top_p | No | ||
| top_k | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must cover behavior. It mentions returning response with token usage, but doesn't discuss side effects, authentication, or rate limits. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to provide context for parameters. For a tool with 6 parameters and no schema descriptions, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any of the 6 parameters. This is a critical gap, as parameters like temperature, max_tokens, etc., need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sends a message to the local LLM and returns response with token usage. Distinct from sibling tools like health_check or list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use or alternatives provided. However, context from siblings suggests this is the primary chat tool, so usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
health_checkA
Check whether the configured LLM backend is reachable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is straightforward and discloses the tool's action: checking reachability. No annotations are provided, but the behavior is simple and non-destructive; no additional behavioral traits are necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. Every word is meaningful; no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no side effects, and an output schema likely covering return values), the description is complete enough for an agent to understand its purpose and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description does not need to add parameter information. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking connectivity to the LLM backend. It uses a specific verb ('Check') and resource ('the configured LLM backend'), and is distinct from sibling tools like 'chat' or 'list_models'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context from sibling tools suggests it is used for pre-flight checks, but the description does not mention this explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsA
List available models on the configured backend.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it clearly states a read operation without side effects, which is transparent enough for a simple list tool, though it does not mention rate limits or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no unnecessary words, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no parameters, and presence of an output schema, the description is complete enough, covering what models and where.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is effectively 100%. The description adds no param info beyond the schema, but the baseline for 0 parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'available models' with context 'on the configured backend', clearly distinguishing it from sibling tools like chat, health_check, and quick_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing models but provides no explicit instructions on when to use it versus alternatives or when not to use it. It assumes the agent knows the tool's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quick_testB
Run a predefined diagnostic prompt to sanity-check the loaded model.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| test_type | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states it runs a diagnostic prompt, implying no side effects, but doesn't disclose if tests are stateless or have restrictions. Adequate but lacks depth on behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key info, no waste. Perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one enum parameter, output schema exists), the description is minimal but adequate for basic use. However, it doesn't explain the purpose of each test type, leaving the agent to rely solely on enum names. Could be more complete for a new user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not mention the lone parameter 'test_type' or its enum values. The schema provides the enum, but with 0% schema description coverage, the description should explain what each test type does. It fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a diagnostic prompt to sanity-check the model, with a specific verb and resource. The enum values for test_type add specificity, but the description doesn't distinguish from sibling tools like 'chat' or 'health_check', missing a clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description implies it's for sanity checking, but doesn't mention when not to use it or compare to siblings like 'chat' or 'health_check'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
chat - First observed
health_check - First observed
list_models - First observed
quick_test
TDQS
A3.7/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: chat for conversation, health_check for backend connectivity, list_models for available models, and quick_test for a diagnostic check. No overlap.
Naming Consistency3/5
Tool names use different patterns: chat is a bare verb, health_check is noun_verb, list_models is verb_noun, and quick_test is adjective_noun. While readable, there is no consistent convention.
Tool Count5/5
With 4 tools, the server is well-scoped for its purpose of local LLM interaction. Each tool serves a necessary function without bloat.
Completeness4/5
Core interactions (chat, health, model listing, diagnostic) are covered. Minor gaps exist, such as lack of model configuration or streaming support, but the set is sufficient for basic use.
Maintenance
ActivityMaintained
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- QuallaaOAuthcom.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA bridge that allows Claude to communicate with locally running LLM models via LM Studio, enabling users to leverage their private models through Claude's interface.168MIT
- AlicenseCqualityDmaintenanceBridges Claude Desktop with local LLM instances running via llama-server, enabling full conversation support with complete parameter control and health monitoring. Allows users to chat with their local models directly through Claude Desktop with configurable sampling parameters.3229Creative Commons Zero v1.0 Universal
- AlicenseNot gradedqualityCmaintenanceThe self-hosted MCP bridge between Claude Chat and Claude Code.46AGPL 3.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deresolution20/mlx-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server