How do I use LM Studio MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LM Studio MCP Server list available models" 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.

LM Studio MCP Server

by seajhawk

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

LM Studio MCP Server

A Model Context Protocol (MCP) server for LM Studio that enables model management through standardized tools.

Features

📋 List Models - View all available models and their current state
🚀 Load Models - Load models into memory with configurable TTL
🛑 Unload Models - Immediately unload models from memory
⚙️ Configure Models - Adjust model settings like TTL and draft models
📊 Model Details - Get detailed information about specific models

Related MCP server: LM Studio MCP Bridge

Prerequisites

Node.js >= 18.0.0
LM Studio running with local server enabled
LM Studio local server running on port 1234 (default) or custom port

Installation

npm install
npm run build

Quickstart (Build & Run)

Follow these steps to build and run the MCP server locally.

Install dependencies and build the project:

npm install
npm run build

Start the server (uses the compiled files in dist):

npm start

The server writes MCP communication to stdout and logs to stderr.

Environment variable tips:

Default LM Studio URL: http://localhost:1234.
To use a custom LM Studio URL, set LM_STUDIO_BASE_URL before starting.

PowerShell (Windows) example:

$env:LM_STUDIO_BASE_URL = "http://localhost:1234"
npm start

Command Prompt (Windows) example:

set LM_STUDIO_BASE_URL=http://localhost:1234 && npm start

macOS / Linux example:

LM_STUDIO_BASE_URL="http://localhost:1234" npm start

Development workflow:

Rebuild on change (in one terminal): npm run watch
Run the server (in another terminal): npm run dev (starts Node with the inspector)

You can also run the compiled script directly with node dist/index.js if preferred.

Configuration

LM Studio Setup

Open LM Studio
Go to the Developer tab
Enable the local server (default port: 1234)
Optionally enable "Serve on Local Network" if accessing remotely

Environment Variables

LM_STUDIO_BASE_URL - Base URL for LM Studio API (default: http://localhost:1234)

Usage

With Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "lmstudio": {
      "command": "node",
      "args": ["/path/to/lmstudio-mcp/dist/index.js"],
      "env": {
        "LM_STUDIO_BASE_URL": "http://localhost:1234"
      }
    }
  }
}

With Other MCP Clients

Run the server directly:

node dist/index.js

The server communicates over stdio following the MCP protocol.

Available Tools

`list_models`

List all available models with their current state (loaded/not-loaded).

Parameters: None

Example Response:

[
  {
    "id": "lmstudio-community/Meta-Llama-3-8B-Instruct-GGUF",
    "type": "llm",
    "publisher": "Meta",
    "architecture": "llama",
    "state": "loaded",
    "max_context_length": 8192
  }
]

`get_model_details`

Get detailed information about a specific model.

Parameters:

model_id (string, required) - The ID of the model

Example:

{
  "model_id": "lmstudio-community/Meta-Llama-3-8B-Instruct-GGUF"
}

`load_model`

Load a model into memory with configurable Time-To-Live.

Parameters:

model_id (string, required) - The ID of the model to load
ttl (number, optional) - Time-To-Live in seconds before auto-unload (default: 3600)

Example:

{
  "model_id": "lmstudio-community/Meta-Llama-3-8B-Instruct-GGUF",
  "ttl": 7200
}

`unload_model`

Unload a model from memory immediately.

Parameters:

model_id (string, required) - The ID of the model to unload

Example:

{
  "model_id": "lmstudio-community/Meta-Llama-3-8B-Instruct-GGUF"
}

`configure_model`

Configure model settings such as TTL and draft model for speculative decoding.

Parameters:

model_id (string, required) - The ID of the model to configure
ttl (number, optional) - Time-To-Live in seconds
draft_model (string, optional) - Draft model ID for speculative decoding

Example:

{
  "model_id": "lmstudio-community/Meta-Llama-3-8B-Instruct-GGUF",
  "ttl": 1800,
  "draft_model": "small-draft-model"
}

How It Works

LM Studio uses JIT (Just-In-Time) model loading. Models are loaded on-demand when inference requests are made:

Loading: Making an inference request automatically loads the model with the specified TTL
Unloading: Models auto-unload after TTL expires, or immediately when TTL is set to 0
Configuration: Model settings are applied through inference request parameters

Development

Build

npm run build

Watch Mode

npm run watch

Debug

npm run dev

API Reference

This server interfaces with the LM Studio Developer API:

GET /api/v0/models - List all available models
GET /api/v0/models/{model} - Get model details
POST /api/v0/chat/completions - Used for loading/configuring models

Troubleshooting

Connection Refused

Ensure LM Studio is running
Verify the local server is enabled in Developer settings
Check that port 1234 (or custom port) is accessible

Model Not Found

Verify the model ID is correct using list_models
Ensure the model is downloaded in LM Studio

Model Won't Load

Check available system memory
Verify model compatibility with your system
Review LM Studio logs for errors

License

MIT

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Available Tools

5 tools

configure_modelC

Configure model settings such as TTL and draft model for speculative decoding

ParametersJSON Schema

Name	Required	Description
`ttl`	No	Time-To-Live in seconds (optional)
`model_id`	Yes	The ID of the model to configure
`draft_model`	No	Draft model ID for speculative decoding (optional)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints at the domain (TTL, speculative decoding) but says nothing about permissions required, whether changes apply immediately or require a reload, whether settings are reversible, or what happens to settings not specified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence with the purpose front-loaded and no filler. It is well-sized, though it is on the thin side for a mutation 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?

For a 3-parameter tool with 100% schema coverage and no output schema, the description plus schema is minimally sufficient to invoke the tool. However, as a mutation with zero annotation coverage, it leaves important behavioral context (side effects, required state, permission needs) unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters including the required model_id and the units for ttl. The description adds no syntax, format, or constraint detail beyond what the schema provides, so the baseline of 3 applies.

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?

States a specific verb (Configure) and resource (model settings) and names two concrete settings (TTL, draft model for speculative decoding). It is clearly distinct from the sibling tools list_models/get_model_details/load_model/unload_model, though it never explicitly contrasts itself with them.

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 versus load_model/unload_model, no prerequisites (e.g. must the model be loaded?), and no indication of when configuring is appropriate or not. Usage must be inferred entirely from the name and schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_model_detailsB

Get detailed information about a specific model including architecture, quantization, and context length

ParametersJSON Schema

Name	Required	Description	Default
`model_id`	Yes	The ID of the model to get details for

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It partially compensates by disclosing what the call returns (architecture, quantization, context length), which substitutes for the absent output schema. However, it says nothing about behavior on an invalid or missing model_id, read-only safety, or any auth requirement.

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?

A single sentence, front-loaded with the verb and resource, with the return contents appended rather than padded out. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a trivial single-parameter read tool with no annotations and no output schema, the description covers purpose and return content well, which compensates for the missing output schema. It stops short of coverage for edge cases (unknown model_id) and routing versus list_models.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema description coverage is 100%, so the schema already defines model_id fully. The description adds no format hints (where the ID comes from, e.g. list_models) beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (get detailed information about a specific model) and enumerates the returned content: architecture, quantization, context length. It implicitly distinguishes itself from list_models by targeting 'a specific' model, but never names the siblings (load_model, unload_model, configure_model) that an agent might confuse it with.

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 when-to-use guidance and no alternatives named. The description never says to use this when you already have a model_id versus calling list_models first, nor how it relates to load/unload/configure. Usage is inferable from the name alone, which is the definition of minimal guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_modelsA

List all available models in LM Studio with their current state (loaded/not-loaded)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. 'List' strongly implies a safe, read-only operation and it discloses the shape of the returned data (models plus loaded/not-loaded state), which is useful since there is no output schema. However, it says nothing about permissions, ordering, or whether the listing can be filtered/paginated.

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 sentence, front-loaded with the verb and resource, with the one extra clause (current state) earning its place by previewing the return content. No waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool with no annotations and no output schema, the description covers purpose, scope, and the essential returned field (load state). It is nearly complete; only the absence of sibling routing guidance keeps it from a 5.

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 takes zero parameters, so the schema cannot add meaning and the description has nothing to disambiguate. Baseline of 4 applies for a parameterless tool.

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?

States a specific verb (List) and resource (models) and adds scope ('all available') plus the returned attribute (loaded/not-loaded state). It implicitly distinguishes itself from get_model_details by being the bulk listing, but never names the sibling, so it stops short of a 5.

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 when-not-to-use guidance. The 'all available models' phrasing implies this is the enumeration entry point versus the single-model siblings (get_model_details, load_model, unload_model, configure_model), but the agent must infer that routing on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

load_modelB

Load a model into memory with configurable Time-To-Live (TTL). The model will auto-unload after the TTL expires.

ParametersJSON Schema

Name	Required	Description	Default
`ttl`	No	Time-To-Live in seconds before auto-unload (default: 3600)
`model_id`	Yes	The ID of the model to load

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the model auto-unloads after the TTL expires, but it does not cover other relevant traits such as whether loading is idempotent, what happens if the model is already loaded, permission requirements, or return behavior.

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 two sentences and front-loads the core purpose. Every sentence adds value: the first states the action and configurability, the second states the auto-unload consequence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool with full schema parameter coverage and no output schema, the description covers the essential purpose and TTL behavior. It is somewhat incomplete regarding edge cases and usage context, but the structured fields carry much of the remaining detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description adds the concept of configurable TTL and auto-unload, but does not add syntax or format details beyond what the schema provides. This matches the baseline of 3 when the schema does the heavy lifting.

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 states a specific verb and resource: load a model into memory. It also introduces the TTL behavior. However, it does not explicitly differentiate itself from siblings such as unload_model or configure_model beyond the natural opposite of loading.

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?

There is no explicit guidance on when to use this tool versus alternatives like list_models, get_model_details, or configure_model. The purpose implies it is for loading models, but no conditions or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unload_modelB

Unload a model from memory immediately by setting its TTL to 0

ParametersJSON Schema

Name	Required	Description	Default
`model_id`	Yes	The ID of the model to unload

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does disclose the mechanism (TTL set to 0) and the effect (immediate removal from memory). However, it does not say whether the action is destructive or reversible, what happens to in-flight requests, or what permissions are needed.

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?

A single tight sentence with the action and mechanism front-loaded; no filler or redundancy.

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?

For a one-parameter tool with no output schema, the description is minimally sufficient, covering what it does and how. It omits the destructiveness/reversibility question, which matters for an operation that pulls a model out of memory, leaving a gap that annotations would normally fill.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single well-documented model_id parameter, so the schema already handles semantics. The description adds no additional detail about the identifier format or source, which is the expected baseline when the schema does the work.

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?

States a specific verb and resource ('unload a model') plus the mechanism ('setting its TTL to 0'), which an agent can readily distinguish from load_model. It stops short of explicitly naming the sibling alternative, so it is clear but not maximally differentiated.

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?

There is no statement of when to use this versus load_model, configure_model, or simply letting a TTL expire naturally. The adverb 'immediately' hints at urgency but provides no explicit conditions or exclusions.

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.

5 tool updatesv0.1.0Sep 13, 2026
- First observedconfigure_model
- First observedget_model_details
- First observedlist_models
- First observedload_model
- First observedunload_model

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-09-13 13:00 across 5 tools

Disambiguation4/5

Tools have largely distinct purposes: list_models for overview, get_model_details for specifics, load/unload for state changes, configure_model for settings. However, load_model and configure_model both involve TTL, and unload_model is essentially a special case of configure_model (TTL=0), creating minor overlap.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: list_models, get_model_details, load_model, unload_model, configure_model. No deviations.

Tool Count5/5

Five tools is well-scoped for model lifecycle management in LM Studio. Each tool covers a distinct operation without redundancy.

Completeness4/5

The surface covers listing, inspecting, loading, unloading, and configuring models, which is solid for model management. Minor gaps include no tool for downloading or deleting model files, but these may be outside the server's scope.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

TokenOracle
com.guffeyholdings
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Finance Monitoring
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238

Related MCP Servers

LM Studio MCP Server
AI & Machine Learning Developer Tools
portertech
A
license
A
quality
D
maintenance
Enables AI assistants to manage LM Studio models, including listing, loading, and unloading models through the LM Studio API.
Updated 7 months ago (2026-02-08 16:58 UTC)
6
14 npm
4
ISC
LM Studio MCP Bridge
AI & Machine Learning RAG Systems
ozwei
F
license
C
quality
D
maintenance
Enables MCP clients to interact with local LLMs via LM Studio, supporting dynamic chat, vision, RAG, file interaction, and model orchestration.
Updated 5 months ago (2026-04-09 00:46 UTC)
28
-
llmstudio-mcp
AI & Machine Learning Agent Orchestration
dam2452
F
license
A
quality
C
maintenance
MCP server that connects LLM agents to a local LM Studio instance, enabling model management, OpenAI-compatible chat completions, text completions, and embeddings through a set of tools.
Updated 2 months ago (2026-07-15 17:43 UTC)
9
1
-
mcp-file-system-lmstudio
AI & Machine Learning Developer Tools
developersorli
A
license
Not graded
quality
C
maintenance
Exposes local LM Studio language models as MCP tools, enabling chat completions and model listing through a local OpenAI-compatible API without requiring API keys.
Updated a month ago (2026-08-22 06:56 UTC)
MIT

LM Studio MCP Server

Features

Prerequisites

Installation

Quickstart (Build & Run)

Configuration

LM Studio Setup

Environment Variables

Usage

With Claude Desktop

With Other MCP Clients

Available Tools

list_models

get_model_details

load_model

unload_model

configure_model

How It Works

Development

Build

Watch Mode

Debug

API Reference

Troubleshooting

Connection Refused

Model Not Found

Model Won't Load

License

Contributing

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`list_models`

`get_model_details`

`load_model`

`unload_model`

`configure_model`