Heya! 👋

It's been a while since I sent the last iximiuz Labs update, so brace for a long release log!

Labs MCP

Yes, I gave in. But before you start throwing stones at me, skim through the use case that the shiny new Labs MCP server unlocks.

How to use Labs MCP

It's dead simple, actually. Labs MCP is a remote (HTTP) server. To start using it, you only need to point your AI assistant to its URL and go through a simple OAuth flow it'll trigger:

Labs MCP has already been tested with:

• ChatGPT (web & desktop)
• Claude (web & desktop)
• Claude Code, Codex, and OpenCode (CLI)

And it likely also works with Gemini, Copilot, Cursor, and even Warp and Zed (docs).

Use Case 1: Personalized Tutor

This one is kinda obvious. Paired with the recently added site-wide search, Labs MCP lets you request learning paths tailored to your current needs.

A simple example:

Here is what I got from ChatGPT (5.6 Sol High):

You can probably achieve the same by playing with the filters and search queries in the catalog, but it's kinda handy to just prompt it.

A more involved request:

Claude (Opus 5 High) found these challenges for me, and they are a solid match!

Such results are way harder to reproduce with the plain catalog search because not every challenge that mentions ConfigMap actually primarily focuses on ConfigMap manipulations (and that's what we're looking for here). So a bunch of intelligent analysis that Claude put on top of full-text search was very much needed.

But the Personalized Tutor is not limited to search!

With Labs MCP, you can now ask your favorite AI assistant to help you with a course lesson, tutorial, or challenge if you got stuck with a particular task or on a particular section:

Notice how I didn't even mention the exact challenge. ChatGPT was smart enough to list all currently running playgrounds first, find which one corresponds to a challenge, then read the challenge and the task statuses and provide the feedback (without revealing the solution - it's part of the tool description):

All of the above scenarios were done right on chatgpt.com and claude.ai using the plain chat mode. And of course, they would also work on desktop apps or even on your phone.

Case 2: Playground Builder

Preparing a practice environment is an interesting exercise in itself. But sometimes (more often than not), you don't really have time for such a detour and want to jump straight to the target system. And Labs MCP can help with it!

Here is a simple example:

It took ChatGPT (5.6 Sol High) 3m 24s, but the result is well worth it:

The Dual-Network Router Lab playground it created is pretty close to the one I crafted manually (a while ago) for this networking challenge. And ChatGPT also prepared a very helpful description and a walkthrough (which you can find on the playground page).

Another frequent use case is deploying demo applications while learning a certain technology - e.g., the famous Istio's Bookinfo, Grafana's QuickPizza, or Jaeger's HotRod apps:

Claude Cowork launched right from the web interface (with Opus 5 High) spent about ten minutes on this prompt, but it delivered a rather flawless result - a running K3s playground with a few microservices deployed and Jaeger collecting and visualizing traces:

And if you want to reuse the results of such an experiment, you can always ask the AI assistant to save the current playground session as a custom playground with a follow-up prompt:

Here is the playground I've got for the above example: HotROD + Jaeger on K3s. Similar to the dual-network playground, it has a helpful walkthrough on the front page.

The Jaeger demo app was already non-trivial, but I also tried Labs MCP on the much larger OTEL demo app, and both Claude and ChatGPT managed to produce a working setup:

The OTEL app needs over 15GB of container images, and it took about 30 minutes for the agent to set it all up end-to-end, but since it all happened without my involvement, I count it as a rather huge win. And it's also proof that the Labs MCP's design allows agents to work on long-running, multi-step tasks, which may require debugging along the way.

Playground Builder is a more advanced use case, so you'll want to use the work/cowork mode of ChatGPT/Claude (either via the web interface or the desktop app). In most cases, chat mode won't cut it because the single context window fills up quickly, especially when the model has to keep large Kubernetes and playground manifests right in its context. Of course, Claude Code, Codex, OpenCode, or the like, when paired with Labs MCP, will nail it, too.

Case 3: Remote infrastructure for your agents

Oftentimes, an agent runs in a tiny container, a constrained runtime, or a fully featured VM, but with the wrong kernel and/or Linux distro version. And yet you need this agent to author a shell script that can certainly work on all mainstream Linux distros, or deploy and test an application that can only reveal its cracks on a real multi-node Kubernetes cluster, or debug some involved tech that cannot be launched in the agent's sandbox (e.g., gVisor, Kata containers, or eBPF).

iximiuz Labs is not in the agent sandboxing market, and even with Labs MCP, I expect agents and AI assistants to run outside the playgrounds it controls. But where do iximiuz Labs playgrounds fit nicely is providing realistic remote infrastructure for agents to run and test the software they work on. And with Labs MCP, it becomes rather easy.

A simple example - pair your coding agent with Labs MCP and say:

A more advanced use case is using iximiuz Labs VMs as execution environments to build, develop, or investigate something.

Another typical multi-agent thing you can enhance with Labs MCP is git worktrees. They isolate source trees, but not ports, databases, or dev servers. You can mitigate it to some extent with local containers, but the dev machine's capacity can quickly become a problem. With Labs MCP, you can let different branches - or different agents - use separate remote environments instead of competing for the same laptop.

Last but not least, I've been talking about the bug reproduction use case for a few years now, but with agents it's become so simple that there is no excuse for not leveraging it. Ask the agent to clone a repository, check out the exact commit, reproduce the failure, and preserve the resulting machine state. Such a repro can persist beyond the agent session and be reopened later, rather than being reduced to a (questionable) list of reproduction steps.

Similar to the Playground Builder use case, to benefit from the remote infrastructure capabilities of iximiuz Labs, you will want to use either the work/cowork mode of ChatGPT/Claude or connect Labs MCP straight to your CLI coding agent.

How Labs MCP works

Labs MCP is a stateless remote MCP server that implements the recently released 2026-07-28 Specification (a.k.a., MCP 2.0).

From the caller's perspective, it's just a single JSON-RPC endpoint that handles "tools/call" requests:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
        "name": "start_play",
        "arguments": {"playground":"docker"}
    }
}

Since it's stateless (thanks to the new spec), the implementation of this endpoint is no different from any other endpoint served by the iximiuz Labs API server. This simplification was the primary reason I decided to give it a shot.

If you've never implemented a remote MCP server before, you might think it requires some special AI engineering skills. In actuality, most of the problems I had to solve while implementing it were the good old server-side engineering - adding OAuth authentication (probably the biggest lift), sizing requests and tweaking timeouts for the upstream system calls, refactoring existing business logic to make it usable by both the existing API endpoints and the new MCP tools (e.g., the start_play tool from the above example invokes the same handler as the POST /api/plays endpoint), etc.

But some "AI engineering" still happened. I shipped a working PoC in less than a day (thanks to Claude Code & Fable). But the path from the PoC to a usable MVP took almost two weeks. While almost all tools in the PoC technically worked, the initial tool set, input and output schemas, and tool descriptions yielded rather suboptimal results when I tried pointing ChatGPT and Claude at the new MCP server. None of the above Personalized Tutor, Playground Builder, and Remote Infra prompts produced meaningful output with the original version of the MCP server.

Some examples:

• The first version of the search tool worked across all materials on the site - content, playgrounds, and documentation. But different documents have different filter criteria, and models kept confusing them. Splitting the "omnisearch" tool into three separate tools (search_content, search_playgrounds, search_docs) with independent input and output schemas made the problem go away immediately.
• The search and get tools would return the URL of the found document, but their description wouldn't ask to include the URL in the model's response, which led to rather bizarre results. I'd ask for a personalized learning path and get a bunch of great matches, but the model would give me no way to click on them (same behavior with both ChatGPT and Claude).
• Updating a playground requires its full manifest. The full manifest wouldn't always fit into a single MCP tool call response, so I returned a manifest URL instead. But playgrounds are created private by default, so such a URL cannot be fetched by the agent directly. And changing the playground's visibility would require a manifest update. A chicken-and-egg problem that I resolved by returning the paged manifest right in the MCP tool call response.
• The initial version of the get_playground tool lacked the cache bypass when invoked by the playground's author. A similar bypass exists in the GET /api/playgrounds/endpoint to prevent stale reads during active editing. The model would call update_playground, then follow up with get_playground to verify the changes, find the stale cached version, and enter an infinite edit-and-debug loop.

Things like that are virtually impossible to catch with automated testing. You can only spot them while using the product to solve real problems. And only once you spot & fix them can you (and should) cover them with tests so the implementation doesn't regress. The gap between a PoC and an MVP remains huge, and it's one of the key reasons I don't believe claims that "software development" has been solved.

Activity Log Heatmap

Ok, enough MCP chatter 🙈 Here is a nice little enhancement I recently added for the personal dashboard - a GitHub-style activity tracker:

The heatmap not only shows when/how much you have been using the labs but also the exact materials and playgrounds you used on a given day. Plus, you can filter it by categories to see how much learning effort you've put specifically into Linux, Networking, Containers, or Kubernetes topics.

Playground Run Settings

Since Playgrounds 2.0 (released over a year ago), it has become possible to customize playground settings. However, already started playground runs couldn't be edited. If you started a new playground with, say, only 1 VM, 2 CPUs, and 4 GB RAM, you wouldn't be able to add a second machine to it or change the CPU and memory limits later. But now you can!

Stop the running playground session (preserving the VM's state), then click the Settings button on the next page, and you'll be taken to a familiar playground settings UI (only a subset of playground knobs will be editable for a run, but it's better than nothing).

A nice bonus: you can now combine persistent and non-persistent drives. I.e., you can have a machine that boots up from its previous rootfs state, but its secondary drive is always backed by a fresh volume and discarded on termination. Or you can have a playground run with both persistent and ephemeral VMs.

Authentication via Google and GitLab

Last but not least. It has recently become possible to sign in/up on iximiuz Labs via Google and GitLab. GitHub lock-in is no more!

For existing users, it is also possible to link the labs account to a new or alternative login method on labs.iximiuz.com/account.

GitHub's recurring unavailability has been a great motivator.

Wrapping up

August was a weird month for iximiuz Labs. Signups and playground usage are up compared to June and July. But the revenue is significantly down - way below the sustainability level. To stimulate things a bit, I'm running the Fair Pricing pilot - you can pick your discount, no questions asked. If you've been considering upgrading your membership, now is a good time to both support the labs and get a good deal: https://labs.iximiuz.com/pricing​

Happy hacking,

Ivan