{"slug": "beta4-is-here-upgrade-all-your-mcp-servers-with-one-line", "title": "Beta4 Is Here. Upgrade All Your MCP Servers With One Line.", "summary": "Ikanos v1.0.0-beta4 shipped this week with support for the 2026-07-28 MCP specification, requiring only a one-line change to the Docker image tag to upgrade all MCP servers. The company demonstrated that two existing capabilities ran unchanged, with zero file diffs and only minor additions to the tool contract, such as ttlMs and cacheScope caching hints.", "body_md": "Three weeks ago [we wrote](/blog/the-2026-07-28-mcp-spec-and-why-your-capabilities-dont-need-recertifying/) that the `2026-07-28`\n\nMCP revision was the biggest breaking change since the protocol launched, and that capabilities running on Ikanos would ride through it as one engine upgrade with zero edits to any capability file. At the end of that post, we said we would show the diff when Ikanos shipped support.\n\nIkanos `v1.0.0-beta4`\n\nshipped this week with `2026-07-28`\n\nsupport. This is that post.\n\nWe took two capabilities from earlier write-ups, the [Notion to GitHub spec sync](/blog/sync-a-notion-spec-into-a-github-issue-with-one-ikanos-capability/) and the [support voice assistant](/blog/voice-assistants-and-the-200-tool-bottleneck/), ran them on beta3, changed one thing, and pointed a real MCP client at both before and after. Every command and diff below was run against the real engine.\n\n## The bump\n\nThe engine is a plain `docker run`\n\n, straight from the install docs. The version is the image tag. Moving from beta3 to beta4 means changing that tag:\n\n```\n- ghcr.io/naftiko/ikanos:v1.0.0-beta3\n+ ghcr.io/naftiko/ikanos:v1.0.0-beta4\nbash\n$ docker run -p 9095:9095 -p 9198:9198 \\\n    -v $(pwd)/capabilities/notion-github-spec-sync.yaml:/app/ikanos.yaml \\\n    ghcr.io/naftiko/ikanos:v1.0.0-beta4\nMCP Server started on 0.0.0.0:9095 (namespace: spec-sync)\nCapability started successfully.\n```\n\nIf you manage the engine through `docker-compose.yml`\n\n, it’s the same edit in a file instead of on the command line. Ikanos doesn’t care how the image gets pulled, only which tag it is. Compose just means the tag lives somewhere you can diff:\n\n``` bash\n$ docker compose up -d\nnotion-github-spec-sync-1  | MCP Server started on 0.0.0.0:9095 (namespace: spec-sync)\nsupport-voice-assistant-1  | MCP Server started on 0.0.0.0:9096 (namespace: voice)\nnotion-github-spec-sync-1  | Capability started successfully.\nsupport-voice-assistant-1  | Capability started successfully.\n```\n\nBoth capabilities are back up on the current MCP specification. Their own files were not touched, including the `ikanos:`\n\nline inside each one.\n\n## The diff on every capability\n\nA real `git diff`\n\nacross the tagged commits, on both capability files, before the bump and after:\n\n``` bash\n$ git diff before after -- 'capabilities/*.yaml'\n(exit code: 0)\n```\n\nZero files changed. Zero insertions. Zero deletions. Not “no breaking changes we noticed.” Zero bytes.\n\nThe file that describes what your capability does was never a place the transport migration could touch, because the transport never lived there. It lives in the engine.\n\n## The diff on the tool contract\n\nUnchanged YAML is half the promise. The other half is that the agent sees the same thing before and after. We captured `tools/list`\n\nagainst both engine versions and diffed the raw responses:\n\n``` bash\n$ diff fixtures/beta3/tools-list.json fixtures/beta4/tools-list.json\n       ]\n+      \"resultType\": \"complete\",\n+      \"ttlMs\": 0,\n+      \"cacheScope\": \"private\",\n+      \"_meta\": {\n+        \"io.modelcontextprotocol/serverInfo\": {\n+          \"name\": \"spec-sync\",\n+          \"version\": \"unspecified\"\n+        }\n+      }\n```\n\nThat is the entire substantive difference, and it repeats identically for the second capability. The tool itself is identical left to right — same `name`\n\n, `title`\n\n, `description`\n\n, `inputSchema`\n\n, and safety hints, byte for byte, for all three tools across both capabilities.\n\nThe only additions sit outside the tool definition: `ttlMs`\n\nand `cacheScope`\n\n, response-level caching hints from the `2026-07-28`\n\nspec. A client can use them. A capability author never has to think about them.\n\n## The transport actually moved\n\nThe wire underneath changed shape, which is the reason a migration post exists at all. beta3 spoke the old session-based handshake:\n\n```\n# beta3 · POST /mcp · initialize\nHTTP/1.1 200 OK\nMcp-Session-Id: 6f04252a-5320-4aca-99b4-ecb6175ab30c\n\n{\"result\":{\"protocolVersion\":\"2025-11-25\", ...}}\n```\n\nSend that same request to beta4 and it doesn’t get as far as being an unknown method:\n\n```\nHTTP/1.1 400 Bad Request\n\n{\"jsonrpc\":\"2.0\",\"id\":1,\"error\":{\"code\":-32020,\n  \"message\":\"Missing mandatory header: Mcp-Method\"}}\n```\n\nbeta4 speaks the stateless `2026-07-28`\n\ncore. No handshake. Protocol version and method travel with every request instead of being negotiated once:\n\n```\n# beta4 · POST /mcp · tools/list, no prior handshake\nMcp-Method: tools/list\nMCP-Protocol-Version: 2026-07-28\n\n{\"result\":{\"tools\":[...], \"resultType\":\"complete\",\n  \"ttlMs\":0, \"cacheScope\":\"private\"}}\n```\n\nThat is a real break for a client hardcoded to the old handshake, and it is meant to be. The MCP spec’s own [compatibility matrix](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning#backward-compatibility-with-initialization-based-versions) documents *legacy client × modern server → fails* as the expected outcome for a modern-only server. It’s not an Ikanos choice.\n\nThe current Tier-1 SDKs (TypeScript, Python, Go, C#) already speak `2026-07-28`\n\n, and the Python and TypeScript v2 SDKs support every earlier revision too. The one thing to check before you change the tag in production is what your agent’s client dependency is running. Not your capability files.\n\n## One certification, not many\n\nBefore Ikanos, verifying a transport migration was safe meant re-reviewing every capability that touches MCP. Two capabilities meant you had to do two reviews. Here it is one engine, reviewed once, inherited by both. Every capability you add later inherits the same guarantee without a second audit, because the thing that changed was never expressed in any of them.\n\nWhat we verified:\n\n**Capability YAML**— 0 bytes changed across both files** Tool contract**— identical name, description, schema, hints** Engine**— started clean on beta4, serving both capabilities** Wire protocol**— checked against the public`2026-07-28`\n\nspec, not just the release notes\n\n## Also in beta4\n\nNaftiko’s `1.0.0-beta4`\n\nreleases didn’t stop there. The rest of the releases are about testing what we say holds.\n\n- Ikanos has its first real end-to-end suite. CI brings up Keycloak and Microcks in Docker Compose, starts Ikanos against them, and exercises the OAuth 2.1 and Bearer paths with real tokens and real JWKS discovery, plus an invalid token to confirm rejection works.\n- A feature coverage tracker maps all 32 blueprint features against test depth and delivery progress. It works as a roadmap and as a plain list of what is still thin.\n- Polychro’s “iso-functional with Spectral” claim is now a harness rather than a sentence. Same ruleset, same document, run through both engines, diagnostics diffed.\n- Trivy scans now gate Polychro’s Maven and CLI release pipelines. CLI binaries ship with SHA256 checksums. Five CVEs patched.\n- Polychro fix: paths in\n`.polychro.yml`\n\nresolve against the config file, not the working directory.\n\nCrafter, Warden, and Skipper picked up the beta4 schema and engine versions in the same coordinated release.\n\n## The takeaway\n\nThe migration cost was real. It landed where the architecture said it would: in the engine, once, instead of in every capability, every time.\n\nIf you run Ikanos today, the action item is not “audit your YAML.” It’s “change the image tag, and make sure whatever calls you is on a current MCP client.”", "url": "https://wpnews.pro/news/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line", "canonical_source": "https://naftiko.io/blog/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line/", "published_at": "2026-08-18 00:00:00+00:00", "updated_at": "2026-08-28 16:49:04.496856+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Ikanos", "MCP"], "alternates": {"html": "https://wpnews.pro/news/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line", "markdown": "https://wpnews.pro/news/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line.md", "text": "https://wpnews.pro/news/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line.txt", "jsonld": "https://wpnews.pro/news/beta4-is-here-upgrade-all-your-mcp-servers-with-one-line.jsonld"}}