Scopes and Tools
How Authorization Works
Labs MCP uses standard OAuth: your AI tool never gets hold of your iximiuz Labs credentials - it only receives a token limited to the scopes you granted, and you can revoke that token at any time under Account → Connected apps.
This section explains how that grant is requested, narrowed, and enforced. If you're only here for the list of tools, skip straight to the catalog - the tools are grouped by the same scopes described below.
Lazy authorization
No sign-in is needed to start: the discovery tools (searching and reading the public catalog and the docs) work anonymously. Authorization kicks in the first time your AI tool calls a protected tool - starting a playground, running a shell command, checking your progress, etc. The client then sends you to the iximiuz Labs consent screen, which lists exactly which permissions are requested; nothing is granted until you approve.
Clients that cannot complete the OAuth flow (agents in remote VMs, CI jobs, headless tools) can use a pre-issued access token instead. Such tokens carry the scopes chosen at creation time and are enforced - and revoked - exactly like OAuth grants.
The eight scopes
Every protected tool requires exactly one scope. Scopes are drawn along two axes:
the product area (account, learning, playground, author) and the access level (read or write):
| Scope | What it allows |
|---|---|
account:read | Read your profile, progress, and daily practice |
account:write | Manage your daily practice and email notification settings |
learning:read | See what you're working on and coach you through it |
learning:write | Start and complete challenges, tutorials, courses, and skill paths for you |
playground:read | List and inspect your playgrounds and playground runs |
playground:write | Start and manage playgrounds; run shell commands in VMs; expose ports; create custom playgrounds |
author:read | Read your author profile |
author:write | Create and update your author profile; create new content drafts |
The author:* scopes are a pro feature - the consent screen offers them only to accounts with pro access.
Regardless of the scopes granted, shell commands run only in playgrounds you own.
Partial grants
The consent screen is not all-or-nothing: all requested scopes start checked, but you can uncheck any of them
before approving, and the grant covers only what you left checked.
The one rule is that a write scope implies its read sibling - unchecking playground:read also unchecks playground:write.
If your AI tool later needs a scope you didn't grant, the server responds with a challenge naming the missing scope, and a well-behaved client sends you back to the consent screen to extend the grant - again, only with your approval.
Grants vs. your agent's own approval prompts
Many AI tools have their own safety prompt - Claude Code, for example, asks "Do you want to allow this tool call?" before invoking an MCP tool. These are different layers:
- The agent's approval prompt is client-side. It's only as reliable as the tool
and its configuration (think
--dangerously-skip-permissions). - The grant is enforced by the Labs MCP server on every request. A call outside the granted scopes is rejected - no matter what the agent decided, promised, or was tricked into.
The grant is the hard boundary; the agent's prompts are a convenience on top. Grant generously to a chat assistant you supervise, narrowly to an autonomous agent.
Revoking access
Every connected AI tool and access token shows up under Account → Connected apps, along with the scopes it holds. Revoke it there at any time - the tokens stop working immediately, and reconnecting requires going through the consent screen (or minting a new token) again.
Discovery Tools (No Sign-In Required)
Everything the four use cases boil down to is plain MCP tools - 39 of them, grouped by product area and split into read (inspects, never modifies) and write (changes something: starts plays, runs commands, edits your settings). The split is exactly how the scopes are drawn, so this catalog doubles as a map of what each scope actually unlocks.
We start with the open-access group: the discovery tools work anonymously, without signing in to iximiuz Labs at all.
| Tool | What it does |
|---|---|
search_content | Search the Labs catalog - challenges, tutorials, courses, skill paths, and playgrounds - by free text and optional filters. |
get_content | Fetch a single piece of content's metadata and (access permitting) its full markdown body. |
search_docs | Search the iximiuz Labs documentation (the very docs you're reading). |
get_doc | Fetch a single documentation page - the platform's own manual. |
A few things to try:
› Find beginner-friendly Kubernetes challenges on iximiuz Labs.
› What's the 'Reproduce a Docker Bridge Network' challenge about - and how hard is it?
› How does playground persistence work? Check the Labs docs.
Learning and Account Tools
Learning
The tools behind the AI coach use case: coaching you through content and tracking your progress.
Read (learning:read):
| Tool | What it does |
|---|---|
assist_with_content | Coach you through a running challenge or lesson - checks your tasks, explains the next step, spoiler-free. |
Write (learning:write):
| Tool | What it does |
|---|---|
start_content | Start a challenge, tutorial, course lesson, skill path, or roadmap for you. |
complete_content | Mark a tutorial, lesson, skill path, or roadmap complete (challenges are excluded - their completion is verified server-side). |
Challenge completion is recorded server-side and is authoritative:
your assistant can check whether a task actually flipped to solved (via get_play_tasks),
but it cannot declare a challenge done on its own say-so.
› Start the 'Set Up NAT for a Container' challenge.
› I'm on task 2 of the NAT challenge and iptables looks right to me - what am I missing?
Account
Your profile, streaks, daily practice, and email settings.
Read (account:read):
| Tool | What it does |
|---|---|
get_my_profile | Your plan, join date, lifetime stats, GitHub identity, and notification settings. |
get_my_progress | Your learning activity - active days and streaks. |
get_daily_practice | Today's daily-practice challenge suggestions and whether each is solved. |
Write (account:write):
| Tool | What it does |
|---|---|
manage_daily_practice | Enable, disable, or reshuffle your daily practice. |
manage_notifications | Toggle newsletter and digest emails and their cadence. |
› Did I keep my streak alive this week?
› Today's challenge is too hard - reshuffle my daily practice.
Playground Tools
The largest group - and the one that powers both the playground builder and the agent sandbox use cases: starting VMs, running commands, exposing ports, and authoring custom playgrounds.
A note on terminology: a playground is a reusable environment definition (like docker or k3s),
while a play is a running (or stopped-but-kept) instance of one.
Shell commands run only in plays you own.
Read (playground:read):
| Tool | What it does |
|---|---|
list_playgrounds | Browse official, community, or your own custom playgrounds. |
get_playground_manifest | Inspect a playground's machines, networks, and setup. |
list_plays | List your running and stopped plays, or recent runs. |
get_play | A running play's live status: machines, conditions, expiry. |
get_play_tasks | Your task progress in a running challenge (spoiler-free). |
list_kernel_sources | List the VM kernels you can pick for custom machines. |
list_rootfs_sources | List the base OS images available for custom machines. |
scan_ports | Scan a VM for listening ports without exposing them. |
Write (playground:write):
| Tool | What it does |
|---|---|
start_play | Spin up a fresh playground VM (or VMs) with internet access. |
run_shell_command | Run a shell command inside your VM. |
write_file | Write a config, manifest, or script into your VM. |
expose_port | Publish a port on a VM as a public HTTPS URL. |
expose_shell | Share a browser terminal into your VM via a URL. |
persist_play | Keep a play's state instead of destroying it at expiry. |
stop_play | Stop a play, preserving its state. |
restart_play | Restart a stopped play, resuming from its preserved state. |
destroy_play | Permanently delete a play and its state (irreversible). |
set_play_title | Rename a play. |
set_play_lifetime | Extend how long a play runs before expiring. |
create_playground | Create a reusable custom playground from a base and a manifest. |
update_playground | Replace a custom playground's manifest. |
remove_playground | Delete a custom playground. |
save_play_as_playground | Snapshot a stopped play into a new reusable playground. |
A few things worth knowing about how agents use these tools in practice:
- Long-running commands (builds, downloads, servers) outlast a single
run_shell_commandcall's timeout. Agents are instructed to launch them detached (nohup ... &) and poll the output with follow-up calls. - Exposing a port or a shell creates a public URL. Agents are instructed to confirm with you what they're about to expose and why - but remember that the hard boundary is always the grant, not the agent's manners.
- The custom-playground tools speak the same manifest language you may know from the Custom Playgrounds module - everything an agent builds, you can inspect, tweak, and share like any other custom playground.
› Give me a clean Ubuntu 24.04 VM.
› Run kubectl get pods -A and tell me what's crashlooping.
› Expose port 3000 so I can open the app on my phone.
› Snapshot this setup as a playground so my study group can start from it.
Author Tools (Pro)
The tools behind the create and teach use case.
They act on your real author profile and create real content drafts,
which is why they live behind the pro-only author:* scopes -
and why agents are instructed to confirm intent before creating or updating anything.
Read (author:read):
| Tool | What it does |
|---|---|
get_author_profile | Your author profile: bio, avatar, social links, stats, and the public page URL. |
Write (author:write):
| Tool | What it does |
|---|---|
create_author_profile | Create your author profile - a prerequisite for creating content. |
update_author_profile | Update your display name, bio, avatar, or social links. |
create_content | Start a new draft tutorial, challenge, course, skill path, roadmap, or blog post. |
Drafts created this way land in your usual authoring flow - review and publish them as described in the Content Authoring module.
› Do I have an author profile yet?
› Start a draft tutorial titled 'Debugging DNS Inside Containers'.
- Previous
- Connecting Your AI Tool