← Help contents

MCP Server

Letting the AI agent you already use reach your serial port

The AI assistant built into the app can send frames, read the terminal buffer and run scripts, because it sits next to them. The MCP server opens the same set of tools to an assistant that lives outside the app — Claude Code in your terminal, Cursor, VS Code Copilot, Windsurf.

Why bother, when there is an assistant inside already? Because the agent outside is the one holding your firmware. It can read the source that produced a frame, send that frame, see what the device answered, and change the code — without you copying anything between two windows.

💡 MCP needs a subscription — the same plans as Lua scripting and charts. See Pricing & Plans.

What the agent gets

Every tool the app has, in the shape MCP clients expect: the serial port, the terminal buffer, macros, triggers, the Lua engine, the programmer, the calculation helpers. Not a chosen subset — the same registry the built-in assistant uses.

Anything an outside client sends to your device shows up in the terminal under TX_MCP, so a frame you did not type is never confused with one you did (see the Terminal chapter).

Connecting a client

The connection is a command, not a network address: the client starts comio-studio --mcp and talks to it over its standard input and output. Nothing listens on a port, so nothing is exposed to your network.

Put the entry below in your client's configuration file, replacing /path/to/comio-studio with the actual location of the executable:

{
  "mcpServers": {
    "comio-studio": {
      "command": "/path/to/comio-studio",
      "args": ["--mcp"]
    }
  }
}

Where that file goes depends on the client:

  • Claude Code.mcp.json in your project root, or ~/.claude/mcp.json to have it everywhere.
  • Cursor.cursor/mcp.json in your project root.
  • Windsurf~/.codeium/windsurf/mcp_config.json.
  • VS Code.vscode/mcp.json in your project root, and the shape is slightly different: the outer key is servers instead of mcpServers, with "type": "stdio" added inside the entry.

Two modes, chosen for you

What the agent sees depends on whether the application is running at the time — it works out which on its own, with nothing to configure:

  • ComIO.Studio is open — the agent is connected to that instance. It sees the port you already have open, the data already in the terminal, the macros you defined. Anything it does appears in the window in front of you. This is the useful case: you keep working, and the agent works alongside you on the same session.
  • ComIO.Studio is not open — the command starts a headless instance of its own, with the full set of modules and no window. Good for automation with no one watching; it has its own state and knows nothing about any earlier session.

Nothing runs without permission

An outside client does not get a free pass. Tools marked as needing confirmation are held at the gate, exactly as they are for the built-in assistant — but because there is no conversation to put the question into, it arrives as a separate window titled External tool request, saying which tool wants to run and that it is not part of any chat in this app.

  • You have 120 seconds to answer. No answer means the call does not happen — silence never counts as approval.
  • Several requests at once queue up rather than replacing each other; the window carries a number and a count of what is still waiting, so two identical requests in a row are told apart.
  • Each tool can be set to allow (runs without asking), confirm (asks every time) or off (refused without asking).
⚠ There is no “allow for this session”. A tool set to confirm asks on every call. If an agent will use one tool dozens of times in a row and you trust it there, set that tool to allow — and set it back when you are done.
💡 It is still your serial port. An agent connected this way can drive a live machine. Treat “allow” on a tool that writes to the port the same way you would treat handing someone the keyboard.