What is Implementation?
Implementation is a small identity record that every MCP participant attaches to the initialization handshake. It carries two mandatory fields — name (a stable, machine-readable identifier) and version (expected to follow semantic versioning) — plus optional human-facing metadata such as title, description, websiteUrl, and an icons array. The type lives in the modelcontextprotocol/types package and is intentionally minimal: its only job is to let each side announce who it is before any capability negotiation or protocol work begins. \n\nIn the message flow, the client populates clientInfo inside InitializeRequest and the server echoes back a matching serverInfo inside InitializeResult. Both fields carry the same Implementation shape, so a single reusable type covers both directions. The protocol treats neither field as executable; they are purely informational. Hosts typically surface server name and version in UI dashboards, log them to structured telemetry, or use them for compatibility gates (for example, refusing to send elicitation requests to a server version older than a known cutoff). \n\nThe distinction between name and title matters in practice. name should be a stable slug — like weather-server — that never changes between releases, because downstream tooling may key on it. title is the display string shown to users and can be localized or reworded freely. The icons field, introduced in later revisions of the schema, accepts an array of Icon objects so servers can supply multiple resolutions or formats; it is entirely optional and most current SDKs omit it.
When to use
Every initialize handshake.
When NOT to use
Never omit the version — clients use it for compatibility.
Notes
Keep name stable across versions
The name field is used by host applications and telemetry pipelines as a persistent identifier. Changing it between releases breaks dashboards that filter by server name and may silently disable version-specific compatibility logic in clients. Treat it like a package name — evolve title and description freely, but treat name as immutable once published.
SemVer in version is a real constraint
The spec recommends MAJOR.MINOR.PATCH format and several SDK helpers call semver.parse() on the version string at handshake time. A non-standard string like 'dev' or 'git-abc1234' will not fail the handshake, but it will cause version-comparison logic in compatibility checks to silently short-circuit or throw. Use a proper semver string, even in development builds (e.g. '0.0.1-dev').
Icons array is schema-complete but rarely wired
The Icon[] field appears in the TypeScript SDK typings and JSON Schema for 2025-06-18 and later drafts, but most official client implementations (Claude Desktop, Inspector) do not yet render it. Including it does no harm, but do not rely on it for anything visible to end users. Prefer websiteUrl for discoverable project identity.
Asymmetry between client and server info
Although the same Implementation type is used for both clientInfo and serverInfo, the two have different practical weights. serverInfo is surfaced prominently in host UIs and logged by nearly all production clients; clientInfo is mostly consumed by servers for access-control decisions or debug logging. A server that logs the incoming clientInfo can use it to detect legacy client versions that predate a breaking schema change and respond with a downgrade path or a clear error.
No runtime validation by default
The MCP spec does not mandate that a receiving peer validate the name or version fields beyond ensuring they are present strings. Relying on the other party to send a well-formed version is an unsafe assumption in open deployments. If your server gates behavior on the client version, add an explicit semver parse and a clear error response rather than silently ignoring malformed values.
Fields
| Field | Type | Required | Purpose |
|---|---|---|---|
| name | string | yes | Programmatic name. |
| title | string? | no | Human-friendly name. |
| version | string | yes | SemVer version string. |
| description | string? | no | What this implementation does. |
| websiteUrl | string? | no | Project homepage. |
| icons | Icon[]? | no | Visual representations. |
Examples
Server identity
{
"name": "weather-server",
"title": "Weather MCP Server",
"version": "1.0.0"
}Common mistakes
❌ Using a non-semver version
✅ Stick to MAJOR.MINOR.PATCH — tooling depends on it.