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., "@LM Studio MCP Server list downloaded 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.
An MCP (Model Context Protocol) server that provides AI assistants with control over LM Studio models. This server enables remote model management including listing, loading, and unloading models through the LM Studio API.
Health Check: Verify connectivity to LM Studio
List Downloaded Models: View all LLM models available in your LM Studio library
List Loaded Models: See which models are currently loaded in memory
Load Models: Load models into memory with configurable parameters
Unload Models: Remove specific model instances from memory
Get Model Info: Retrieve detailed information about loaded models
Related MCP server: Ollama MCP Server
Node.js 18.0.0 or higher
LM Studio running with the local server enabled
# Clone the repository
git clone <repository-url>
cd lm-studio-mcp-server
# Install dependencies
npm installThe server connects to LM Studio using environment variables:
Variable | Default | Description |
| (derived) | Full WebSocket URL for LM Studio |
|
| LM Studio host (used if BASE_URL not set) |
|
| LM Studio port (used if BASE_URL not set) |
Development (uses tsx for TypeScript execution):
npm start
# or with file watching
npm run devProduction (uses compiled JavaScript):
npm run build
npm run start:prodDocker:
# Pull the published image
docker pull portertech/lm-studio-mcp-server:latest
# Run (connects to LM Studio on host machine)
docker run -i --rm portertech/lm-studio-mcp-server:latest
# Run with custom LM Studio host
docker run -i --rm \
-e LMSTUDIO_HOST=192.168.1.100 \
-e LMSTUDIO_PORT=1234 \
portertech/lm-studio-mcp-server:latestAdd to your claude_desktop_config.json:
Using npx (recommended for installed packages):
{
"mcpServers": {
"lmstudio": {
"command": "npx",
"args": ["@portertech/lm-studio-mcp-server"],
"env": {
"LMSTUDIO_HOST": "127.0.0.1",
"LMSTUDIO_PORT": "1234"
}
}
}
}Using local development:
{
"mcpServers": {
"lmstudio": {
"command": "npx",
"args": ["tsx", "/path/to/lm-studio-mcp-server/src/index.ts"],
"env": {
"LMSTUDIO_HOST": "127.0.0.1",
"LMSTUDIO_PORT": "1234"
}
}
}
}Using Docker:
{
"mcpServers": {
"lmstudio": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"LMSTUDIO_HOST=127.0.0.1",
"-e",
"LMSTUDIO_PORT=1234",
"portertech/lm-studio-mcp-server:latest"
]
}
}
}Note: For Docker on macOS/Windows connecting to LM Studio on the host machine, use
LMSTUDIO_HOST=host.docker.internal.
All tools return a consistent response envelope:
{
success: boolean;
message: string;
data?: T; // Present on success
error?: { // Present on failure
code: string;
message: string;
};
}Code | Description |
| Requested model does not exist |
| Model is not currently loaded |
| Cannot connect to LM Studio |
| Invalid parameters provided |
| Failed to load model |
| Failed to unload model |
| Unexpected error |
health_checkCheck connectivity to LM Studio server.
Parameters: None
Returns: Connection status and base URL
list_modelsList all downloaded LLM models available in LM Studio.
Parameters: None
Returns: Array of model info objects with:
modelKey: Model identifier for loading
path: Relative path to the model
displayName: Human-readable model name
sizeBytes: Size in bytes
architecture: Model architecture (if available)
quantization: Quantization type (if available)
list_loaded_modelsList all currently loaded models in memory.
Parameters: None
Returns: Array of loaded model info with:
identifier: Instance identifier
modelKey: Model key
path: Model path
displayName: Human-readable name
sizeBytes: Size in bytes
vision: Whether model supports vision
trainedForToolUse: Whether model was trained for tool use
load_modelLoad a model into memory.
Parameters:
model (required): Model key to load (e.g., llama-3.2-3b-instruct)
identifier (optional): Custom identifier for the loaded instance
contextLength (optional): Context window size in tokens (minimum: 1)
evalBatchSize (optional): Batch size for token processing (minimum: 1)
Returns: Success status with loaded model details (identifier, modelKey, path)
unload_modelUnload a model from memory.
Parameters:
identifier (required): Identifier of the loaded model to unload
Returns: Success status
get_model_infoGet detailed information about a loaded model.
Parameters:
identifier (required): Identifier of the loaded model
Returns: Model details including identifier, modelKey, path, displayName, sizeBytes, contextLength
# Build the project
npm run build
# Run in development mode with auto-reload
npm run dev
# Type check without emitting
npm run typecheck
# Run tests
npm test
# Lint
npm run lint
# Format
npm run format:check
npm run formatThe project includes a make release command for automated releases:
# Create a new release (runs CI, sets version, commits, tags, publishes to npm and Docker Hub)
make release VERSION=<version>
# Example:
make release VERSION=1.0.5This runs the full release pipeline:
CI checks (lint, typecheck, test)
Sets version in package.json
Commits the version bump
Creates an annotated git tag (v<version>)
Publishes to npm
Builds and pushes Docker images to Docker Hub
src/
├── index.ts # MCP server entry point
├── client.ts # LM Studio client wrapper
├── types.ts # Shared types and result helpers
└── tools/
├── index.ts # Tool exports
├── health-check.ts # Health check tool
├── list-models.ts # List downloaded models
├── list-loaded-models.ts
├── load-model.ts
├── unload-model.ts
└── get-model-info.tsConsistent Results: All tools return the same ToolResult<T> envelope
Safe Wrappers: Tool handlers are wrapped to catch exceptions and return error payloads
Lazy Config: Environment variables are read at runtime, not module load
Singleton Client: Single LM Studio client instance is reused
ISC
Get detailed information about a specific loaded model in LM Studio
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The model instance identifier to get information about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states the purpose. It implies a read-only operation but does not disclose any behavioral traits such as permissions, side effects, or rate limits. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It is front-loaded and efficient, earning its place without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but lacks detail on what 'detailed information' includes. It does not fully compensate for the absence of an output schema or provide usage examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('detailed information about a specific loaded model in LM Studio'). It implicitly distinguishes from siblings like list_loaded_models, which list all loaded models, by focusing on a single specific model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or contrast with sibling tools like list_loaded_models or health_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check connectivity to LM Studio server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on behavioral traits such as what is returned (e.g., success/failure), network calls made, or idempotency. Should disclose more for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous content, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a simple health check tool with no parameters and no output schema, but lacks details on return value and error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description adds nothing beyond schema. Baseline 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Check' and resource 'connectivity to LM Studio server'. Distinguishes from sibling tools which focus on model operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for verifying server connectivity before other operations, but no explicit when-to-use or when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently loaded LLM models in LM Studio
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is straightforward for a read-only list operation. No contradictions with annotations (none provided). Lacks mention of return format but acceptable for simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter list tool, but could mention what information is returned per model (e.g., name, path). No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so no param info needed. Schema coverage is 100% (empty), baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('list') and resource ('currently loaded LLM models'). Distinguishes from sibling 'list_models' which likely lists all available models, not just loaded ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get_model_info' or 'list_models'. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all downloaded LLM models available in LM Studio
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description simply states a listing operation without details on performance, pagination, or authentication. Since operation is simple and read-only, it is adequate but not informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no superfluous information. Concisely states purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters or output schema, the description is complete enough. Could mention return format but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description need not 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all downloaded LLM models available in LM Studio', distinguishing it from sibling 'list_loaded_models' which likely lists currently loaded models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. While sibling names suggest a distinction between downloaded and loaded models, the description does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a model into memory in LM Studio
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | The model key to load (e.g., 'llama-3.2-3b-instruct') | |
| identifier | No | Custom identifier for the loaded model instance | |
| contextLength | No | Context window size in tokens | |
| evalBatchSize | No | Number of tokens to process together in a batch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It only states 'Load a model into memory', omitting potential side effects (e.g., unloading previous model), resource consumption, loading time, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At one sentence, the description is concise, but it sacrifices essential details. It could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and no annotations, the description is inadequate. It does not explain return behavior, verification steps, or how loading integrates with sibling tools like list_loaded_models.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description in the schema. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Load' and resource 'a model into memory in LM Studio', clearly distinguishing it from sibling tools like unload_model, list_loaded_models, and list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, prerequisites, or alternatives. It does not mention that loading requires the model to be available via list_models or that it may conflict with an already loaded model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unload a model from memory in LM Studio
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The model instance identifier to unload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only says 'unload from memory' but does not disclose prerequisites, side effects, or error conditions (e.g., model not loaded). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (one parameter, no annotations, no output schema). Description is adequate but lacks context like prerequisites or relationship to sibling tools (e.g., 'list_loaded_models'). Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'identifier', so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'unload' and the resource 'model from memory', distinguishing it from siblings like 'load_model' and 'list_loaded_models'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as 'list_loaded_models' or 'load_model'. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: health_check for connectivity, list_models vs list_loaded_models for different sets, get_model_info for details on a loaded model, and load/unload for lifecycle management. No ambiguity.
Most tools follow a verb_noun pattern (get_model_info, list_choices, load_model, unload_model). health_check deviates as a noun phrase but is conventional and understandable. Overall consistent.
With 6 tools covering connectivity, listing, loading/unloading, and info query, the count is well-scoped for the domain of model management without bloat or deficiency.
The set covers core model lifecycle (load, unload, list, info) and connectivity. Minor gaps like model deletion or parameter configuration are not critical for common agent tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage your Mistral platform — models, files, batch jobs, agents and RAG document libraries.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Manage portable AI agent playbooks, Agent Skills, MCP configurations, personas, and memory.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/portertech/lm-studio-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
