Overview

1.1 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

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

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 and background mode.
• 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.
• 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.
• Agent2Agent (A2A). Service cards, explicit task states, task subscription and cancellation inform LMSP’s service description and its asynchronous task model. See A2A.

1.4 Architecture

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

+---------------------------------------------------------------+
| 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).
• Core. The model catalog, synchronous responses, server-sent events and asynchronous tasks (pages 5 to 7).
• Compatibility. An OpenAI-compatible API and, optionally, an Ollama-compatible API (page 8).
• 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

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 (RFC 2119, RFC 8174) 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