LM Studio Responses API 2026: Local Models, Stateful Chat, Tools & MCP

If you already use LM Studio as a local model runner, there is a point where the desktop chat interface stops being enough. You want your own Python script to call the model, your Next.js app to use it, or an agent to keep a conversation state without resending the entire history every time.

That is where LM Studio's newer API stack becomes much more interesting. The current documentation recommends its native v1 REST API, while LM Studio also exposes OpenAI-compatible endpoints including /v1/responses. The Responses endpoint supports streaming, reasoning controls, stateful follow-ups with previous_response_id, custom tools and optional remote MCP tools.

This guide walks through the setup from zero: start the local server, call a model with the OpenAI-compatible Responses API, keep state between requests, add tools, understand remote MCP, and secure the server before allowing anything else on your network to access it.

Why use the LM Studio API instead of the chat window?

The LM Studio app is convenient for experimenting with models. An API is useful when the model needs to become part of another application.

LM Studio's current API documentation describes the native v1 REST API as the recommended replacement for its older v0 API. It includes model listing, loading, unloading, downloads, stateful chat and MCP support. The OpenAI-compatible layer remains useful when you want existing OpenAI-style client code to work against a local endpoint.

Step 1: Start the LM Studio local server

Open LM Studio and go to the Developer tab. Start the local server.

You can also start it from the command line with the LM Studio CLI:

lms server start

The default local server is normally available at:

http://localhost:1234

If you want to confirm the server is reachable, open the local API endpoint from the machine running LM Studio or send a request to an endpoint you have enabled.

Step 2: Load a model

An API server is only useful if there is a model available to answer requests. You can load one from the LM Studio interface, or use the CLI when you want a repeatable workflow.

lms load

For your first API test, use a model you already know works in the LM Studio chat interface. That isolates API problems from model-loading problems.

This is an important debugging habit: prove the model works in LM Studio first, then prove the API works, then add tools or MCP. If you enable everything at once, a failure becomes much harder to diagnose.

Step 3: Call LM Studio's OpenAI-compatible Responses API

LM Studio supports the OpenAI-compatible /v1/responses endpoint. A minimal request looks like this:

curl http://localhost:1234/v1/responses   -H "Content-Type: application/json"   -d '{
    "model": "openai/gpt-oss-20b",
    "input": "Explain why local LLMs need quantization.",
    "reasoning": {
      "effort": "low"
    }
  }'

Replace the model identifier with the model loaded or available in your LM Studio installation.

The response API can stream events or return a completed response. For applications where you want text to appear progressively, set stream to true.

Step 4: Build a stateful conversation

This is one of the most useful differences between a simple stateless completion endpoint and the Responses API.

After the first response, the response has an ID. You can use that ID as previous_response_id in a later request.

curl http://localhost:1234/v1/responses   -H "Content-Type: application/json"   -d '{
    "model": "openai/gpt-oss-20b",
    "input": "Now explain the same idea for a developer building a local RAG app.",
    "previous_response_id": "resp_123"
  }'

The exact response ID comes from your previous request. The important idea is that your application does not have to resend the entire conversation as a giant prompt every time.

This can be especially useful for local agents because context management becomes part of the application design instead of a pile of manually concatenated messages.

Why stateful responses matter for local AI

Imagine a coding assistant that has already discussed a project architecture with you. With a stateless request, your application may need to resend all of that context. With stateful response handling, the application can continue from the previous response state.

That does not mean context becomes free or infinite. The model still has finite context and the server still has to process the information associated with the conversation. Stateful APIs mainly give the application a cleaner way to manage the interaction.

Step 5: Use Python with an OpenAI-compatible client

If you already have Python code built around the OpenAI client, you can point it at the local LM Studio endpoint instead of rewriting your application around a completely different SDK.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:1234/v1",
    api_key="lm-studio"
)

response = client.responses.create(
    model="openai/gpt-oss-20b",
    input="Give me three practical uses for a local LLM."
)

print(response)

The API key value shown here is only a placeholder for clients that require one. If you enable authentication in LM Studio, use the actual configured token and send it through the normal Authorization: Bearer ... mechanism.

For a real application, keep credentials in environment variables rather than hard-coding them into source files.

Step 6: Add normal tool calling

Tool calling lets the model request that your application execute a function. The model does not magically run arbitrary code; your application decides whether to execute the requested tool.

A simplified tool definition might describe a weather function:

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    },
    "required": ["city"]
  }
}

Your application receives the tool request, validates the arguments, executes the function, and sends the result back to the model.

This distinction matters for security. A local model should not be treated as a trusted program merely because it is running on your own computer.

Step 7: Connect a remote MCP server through LM Studio

LM Studio's current Responses documentation also supports optional remote MCP tools. A request can include an MCP tool definition such as:

{
  "model": "ibm/granite-4-micro",
  "input": "Search for the latest local AI models.",
  "tools": [
    {
      "type": "mcp",
      "server_label": "huggingface",
      "server_url": "https://huggingface.co/mcp",
      "allowed_tools": [
        "model_search"
      ]
    }
  ]
}

The important word here is optional. Remote MCP access should not be enabled simply because a tool exists. First decide what information the server receives, what actions it can perform, and whether the model should be allowed to call it at all.

Remote MCP is not the same as local MCP

There are two useful concepts to keep separate.

LM Studio can also configure MCP servers through its mcp.json system. Its API documentation distinguishes between ephemeral MCP integrations supplied for one request and servers preconfigured in mcp.json.

Step 8: Understand the LM Studio security settings before opening the API

This is where a local API can become dangerous if configured casually.

LM Studio's server settings include options for authentication, serving on the local network, API-client MCP access, CORS and just-in-time model loading.

In particular, the documentation warns that allowing API clients to call MCP servers defined in mcp.json can be a security risk when those servers have access to your filesystem or private data. That setting requires API authentication.

A sensible progression is:

1. Keep the server on localhost while developing.
2. Test the application.
3. Enable authentication before exposing the server to other machines.
4. Only then consider “Serve on Local Network”.
5. Review MCP permissions separately.
6. Do not install unknown MCP servers just because they are convenient.

What happens if you expose LM Studio to your LAN?

Serving on the local network changes the threat model. Another device on your network may be able to send requests to the model server depending on your authentication and firewall configuration.

That can be useful when you want a desktop to act as a private model server for a laptop, phone or development VM. It can also create an unintended API endpoint if you enable it without authentication.

For a development machine, the safest default is usually to leave the server local until you have a specific reason to expose it.

LM Studio Responses API vs Chat Completions

LM Studio's current documentation recommends its native v1 REST API when you need LM Studio-specific capabilities such as model management, while the OpenAI-compatible APIs are convenient when an application already speaks OpenAI-style APIs.

When should you use LM Studio's native v1 REST API?

Use the native API when you need capabilities that are specific to managing a local model server.

For example, the native API exposes endpoints for:

• Listing models
• Loading models
• Unloading models
• Downloading models
• Checking download status
• Stateful chat
• MCP integrations

This makes it a better fit for automation that needs to manage the machine rather than merely generate text.

A useful architecture for a local AI application

Your App
   |
   | OpenAI-compatible API
   v
LM Studio Server
   |
   +---- Local Model
   |
   +---- Custom Tools
   |
   +---- Optional MCP
   |
   +---- Local / LAN clients

This architecture can support a local developer assistant, a private research application, a document workflow, or a prototype that you eventually move to another inference backend.

How to debug a failed LM Studio API request

1. Test the model in the GUI

If the model cannot answer normally in LM Studio, do not debug your application yet.

2. Check the server

Confirm the Developer server is running and that your application is using the correct port.

3. Check the model identifier

Use the exact identifier exposed by your LM Studio installation. Do not assume the display name in the model browser is identical to the API identifier.

4. Remove tools

If a basic text request works but a tool-enabled request fails, test without tools. Then add your tool back.

5. Remove MCP

If normal tool calling works but an MCP request fails, isolate the MCP server. Check its URL, authentication and allowed tools.

6. Check authentication

If the API works on localhost but fails after you enable network access, inspect the authentication and network settings before changing the application code.

Can LM Studio replace Ollama for API development?

Sometimes, yes, but the two products have different strengths. Ollama is excellent when you want a lightweight model runtime and API that fits naturally into server-side workflows. LM Studio is particularly attractive when you want a desktop model manager, visual controls, local model experimentation and a developer API in the same application.

GyanAangan already covers the broader Ollama vs LM Studio comparison. For a browser interface around local models, see our Open WebUI + Ollama connection guide.

FAQ

What is the LM Studio Responses API?

It is LM Studio's OpenAI-compatible /v1/responses endpoint for local models. It supports streaming, reasoning controls, stateful follow-ups, tools and optional remote MCP tools.

What port does LM Studio use?

The local API server commonly runs on port 1234, so the base URL is usually http://localhost:1234. The port can be changed in server settings.

Can I use the OpenAI Python SDK with LM Studio?

Yes. LM Studio provides OpenAI-compatible endpoints, so an OpenAI-style client can be pointed at the local base URL.

Can LM Studio use MCP through its API?

Yes. Current LM Studio documentation supports MCP through both its native API and the OpenAI-compatible Responses API.

Is the LM Studio API safe to expose on my network?

It can be used on a local network, but you should configure authentication and understand the permissions of any tools or MCP servers before exposing it.

Official documentation

LM Studio Responses API · LM Studio REST API · MCP via API · Server Settings · Tool Use

Final takeaway

The interesting part of LM Studio's current API stack is that it is no longer just a convenient way to send a prompt to a local model. You can build stateful applications, use familiar OpenAI-compatible clients, call custom tools, connect MCP and programmatically manage local models.

For developers, that makes LM Studio a practical local backend rather than just a desktop chatbot. Start with a simple local request, add state, then add tools and MCP one layer at a time. That approach gives you a useful application while keeping failures and security boundaries understandable.