# Command Line (mdk)

Source: https://metadock.app/docs/cli

# Command Line (mdk)

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.

## What is the difference between metadock and mdk?

Two executables ship side by side in the install folder. They split along one line: only one of them ever opens a window.

Executable and What it is for

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.

Note

Ask `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.

## How do I turn the CLI on?

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.

-   •Part of MetaDock Pro: the pipe does not start on the base plan, the same way the other automation surfaces do not
-   •No key, no port, no base URL: the pipe is named per Windows user account and its permissions are restricted to that account
-   •Only MetaDock's own binary may connect: the app checks the code signature of the process on the other end of the pipe before answering it
-   •The app must already be running: mdk reports a closed app rather than starting one, so a command in a script never spawns a window you did not expect

## What are the first commands to run?

bash

```
mdk status
mdk tools
mdk help browser create
mdk browser create --url https://example.com
```

`mdk 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 and What it 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

## How does a tool name become a command?

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:

bash

```
mdk browser navigate <browser_uuid> https://example.com

mdk browser navigate --browser_uuid <uuid> --url https://example.com
```

Optional 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.

Tip

A missing required parameter is refused with the usage line rather than filled in from a default. A command that ran is a command you fully specified.

## How do I use the output in a script?

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.

bash

```
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:

powershell

```
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.

## Which global flags are there?

Flag and Effect

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.

## Can the CLI act as the MCP server too?

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.

Note

Setting up an AI client rather than a script? The [MCP server guide](https://metadock.app/docs/mcp) covers the config for each client, the HTTP transport, and how to choose which tools an assistant can reach.

## What else should I know?

-   •It drives the browsers you can see: the same visible, logged-in panels in your workspace, not a hidden copy
-   •One command, one process: nothing stays resident; there is no daemon or background service to manage
-   •The catalog is the contract: every command maps to one of the 198 tools, so what you script by hand is what an assistant calls
-   •Windows only: the pipe and the console shim are Windows-specific, matching the app

Tip

Prefer HTTP? The same catalog is reachable over REST, WebSocket, CDP and W3C WebDriver, 668 operations across the five surfaces. The [API getting-started guide](https://metadock.app/api-docs/getting-started) covers keys, base URLs, and a first request in each.

The command line is one way in. The overview covers the other four surfaces it shares a catalog with. [See the automation workflow](https://metadock.app/automation).

Trying this yourself? The 14\-day trial grants MetaDock Pro with no credit card.

[Start free trial](https://metadock.app/download)
