Munk AI logoMunk AI
Install
Back to Docs
Interfaces

Interfaces and Entry Points

Choose the right way to use Munk AI across CLI, MCP, GUI, and Local API.

Munk AI supports multiple entry points so you can use the same product in different ways.

Start with the CLI if you are unsure

For most developers, the CLI is the best place to begin. It is the clearest path for:

  • local experimentation
  • first-time setup checks
  • running execution workflows directly
  • validating a code change from the terminal

The CLI is a strong default because it covers the three things most teams need first:

  • checking whether the environment is ready
  • generating or running test plans
  • validating a code change directly from the terminal

If you are touching Munk AI for the first time, this is a practical starting sequence:

munk doctor
munk serve --host 127.0.0.1 --port 16888
munk verify change --request-file /path/to/verify-change.request.json --config /path/to/config.yaml --json

Those three steps map to:

  • doctor: verify that the runtime and local environment are usable
  • serve: start the local Web UI and Local API
  • verify change: run a real verification workflow against a code change

The four CLI command groups you should learn first

If you do not want to memorize the full command tree yet, start with these:

munk doctor
munk serve --host 127.0.0.1 --port 16888
munk verify change --request-file /path/to/verify-change.request.json --config /path/to/config.yaml --json
munk plan --app-id your.app.id --requirement-doc /path/to/PRD.md --technical-doc /path/to/TECHNICAL_DESIGN.md --config /path/to/config.yaml
munk run plan --app-id your.app.id --plan-id your-plan-id --package com.example.app --device-ref your-device-ref --config /path/to/config.yaml

In practice:

  • doctor checks environment readiness
  • serve brings up the local page and GUI entry
  • plan / run plan cover formal test asset generation and execution
  • verify change is the fastest review-first validation path for a code change

If you simply want to understand how Munk AI works end to end, use this path:

  1. Run munk doctor
  2. Run munk serve
  3. Use munk verify change for code-change validation
  4. Use munk plan followed by munk run plan for requirement-level test assets

This sequence helps because it:

  • starts with the easiest success case
  • avoids forcing you to learn the entire command tree at once
  • builds the mental model of environment -> plan -> execution -> report

How device selection works

Execution-related CLI commands now use the cross-platform --device-ref parameter rather than the older Android-specific serial wording.

For example:

munk run case \
  --app-id your.app.id \
  --plan-id your-plan-id \
  --case-id your-case-id \
  --package com.example.app \
  --device-ref your-device-ref \
  --config /path/to/config.yaml

If you are unsure which devices are currently visible, list them first:

munk devices list --json

When to stay in the CLI

For most developers, the CLI should remain the default interface, especially when you want to:

  • debug a local execution flow
  • trigger validation from the terminal
  • wire Munk AI into scripts or CI steps
  • inspect operations, artifacts, or available devices quickly

Use MCP when an agent is driving the workflow

MCP is the right choice when you want Munk AI to act as a tool surface for a coding agent or assistant. This is especially useful when an agent needs to trigger verification as part of a larger implementation loop.

Use the Local API when you need HTTP access

The Local API is useful when you want to integrate Munk AI into a local service, automation wrapper, or internal tool that talks over HTTP instead of calling the CLI directly.

Use the GUI for local recording and inspection

The browser-based GUI is most relevant when you are working with recording, local inspection, and live interaction flows. In practice, you usually reach it by running:

munk serve --host 127.0.0.1 --port 16888

Then opening the local page exposed by the runtime.

A simple rule of thumb

Use this default decision path:

  • Start with CLI for direct local usage
  • Use MCP for agent-driven workflows
  • Use Local API for HTTP-based integration
  • Use GUI for recording and local inspection

If you want the full command tree, parameters, and more examples, continue to the CLI reference documentation.