Loading documentation
Every automation tool MetaDock exposes is also a shell command. mdk talks to your running MetaDock over a local named pipe, so there is no port to open, no base URL, and no API key to manage. It is the fastest way to script the browsers you already have open, and the same 198 tools the MCP server advertises.
Two executables ship side by side in the install folder. They split along one line: only one of them ever opens a window.
| Executable | What it is for |
|---|---|
| metadock.exe | The app itself. Opens the window, opens a URL or a file you pass it, runs the stdio MCP server your AI client launches, and accepts the same commands mdk does |
| mdk.exe | The console front end. Runs one command and exits, printing its result. Never opens a window |
The split exists because of how Windows starts a program. metadock.exe is a GUI-subsystem binary, so a shell does not wait for it: type a command and your prompt returns before the output arrives, interleaved with it. mdk.exe is a console binary, so the shell waits and the output lands in order. It holds no logic of its own; it forwards your arguments to metadock.exe and exits with whatever the command returned.
mdk to open a URL and it will tell you to use metadock instead. That refusal is deliberate: mdk waits for the process it starts, so launching the app from it would tie up your terminal for the whole session.Enable the Local CLI connection under Settings → API, Automation & AI. It is off until you turn it on, it takes effect immediately with no restart, and the Install to desktop tools button switches it on for you as a side effect of wiring up an MCP client.
The first connection after each app launch raises an approval prompt in the app, listed as MetaDock CLI. Approve it and the rest of that session runs without interruption; expect the prompt again after a restart unless you have chosen to always allow.
mdk status
mdk tools
mdk help browser create
mdk browser create --url https://example.commdk tools prints every command available to you right now, grouped by area. It is not a static list: it is the live tool catalog, so a group you have switched off in settings does not appear. mdk help <command>prints one command's parameters, their types, which are required, and what each one does.
| Command | What it does |
|---|---|
| mdk tools | List every command, grouped by area |
| mdk help <command> | Show one command's parameters and types |
| mdk status | Report whether the app is running |
| mdk version | Print the CLI and app versions |
| mdk quit | Close the running app |
| mdk <group> <command> | Run one command, e.g. mdk layout list |
Underscores become spaces. The browser_navigate tool is mdk browser navigate, workspace_switch is mdk workspace switch, and so on across all 198 of them. If you know the MCP catalog you already know the command set, and the reverse is true too.
Required parameters can be given positionally, in the order mdk help lists them, or by flag. Both lines below do the same thing:
mdk browser navigate <browser_uuid> https://example.com
mdk browser navigate --browser_uuid <uuid> --url https://example.comOptional parameters are always flags. Values are coerced to the type the schema declares, so a number stays a number and a comma-separated list becomes an array.
By default each command prints a readable result. Add --json to get the raw JSON payload instead, which is what you want when something downstream is parsing it.
mdk browser create --url https://example.com --json
mdk browser get links <uuid> --json | jq -r '.links[].href'A parameter value of - is read from standard input, which keeps long values out of your shell history and out of the argument length limit. It is the natural way to hand over a script file:
Get-Content script.js | mdk browser execute js <uuid> -Exit codes are conventional: 0 on success, non-zero when the command failed, the app was not reachable, or the arguments did not validate. A shell script can branch on that without parsing anything.
| Flag | Effect |
|---|---|
| --json | Print the raw JSON result instead of the readable summary |
| --no-cache | Re-fetch the tool schema instead of using the cached copy |
| --no-launch | Report that the app is closed rather than starting it. Already implied by mdk; it applies when you run a command through metadock.exe, which does start the app for you |
The schema cache is what makes the CLI feel instant: the command tree is fetched once per app version rather than on every invocation. --no-cache is the escape hatch if you have just changed which tools are exposed and want the listing to catch up immediately, since a settings change does not bump the version the cache is keyed on.
Yes. metadock.exe mcp runs the stdio MCP server your AI client launches, and mdk.exe mcp bridges the same thing through the console binary. The Install to desktop tools button writes a metadock.exe entry; either command works, and both need the same Local CLI connection enabled.