TL;DR
Get business pricing on networking and server gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
Microsoft’s Pylance release documentation describes the Type Server Protocol (TSP), a JSON-RPC interface for requesting Python type-analysis data from a type server. It specifies version checks, workspace snapshots and optional negotiated IPC channels for read-only requests; the material does not announce a release date or adoption by other tools.
Microsoft’s Pylance release documentation describes the Type Server Protocol (TSP), a JSON-RPC interface for clients to request Python type-analysis data from a type server. The specification outlines how clients check compatibility, identify workspace snapshots and, when both sides support it, open extra IPC connections for read-only work.
A type server keeps type-analysis state for a workspace and can respond to requests for protocol version, snapshots, Python search paths, import resolution and computed, declared or expected types. TSP uses the JSON-RPC format and draws on Language Server Protocol conventions and data shapes where useful, including positions, ranges and URI strings. Its methods use the typeServer/ prefix.
The repository identifies three protocol artifacts as authoritative: typeServerProtocol.ts, which defines TypeScript interfaces and request types; tsp.json, a machine-readable model; and tsp.schema.json, a JSON schema for that model. The documented version history runs from 0.1.0 to 0.4.1. The report says 0.2.0 added request types and fields, 0.3.0 changed type shapes, 0.4.0 introduced a Type union and stub-based payloads, and 0.4.1 added multi-connection negotiation and a connection-control request.
In a typical session, the client starts or connects to a server, initializes workspace state, requests the supported protocol version and checks compatibility, then obtains an initial snapshot identifier. Type queries and related requests can include that snapshot; the server can send typeServer/snapshotChanged when earlier results are no longer valid. Clients commonly establish workspace and document state using normal LSP initialization and synchronization on the main JSON-RPC connection.
How TSP Separates Analysis Work
The protocol describes a common request-and-response structure for tools that need Python analysis from a separate type server. Its version check gives clients a defined point to compare their expectations with the server’s response before relying on protocol features. Snapshot identifiers also give requests a way to refer to a particular state of the workspace, while snapshot-change notifications signal that previous results may need refreshing.
The optional multi-connection feature is intended for concurrent read-only requests, such as high-volume type queries or background workers. If negotiated, those channels can carry additional work while the main connection retains responsibility for mutable workspace state and connection control. The specification says a server must still function in single-connection mode, so this performance option is not required for protocol correctness.
For developers and tool makers, the practical importance is in the defined boundary between a client and analysis service: which requests exist, how compatibility is checked, and how a client can ask for results tied to workspace state. The documentation alone does not establish that third-party tools have adopted TSP or that it has changed Pylance’s performance or user experience.
Products Worth Considering
Logitech MX Mechanical Wireless Illuminated Keyboard, Tactile Quiet, Graphite
Apple AirPods Pro 3 Wireless Earbuds with Active Noise Cancellation
LG 34GX90SA-W 34-inch Ultragear WQHD OLED Curved Gaming Monitor
As an affiliate, we earn on qualifying purchases.
Protocol Versions and Session Setup
TSP’s version history shows a protocol that has changed its request and type-payload definitions across several 0.x versions. The documentation cautions that while the protocol remains in the 0.x line, a minor-version change may be breaking; patch changes remain backward compatible within the same minor line. Clients therefore should not assume that every version in the 0.x series is interchangeable.
The main connection can use a transport supported by the server, such as stdio or Node IPC. When stdio is used, standard output must be reserved for JSON-RPC messages. The optional extra-channel mechanism is separately negotiated through the ordinary LSP initialize request and response: both client and server advertise supported transports under an experimental capability, and there must be at least one transport in common. The built-in extra-connection transport listed in the documentation is IPC.
After successful negotiation, the client opens an extra channel by sending typeServer/connection on the main connection. The documented open request carries a transport kind and endpoint arguments. For a full-duplex IPC mechanism, the arguments contain one endpoint; for a platform exposing one-way endpoints, they contain separate server-input and server-output endpoints. If negotiation is absent or there is no shared transport, the session stays on one connection and the client must not send the connection-control request.
Adoption and Release Details
The supplied documentation does not state when the page was published, whether TSP is available in a particular Pylance release, or which other clients and servers implement it. It also does not provide performance measurements showing how much optional multi-connection mode improves request handling.
The protocol text describes expected behavior, but it does not report independent testing or confirm that every implementation supports every request. The exact implementation status, deployment scope and any future changes remain unclear from this source alone.
What Implementers Need to Check
Clients and server authors using the specification would need to compare their supported protocol versions, implement the relevant request and response shapes, and preserve the main connection’s ownership of workspace state. Before opening extra channels, they must exchange initialization capabilities and confirm a shared transport; otherwise, requests should remain on the single connection.
The repository’s protocol files provide the definitions to consult as implementations develop. The supplied material does not give a timetable for a later version or announce a specific product rollout, so any adoption or follow-up changes would need confirmation from subsequent documentation or release notes.
Key Questions
What is the Type Server Protocol?
It is a JSON-RPC protocol described in Microsoft’s Pylance release documentation. Clients use it to request Python analysis information, including type queries, import resolution, search paths and workspace snapshots.Does TSP replace the Language Server Protocol?
The documentation says TSP uses LSP conventions and data shapes where useful, and clients commonly use LSP initialization and document synchronization to provide workspace state. It does not describe TSP as a replacement for LSP.Are multiple connections required?
No. Multi-connection mode is an optional performance feature. The documentation says servers must work correctly in single-connection mode, and clients may open extra channels only after both sides advertise compatible support.How does a client know whether its protocol version is compatible?
The client requests the server’s version with typeServer/getSupportedProtocolVersion and checks the returned semantic-version string against the version it expects. The documentation warns that minor changes within the 0.x series may be breaking.Has Microsoft announced broad adoption or a release date?
The supplied source does not give a publication date, rollout schedule or adoption list. It documents the protocol and its expected behavior but does not establish how widely it is implemented.Source: github.com
