What you can ask

This page goes through every area a connected assistant can work in. For each one you get:

• what you can ask — plain requests that work,
• the tools the assistant uses, so you recognise them in your client,
• the thing to know — the behaviour that most often surprises people.

You never have to name a tool. Ask the way you would ask a colleague, and the assistant picks the tools. Which tools it has depends on your plan — see What your plan allows. Tools marked Pro below are not available on a Free account.

Before anything else: ids come from your lab list

Most lab tools need to know which lab. The assistant gets that from list_labs, which is the only place lab ids come from. If you have extra copies of a lab, they each have their own id — mention the copy's name ("my second Ubuntu copy") so the assistant picks the right one.

Two helpers are always there:

Tool	What it does
whoami	Confirms the connection, and reports your account, plan, tool tier and the organizations you can act for
help	The platform's own guide to every tool; the assistant reads it when it is unsure

Starting from an idea

What you can ask

• "I want to host a small website for my bakery. What do I need?"
• "I'd like to build a notes app with a database. Walk me through it."
• "Can you host my Flask project?"

Tool	What it does
plan_my_build	Lays out the decisions in the order they have to be made — which lab, whether you need a domain, a database, how it is published, what runs at startup — and which tools show the real options at each step. It deploys nothing and spends nothing. Pro

The thing to know: the assistant is asked not to choose for you. At each step it shows you what your platform actually offers and lets you pick. If you want its opinion, ask for it — it will say what it would choose and confirm before acting.

Labs: status and lifecycle

What you can ask

• "Which of my labs are running?"
• "Deploy my Essentials lab and give me the SSH command."
• "Pause my Kali lab, I'll be back after lunch."
• "My lab expires tomorrow — keep it going."

Tool	What it does
list_labs	Your labs, their state, and whether each is a copy
lab_info	A lab's addresses, username, password and web links
lab_status	deploying, deployed, stopped, paused or failed
lab_stats	Live CPU, memory and network for a running lab
lab_logs	The deploy log — the reason a deploy failed
deploy_lab	Deploy a lab, or redeploy one you already have. Also makes a new copy when asked. Pro
wait_for_deploy	Waits for a deploy to finish and reports the real outcome. Pro
list_tasks	Deploys and background processes still in progress. Pro
stop_lab	Stop a lab; your home directory is kept. Pro
pause_lab / resume_lab	Freeze a lab with everything still running, and continue it. Pro
terminate_lab	Destroy an extra copy. Irreversible. Pro
rename_lab	Rename an extra copy. Pro
renew_lab	Extend a lab's time by spending Jolt. Pro
verify_restart	Checks that a lab survives a stop and start with its data and sign-in intact. Pro

The things to know:

• Deploy and redeploy are the same request. Asking to deploy a lab you already have rebuilds it in place; it does not make a second one. A redeploy keeps your home directory and resets everything else, so the assistant should warn you before it rebuilds a lab you are working in.
• Deploys finish in the background. A deploy takes a minute or two, longer for heavy labs. deploy_lab returns as soon as the deploy is queued; the assistant then uses wait_for_deploy (or checks lab_status) and only tells you the lab is ready once it really is. If it fails, lab_logs has the reason.
• One deploy at a time. If a deploy of the same lab is already running, a second one is refused. That is a signal to wait, not to retry.
• Renewing costs Jolt; redeploying is free. A redeploy also resets the expiry clock, so it is usually the better answer to "keep my lab going". renew_lab is the only tool that spends anything.

Lab configuration

What you can ask

• "Put my Essentials lab on shop.selfmade.one."
• "Expose port 3000 of my lab as api.example.com."
• "Set my code-server password to something new."
• "Add a startup script that installs nginx on every deploy."
• "Keep my n8n lab always on."

Tool	What it does
configure_lab_routing	Domains for the lab's web port, HTTPS proxies for other ports, public expose proxies and TCP ports. Pro
configure_lab_runtime	Which SSH keys may log in, which private networks the lab joins, always-on, preferred address. Pro
set_lab_password	The lab's sudo, code-server or VNC password. Pro
lab_startup_script	Read or write the script that runs as root every time the lab deploys. Pro
lab_error_page	The page visitors see while the lab is down. Takes effect immediately. Pro

The things to know:

• These save; the next deploy applies. Except the error page, a configuration change does nothing to the running lab until it is deployed again. For routing, the assistant can save and redeploy in one step. If you change a setting and nothing happens, ask it to redeploy.
• Domains are sent as a complete list. When the assistant changes a lab's domains, it reads the current list first and sends back everything you want to keep. Proxies and ports are added one at a time without touching the others.
• Some options are gated. TCP ports and always-on need a paid plan or 5,000 Zeal, and the lab's template must allow them. When a gate is not met the setting is quietly ignored, so check the lab after deploying. See Publish ports and Lab settings.
• To run the startup script, redeploy. The script runs on every deploy, so after changing it, ask the assistant to redeploy the lab.
• Passwords cannot contain < followed by a letter. The platform would cut the value short; the assistant refuses it before sending and asks for a different one.

Working inside a lab

What you can ask

• "Open my project in the Essentials lab."
• "Run the tests and tell me what failed."
• "Install the dependencies and check the app starts."
• "Is anything listening on port 8000?"

Tool	What it does
open_workspace	Pins a lab and a folder for the conversation, so later requests do not have to name them. Shows the git state of the folder. Pro
workspace_info / close_workspace	Show or clear that pin. Pro
list_projects	Finds the git projects in a lab. Pro
lab_workspace	What is in the lab and what is running — the orientation call. Pro
run_command	Runs one command in the lab and returns its output, up to 15 minutes. Pro
lab_probe	Makes one web request from inside the lab — is the app actually answering? Pro
test_auto_login	Checks that a launchable app's one-click sign-in really works. Pro

The things to know:

• The lab must be running. Stopped and paused labs have nothing to run in.
• run_command is one-shot. A server started with it stops when the command ends. For anything that must keep running, the assistant uses start_lab_process (next section).
• Labs have no systemd. systemctl fails inside a lab; the assistant should use sudo service <name> restart.

Full detail in Workspace and files.

Files and processes

What you can ask

• "Show me the config file for my app."
• "Change the port in server.js to 8080."
• "Find every file that mentions DATABASE_URL."
• "Start the dev server in the background and show me its output."

Tool	What it does
read_lab_file	Read a file, page by page
write_lab_file / write_lab_files	Write one file, or scaffold many at once (up to 2 MB each)
edit_lab_file	Replace an exact piece of text in a file
list_lab_files / lab_file_tree	List a folder, or its whole shape
glob_lab_files	Find files by name pattern
grep_lab_files	Search inside files
move_lab_file	Move or rename; will not overwrite unless asked
create_lab_directory	Make a folder
delete_lab_path	Delete a file or folder. Not recoverable
download_lab_file	Pull a binary file, such as a build output, out of the lab (up to 16 MB)
start_lab_process	Start something that keeps running — a dev server, a worker
list_lab_processes	What the assistant started, and which ports are listening
lab_process_logs	The output of a process it started
stop_lab_process	Stop one
wait_for_process	Wait for a long job, such as a build, to finish and report its exit code

All of these are Pro.

The things to know:

• Only your home directory survives a redeploy. Files the assistant writes there are safe; changes elsewhere in the lab are lost on the next deploy.
• Background processes do not come back on their own. A redeploy stops them. To make one start every time, put it in the startup script.
• Starting a server does not publish it. To reach it from a browser, the port needs routing — see Worked examples.

Domains

What you can ask

• "What domains do I have, and which lab uses each?"
• "Register myshop.selfmade.one for me."
• "Add my own domain example.com."

Tool	What it does
list_domains	Your domains, whether each is verified, and the certificate covering it
add_domain	Register a name on a platform domain, or one you own. Pro
delete_domain	Remove a domain. Pro

The things to know:

• Your own domain needs DNS first. Point its A record at the platform before asking the assistant to add it; otherwise the add is refused. See Domains.
• Deleting a domain does not detach it from a running lab. Ask the assistant to update the lab's routing too.
• Platform-domain names are limited per account. See Plans and limits.

HTTPS and certificates

What you can ask

• "My site says not secure. Why?"
• "When does the certificate on my domain expire?"
• "The certificate expired and didn't renew — get it replaced."

Tool	What it does
list_ssl_certificates	Every certificate covering your domains, with expiry and status
ssl_troubleshoot	Explains why HTTPS is broken, with a fix for each finding
request_ssl_reissue	Asks for a broken certificate to be replaced. Pro
cancel_ssl_request	Withdraws that request. Pro

The things to know:

• Troubleshoot first. ssl_troubleshoot tells apart a DNS record pointing elsewhere (you fix it at your registrar), a refusal from the certificate authority, and old names the platform is already cleaning up (nothing for you to do).
• A re-issue is a request, not an instant fix. An administrator reviews it and applies approved requests on a schedule. A healthy certificate cannot be re-issued — it renews by itself.
• Checks are rate-limited. A few refreshes per ten minutes. After fixing DNS, wait for the platform's next check rather than asking again straight away.

More in HTTPS.

Services and databases

What you can ask

• "Create a PostgreSQL user for my app and a database called orders."
• "What databases do I have on MySQL?"
• "What's the MongoDB connection string for my user appsvc01?"

Tool	What it does
list_services	What you have on each service, as counts
add_service_user	Create a user on MySQL, MariaDB, PostgreSQL, MongoDB, Redis or RabbitMQ. Pro
remove_service_user	Delete a user and every database under it. Pro
list_databases	The databases belonging to one service user
create_database	Create a database under a service user. Pro
delete_database	Drop a database. Pro
service_credentials	The stored credential for a MongoDB user

The things to know:

• You choose the password. Nothing generates one: 8 to 64 characters, no apostrophe. Usernames are 5 to 16 letters, digits or underscores.
• Database names get your username as a prefix. Ask for orders under appsvc01 and you get appsvc01_orders.
• Only MongoDB passwords can be read back. For the other services, the password is shown on the web dashboard.
• The service-user limit is shared across all services. Creating on another service does not get around it.

More in Services.

Private networks and devices (WireGuard)

What you can ask

• "Add my laptop to the VPN and give me the config file."
• "Which of my devices connected recently?"
• "Create a private network for my team and share it with Priya."

Tool	What it does
list_devices	Your devices and when each last connected
add_device	Register a device. Free accounts can do this
device_config	The WireGuard configuration file. Free accounts can do this
delete_device	Remove a device. Free accounts can do this
list_networks	Public networks, yours, and those shared with you
create_network / delete_network	Create or remove a private network. Pro
share_network / unshare_network	Let someone use a network you own, or stop them. Pro
set_default_networks	Which networks your labs join by default. Pro

The thing to know: a device's configuration file may contain its private key. If you give the assistant your own public key instead, the platform never holds a secret for that device. Either way, treat the file like a password. See Devices and Private networks.

SSH keys

What you can ask

• "Add this public key to my account."
• "Which SSH keys do I have?"
• "Disable my old work laptop key."

Tool	What it does
list_ssh_keys	Your keys, including the ones mirrored from your Git account
add_ssh_key	Add a public key. Free accounts can do this
delete_ssh_key	Remove a key. Free accounts can do this
set_ssh_key_enabled	Turn a key off or on without deleting it. Free accounts can do this

The thing to know: if a lab is set to accept only particular keys, deleting or disabling those keys and then redeploying can leave you unable to log in to that lab. Ask the assistant to reset the lab's key selection first.

Storage

What you can ask

• "How much storage am I using?"
• "How much of our organization's storage is used?"

Tool	What it does
storage_usage	Your usage, or an organization's

The thing to know: storage is per account, not per lab — every lab shares one home directory, so filling it in one lab fills it for all of them. See Storage.

Organizations and departments

What you can ask

• "Give me an overview of the acme-labs organization."
• "Add these five people to acme-labs as members."
• "Make Priya an admin of acme-labs."
• "Before Ravi leaves, what would move if I transfer his things?"

Tool	What it does
org_overview	One view of an organization's networks, domains, services and storage
org_profile / org_storage	Its details and storage. Pro
org_add_member / org_add_members	Add one person, or several at once. Pro
org_remove_member / org_remove_members	Remove people. Pro
org_set_member_role	Change someone's role. Pro
org_transfer_preview	Shows exactly what a transfer from one member would move, and what blocks it. Changes nothing. Pro
org_transfer_execute	Carries out that transfer. Pro
create_department / update_department_limits	Create a department and set its limits. Pro

Acting for an organization. Tools for domains, services, WireGuard and storage can act as an organization instead of as you — say "for acme-labs" and the assistant adds the organization to the request. What it creates then belongs to the organization and is shared with its members. If you belong to a department inside that organization, act as the department instead; the plain organization is refused. Labs themselves are the exception — the lab tools always act on your own labs.

The things to know: you can only do what your role allows. A transfer never moves Zeal, Jolt, SSH keys or uploads, and running labs must be stopped first. See Organizations.

Your own lab templates

Authoring templates through the assistant is available to Pro accounts where template authoring is enabled — see Who can author templates.

What you can ask

• "Make a new template based on Ubuntu with Node 20 and PostgreSQL client."
• "Why won't my template build?"
• "Deploy my template for the first time."
• "Share my template with the data-science workgroup."

Tool	What it does
template_status	Where a template is — draft, building, built — and what the next step is waiting on
list_templates / template_info	Your templates, and one template's full details
create_template / fork_template / import_template	Start a template from scratch, from an existing lab, or from an import
list_forkable / list_categories	What you can fork, and the categories a template can have
read_template_file / write_template_file / edit_template_file / delete_template_file	The Dockerfile and other build files
configure_template	Name, stability, CPU, memory, ports, users
configure_template_edge	Rate limits, health check, error page, proxies, connection info
configure_template_auto_login / login_recon	One-click sign-in for an app in the lab
set_template_slug	The lab id the template deploys as. Fixed after the first deploy
build_template / wait_for_build / template_build_log	Build the image, wait for it, read the output
deploy_template	The template's first deploy; afterwards it deploys like any lab
list_template_deployments	Where it is deployed
template_diff	"Why isn't my change live?" — whether a rebuild has taken effect
export_template / upload_template_art	Export the build files; set the icon and cover image
set_template_visibility / share_template / unshare_template / template_shares	Who can see and deploy it
template_versions / restore_template_version	Earlier versions, and going back to one
delete_template	Delete a template. Irreversible, and asks for a typed confirmation

The things to know:

• The steps have an order: create → files and settings → build → move to beta → first deploy → share. template_status says which step is next.
• A new template starts in alpha, which blocks both deploying and sharing. Building does not change that; moving it to beta does.
• Any edit puts it back to draft. It still deploys, but cannot be shared until it is rebuilt.
• Sharing needs a paid plan or 7,500 Zeal. Publishing to the LabStore is done by an administrator.

More in Templates.

Your history

What you can ask

• "What did you do to my Essentials lab yesterday?"
• "Who stopped my lab?"
• "What has been refused recently, and why?"

Tool	What it does
my_history	Every action taken through a connected assistant on your account — which client, which tool, on what, allowed or refused. Pro
my_mcp_clients	Which clients act on your account. Pro

The same record is on the MCP page's Activity tab, on every plan. See History and safety.

Next

• What AI assistants cannot do: learning and competition features are closed to MCP

• Worked examples — these tools strung together into whole tasks

• Workspace and files — letting the assistant write code in a lab

• History and safety — what it cannot do, and how to check what it did