# Overview

> LMSP 1.0 draft overview. What the Local Model Service Protocol is, the designs it builds on, its layered architecture, how to read the specification, and the terms used throughout.

Source: https://madeforagent.com/lmsp/1.0/
Language: en
Specification: LMSP 1.0 (draft)
Updated: 2026-11-08

## 1.1 Abstract {#abstract}

The Local Model Service Protocol (LMSP) defines how clients find and use language-model services that run on a user's own device or local network. It specifies service discovery, a model catalog, synchronous and streaming generation, and asynchronous tasks that survive restarts. It also defines how one service offers an OpenAI-compatible interface next to the LMSP interface, so existing clients keep working.

LMSP does not replace the OpenAI API, Ollama or MCP. It combines their strengths into a protocol layer built for a resident local service.

## 1.2 Status of this document {#status}

This is the first public draft of LMSP 1.0, published on 2026-11-08. "LMSP" is a working name. The text is open for feedback and may change incompatibly until 1.0 is final.

The English text is normative. Translations are provided for convenience; where they differ, the English text prevails.

## 1.3 Design basis {#design-basis}

LMSP reuses proven designs instead of inventing new ones:

- **OpenAI Responses API.** Structured output items, semantic server-sent events, and background execution with query and cancel for long-running work. This is the reference for LMSP's core conversation interface. See [streaming responses](https://developers.openai.com/api/docs/guides/streaming-responses) and [background mode](https://developers.openai.com/api/docs/guides/background).
- **Ollama.** It serves OpenAI-compatible `/v1/models`, `/v1/chat/completions` and `/v1/responses` endpoints, which shows that one service plus an OpenAI adaptation layer sharply lowers the cost of adoption. See [Ollama's OpenAI compatibility](https://docs.ollama.com/api/openai-compatibility).
- **Model Context Protocol (MCP).** Its latest design moves from mandatory session initialization to stateless discovery: every request carries its own version information, and clients learn capabilities through a discovery interface. That suits local services, where restarts, client crashes and dropped connections must not corrupt protocol state. See [MCP](https://modelcontextprotocol.io/).
- **Agent2Agent (A2A).** Service cards, explicit task states, task subscription and cancellation inform LMSP's service description and its asynchronous task model. See [A2A](https://a2a-protocol.org/).

## 1.4 Architecture {#architecture}

LMSP is organized in three layers, on top of the adapters that talk to the model runtimes:

```text
+---------------------------------------------------------------+
| Discovery      mDNS / DNS-SD + well-known service document    |
+---------------------------------------------------------------+
| Core           model catalog, responses, SSE, async tasks     |
+---------------------------------------------------------------+
| Compatibility  OpenAI API, optional Ollama API                |
+---------------------------------------------------------------+
| Adapters       llama.cpp, Ollama, vLLM, custom runtimes       |
+---------------------------------------------------------------+
```

- **Discovery.** mDNS/DNS-SD and a well-known service description document ([page 3](https://madeforagent.com/lmsp/1.0/discovery.md)).
- **Core.** The model catalog, synchronous responses, server-sent events and asynchronous tasks ([pages 5 to 7](https://madeforagent.com/lmsp/1.0/models.md)).
- **Compatibility.** An OpenAI-compatible API and, optionally, an Ollama-compatible API ([page 8](https://madeforagent.com/lmsp/1.0/compatibility.md)).
- **Adapters.** Bridges to llama.cpp, Ollama, vLLM or a custom runtime.

The guiding principle is **one model execution core, two interface families**. A service offers the LMSP interface and the OpenAI interface over the same core, so there is a single place where models are loaded, requests are executed and tasks are tracked.

## 1.5 Conformance language {#conformance}

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY** and **OPTIONAL** in this document are to be interpreted as described in [BCP 14](https://www.rfc-editor.org/info/bcp14) ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119), [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174)) when, and only when, they appear in all capitals.

Each page is marked normative or informative. Normative pages define requirements; informative pages give guidance. Examples are informative. JSON is UTF-8, and field names use `snake_case`.

## 1.6 Terminology {#terminology}

| Term | Meaning |
| --- | --- |
| Service | A resident process that implements LMSP and runs models through adapters. |
| Client | Software that discovers and calls a service: an agent, an application or a tool. |
| Adapter | The component that connects the service to one model runtime, such as llama.cpp, Ollama or vLLM. |
| Model | A locally available model, identified by a stable `id`. |
| Response | The result of one generation request: output items, usage and a status. |
| Task | A persisted, asynchronous execution of a response request, with an explicit state. |
| Event | One server-sent event with a sequence number, emitted while a response is generated. |