Microsoft has published the Type Server Protocol (TSP), a JSON-RPC specification that lets clients query a running Python type server for computed types, declared types, expected types, import resolution, and search paths. The protocol lives in the pylance-release repo on GitHub, with authoritative TypeScript interfaces, a machine-readable protocol model (tsp.json), and a JSON schema. It is currently at version 0.4.1. TSP rides on top of Language Server Protocol (LSP) conventions — zero-based lines, UTF-16 character offsets, standard Position and Range shapes — but adds its own typeServer/ method prefix and a snapshot-based consistency model. Snapshots are non-negative integers that mark a point-in-time view of the analysis state. Every type handle and declaration returned is valid only for the snapshot in which it was issued; when the server advances the snapshot (file changes, config changes, cache resets), clients must re-query. The multi-connection mode introduced in 0.4.1 is the most architecturally interesting feature. It allows clients to open additional read-only IPC channels to the same type server, keeping the main connection for mutable state (document sync, configuration, lifecycle). This is a concurrency play: high-volume type queries or background workers can run without blocking the primary JSON-RPC connection. Both sides must negotiate support during LSP initialization, and the feature is explicitly optional — single-connection mode remains the baseline. The protocol's type system uses tagged JSON objects with discriminators, supporting nodes (URI plus source range), declarations (regular or synthesized), and handles (with -1 as the sentinel InvalidHandle). This is clean plumbing: it maps type-checker internals into a wire-safe shape without inventing new abstractions. What matters here is the strategic framing. TSP is published in the pylance-release repo, not as an independent standard. The spec is open to read and implement against, but the reference implementation is Pylance — Microsoft's proprietary Python language server built on Pyright. This is the familiar pattern: open the protocol, own the canonical server. It lowers the barrier for third-party tooling (IDEs, linters, AI coding assistants) to consume Pylance's type analysis, which expands Pylance's utility without ceding control of the engine. The semantic versioning approach is cautious: the 0.x line explicitly allows breaking changes on minor bumps. This gives Microsoft room to evolve the protocol shape aggressively without backward-compatibility obligations. Patch versions within a minor line are backward-compatible, so downstream consumers can pin to a minor version, but they should expect migration work on each minor bump. For the Python tooling ecosystem, TSP creates a standardized surface for type queries that could eventually decouple type consumption from type computation. If adopted, it means tools don't need to embed their own type checker — they can query one. The question is whether this protocol becomes a genuine ecosystem standard or remains a Pylance integration API with open documentation.
