VibeControls
Ask AI
Developer Tools2 illustrations

Command-Line and MCP Control

Sign in, pick a workspace and manage sessions from your terminal, or let an MCP-capable AI assistant do it for you.

These images are illustrations of the concept, not screenshots of the actual product.

Overview

Command-Line and MCP Control brings the VibeControls fleet to two places where developers increasingly work without opening a dashboard: the terminal and an AI assistant's chat. The concept pairs a command-line tool, which signs in, picks a workspace and lists sessions in a few commands, with an MCP server that exposes the same operations as tools an MCP-capable assistant can call on a developer's behalf.

The problem it addresses is context switching. Checking which sessions are running on a production box, or starting a fresh terminal for a project, normally means leaving the shell or the chat, opening a browser and clicking through several views. The design envisions both surfaces working against the same workspace, agents and sessions as the web app, so the answer is the same wherever the question is asked.

The CLI illustration walks through a first run. A device-code login prints a one-time code to enter in the browser, polls until it is approved and confirms the signed-in account, so no password is typed into the terminal. A workspace command then sets the active workspace, and a sessions list command renders a bordered table of session ID, vibe, target, session type, status and uptime, with colored Running, Completed and Failed states and a one-line summary of totals underneath.

The MCP illustration shows the same fleet from inside an AI chat. Asked in plain language to set up a project on a named server and show what is already running, the assistant calls three VibeControls tools in turn, listing connected agents, listing the project's sessions and starting a new tmux session. Each call appears as a collapsible card with its input and result, and the assistant closes by noting that every call ran as the signed-in user and was recorded in the workspace audit trail.

Because both surfaces are designed to act as the user rather than as a separate service identity, they sit inside the product's usual permissions, audit and usage tracking. Sessions created from the terminal or an assistant are meant to appear alongside those started in the browser, where they can be opened, shared or stopped.

What this concept shows

  • Browser-based device-code login that confirms the signed-in account without a password typed into the terminal
  • Workspace selection from the command line, confirmed with the workspace's display name
  • Sessions table with session ID, vibe, target, type, status and uptime columns
  • Color-coded Running, Completed and Failed states with a totals summary line
  • MCP tools for listing agents, listing a project's sessions and starting a new session
  • Collapsible tool-call cards that show each call's input, result and status badge
  • A connection chip showing the MCP server as connected and how many tools it exposes
  • Assistant-initiated calls attributed to the signed-in user and recorded in the workspace audit trail

How it works

  1. Run the login command, open the device page in a browser and enter the one-time code shown in the terminal.
  2. Wait for the CLI to confirm the signed-in account, then set the workspace you want to work in.
  3. List sessions as a table to see which vibes are running on which targets, with their type, status and uptime.
  4. Connect an MCP-capable AI assistant to the VibeControls MCP server and check that the connection chip shows it as connected.
  5. Ask the assistant in plain language to check agents, review a project's sessions or start a new one.
  6. Expand the tool-call cards to review each input and result, then pick up the new session from the terminal or the web app.

Who it's for

  • Developers who prefer the terminal to a browser dashboard
  • Platform and DevOps engineers scripting session checks across servers
  • Developers who hand routine operations to an AI assistant
  • Engineering leads who need assistant-initiated actions attributed and audited

Illustrations

2 illustrations of this concept. Select one to view it full size.

Device-Code Login and Sessions Table in the CLI

The CLI signs in with a device code, sets the workspace and lists sessions as a formatted table.

This illustration shows a standalone terminal window open in a sample project folder on a developer laptop. Three commands run in sequence. The login command prints a device page to visit and a short one-time code, reports that it is waiting for authorization and polling every few seconds, then confirms with a check mark which sample account is signed in and notes that tokens were stored in a local configuration file. A workspace command sets the active workspace and echoes its display name. A sessions list command, asked for table output, renders a bordered table with Session ID, Vibe, Target, Type, Status and Uptime columns. Five sample rows mix tmux and plain terminal sessions across production, staging, GPU, CI and laptop targets, with green Running, grey Completed and red Failed badges, uptimes for the running sessions and dashes for the ended ones. A summary line counts sessions by state, and the cursor waits for the next command.

AI Assistant Driving the MCP Server

An MCP-capable assistant lists agents and sessions, then starts a session, showing each tool call inline.

This illustration shows a desktop AI assistant chat window connected to the VibeControls MCP server. The user asks in plain language to set up a sample payments project on a named server and show what is already running. The assistant replies with three collapsible tool-call cards, each with status badges and Input and Result rows. The first lists connected agents and returns a summary of six sample machines, one flagged as degraded. The second lists sessions for the project and returns two running tmux sessions with uptimes, the same sample sessions shown in the CLI table. The third starts a session with the project, target and tmux type as input and returns a new session ID with a Running badge. The assistant summarizes its findings between the cards and closes by stating that every call ran as the signed-in user and was audited in the workspace. A chip above the message box shows the MCP server as connected, with the number of tools it exposes.

Topics

  • developer CLI for agent fleets
  • device code login CLI
  • list terminal sessions from the command line
  • tmux session management CLI
  • MCP server for developer tools
  • Model Context Protocol server
  • AI assistant start terminal session
  • manage coding agents from AI chat
  • audited AI tool calls
  • scriptable session management

Related concepts

All VibeControls concepts
Get started freeBrowse all concepts

We use cookies for essential site functions and, with your consent, for analytics to improve VibeControls. We don't use advertising or cross-site tracking cookies. See our Cookie Policy.

Preferences