Labs MCP in Practice

This section walks through the main use cases with prompts that were actually run against Labs MCP from ChatGPT, Claude, and CLI coding agents. Every prompt below is copy-paste ready - the only prerequisite is a connected AI tool.

Finding what to practice

Paired with the site-wide search, Labs MCP lets you request learning paths tailored to your current needs. The simplest form is a filtered catalog query in plain English:

› Find me Linux troubleshooting scenarios to practice on iximiuz Labs. No containers or Kubernetes yet, please.

Behind the scenes, the assistant calls search_content with the right facets (categories, kinds, difficulty) and returns a short list of matches with links. You could achieve the same by playing with the filters in the catalog, but it's handy to just say what you want.

Search becomes noticeably more useful when the request needs judgment on top of full-text matching:

› Find me a few Kubernetes challenges on advanced ConfigMap use cases.

Not every challenge that mentions ConfigMaps is about ConfigMap manipulation, so the assistant has to read the candidates (get_content) and filter out the false positives - something the plain catalog search cannot do. In practice, Claude and ChatGPT both produce a solid short list for prompts like this.

Getting unstuck

The tutor is not limited to search. When you get stuck in a challenge, a tutorial, or a course lesson, ask for help without even naming the material:

› I'm stuck with this iximiuz Labs challenge. Help me out.

A well-behaved assistant then works it out on its own:

1. list_plays - find your currently running playgrounds
2. Spot which one corresponds to a challenge
3. get_content and get_play_tasks - read the challenge text and your per-task status
4. assist_with_content (and, if needed, read-only run_shell_command diagnostics in your VM)
5. Give you a hint for the task you're stuck on - without revealing the solution

The spoiler-free behavior is part of the tool descriptions: the assistant is instructed to coach, not to solve. If you still want the full solution after an honest attempt, ask for it explicitly.

Prompts to try

› Build me a two-week plan to get comfortable with Kubernetes - one hour a day, hands-on only.

› Which medium-difficulty networking challenges haven't I solved yet? Start the easiest one.

› I'm on task 2 of the NAT challenge and iptables looks right to me - what am I missing?

› Explain the 'Reproduce a Docker Bridge Network' challenge to me before I start it.

Preparing a practice environment is an interesting exercise in itself, but more often than not you don't have time for such a detour and want to jump straight to the target system. Labs MCP turns environment preparation into a prompt.

A multi-network topology from one sentence

› Create a playground with 5 VMs split into two isolated networks.
  One network should be private (no Internet access), and the other should be public.
  One of the VMs should sit in both networks and act as a router.
  Briefly describe the final setup.

This prompt took ChatGPT about three and a half minutes end to end, and the result - Dual-Network Router Lab - is close to the hand-crafted environment behind the NAT gateway challenge. The agent also wrote a description and a walkthrough, which you can find on the playground's page.

Under the hood, the agent picks a base with search_playgrounds, studies its manifest with get_playground, and calls create_playground with a multi-network manifest - the same manifest language you would write by hand.

Deploying a demo app

Another frequent need is a demo application to poke at while learning a technology - Istio's Bookinfo, Grafana's QuickPizza, Jaeger's HotROD, etc.:

› Deploy the https://github.com/jaegertracing/jaeger HotROD app to a k3s playground and write a brief walkthrough.

Claude (in cowork mode, launched from the web interface) spent about ten minutes on this and delivered a running K3s playground with a few microservices deployed and Jaeger collecting and visualizing traces. The flow is: start_play (the official k3s playground), a series of write_file and run_shell_command calls to apply manifests and wait for the rollout, and expose_port to hand you the UI URLs.

Saving the result as a reusable playground

A running play expires; a custom playground does not. When you like what the agent built, ask it to persist the result:

› Stop the playground run and save the snapshot as a reusable custom playground.
  Update the playground manifest to expose the demo app and Jaeger as UI tabs.
  Place the walkthrough into the playground's description.

That's stop_play → save_play_as_playground → update_playground (adding UI tabs and the markdown description). Here is the playground produced by the above follow-up: HotROD + Jaeger on K3s. Like the dual-network one, it has a helpful walkthrough on its front page.

Larger, longer tasks

The HotROD app is already non-trivial, but the same approach scales to much bigger targets:

› Deploy https://github.com/open-telemetry/opentelemetry-demo to a k3s playground and write a brief walkthrough.

The OpenTelemetry demo needs over 15 GB of container images, and it takes an agent roughly 30 minutes to set everything up end to end - including some debugging along the way. Both Claude and ChatGPT managed to produce a working setup, unattended. Long-running tasks like this one are what Labs MCP is designed for: the agent launches heavy steps detached in the VM and polls their progress with quick follow-up calls (see Playground Tools).

Which AI tool mode to use

Playground building is an agentic, multi-step job. Use:

• The work/cowork (agent) mode of ChatGPT or Claude - via the web interface or the desktop app
• A CLI coding agent - Claude Code, Codex, OpenCode, and the like - connected as described in Coding Agents and IDEs

Plain chat mode usually won't cut it: a single context window fills up quickly when the model has to keep large Kubernetes and playground manifests in it while debugging a rollout.

Prompts to try

› Start the K3s playground, helm-install Argo CD, and give me the UI URL and the admin password.

› Deploy a demo microservice app on K0s and break it in three subtle ways. Don't tell me what you broke.

› Set up a 3-tier app across five VMs - an LB, two instances of the API service, and a replicated DB.

› Save this setup as a private playground named 'my-argocd-lab' and share it with github user octocat.

Agents often run in a tiny container, a constrained runtime, or a full VM - but with the wrong kernel or Linux distro. Yet you may need that agent to author a shell script that works on all mainstream distros, deploy and test an application that only reveals its cracks on a real multi-node Kubernetes cluster, or debug something that simply cannot run in the agent's sandbox (gVisor, Kata Containers, eBPF, ...).

iximiuz Labs is not in the agent-sandboxing business: even with Labs MCP, the agent is expected to run outside the playgrounds it controls. Where playgrounds fit is providing realistic remote infrastructure for agents to run and test the software they work on.

Cross-distro testing

The simplest form - pair your coding agent with Labs MCP and say:

› This script works on Ubuntu but fails on Fedora. Test it across the mainstream Linux playgrounds and make it portable.

The agent starts the relevant official playgrounds (search_playgrounds → start_play), copies the script in (write_file), runs it on each VM, fixes it locally, and repeats until it passes everywhere.

Real clusters and exotic runtimes

Anything that needs a real kernel, nested virtualization, or a multi-node cluster is a good fit:

› Using the K3s playground, clone the https://github.com/kubernetes-sigs/agent-sandbox repo
  and deploy its OpenClaw + gVisor example. Expose OpenClaw with a public URL.
  Briefly explain the final setup and how to use it.

The result of this prompt is OpenClaw on K3s with agent-sandbox + gVisor - a 3-node K3s cluster with gVisor's runsc, the agent-sandbox controllers, and the example app deployed, with the OpenClaw UI exposed as a tab.

One environment per branch (or per agent)

Git worktrees isolate source trees, but not ports, databases, or dev servers. Local containers help to a point, but the dev machine's capacity quickly becomes the bottleneck. With Labs MCP, different branches - or different agents - get separate remote environments instead of competing for the same laptop:

› Deploy these three feature branches independently and give me a URL for each one.

Each branch lands in its own play, and expose_port returns a public HTTPS URL per deployment.

Bug reproduction that outlives the session

Ask the agent to clone a repository, check out the exact commit, reproduce the failure, and preserve the resulting machine state:

› Check out commit 8ac21f, reproduce issue #423, and save the working repro as a reusable playground.

Such a repro persists beyond the agent session as a custom playground that anyone with access can start and reopen later - instead of being reduced to a (questionable) list of reproduction steps in an issue comment.

Keeping an eye on the agent

Unlike black-box sandboxes, you see and keep everything the agent does:

• SSH into the VM to watch or take over mid-task
• Expose ports as public HTTPS URLs to demo what it built
• Persist the play to resume tomorrow

And the grant is the hard boundary: an agent holding only playground:* scopes gets its VMs but cannot touch your learning progress, account settings, or author profile.

Prompts to try

› My install script works on Ubuntu but dies on Alpine. Start both VMs and find where they diverge.

› Run the integration test suite of this repo on a 3-node Kubernetes cluster and report what fails.

› Build the Docker Compose app in this repo on a remote VM, expose the frontend, and send me the URL.