AI agents over MCP

An AI agent can drive your Qt application through veriCue: ask what is on screen, click things, read properties back, look at screenshots. It goes through the same Runtime, the same protocol, the same authentication and the same licensing a human test author uses. MCP is an adapter over veriCue, not a second way in.

The practical use is test authoring. An agent that can look at the real application writes tests against object paths that exist, instead of ones it guessed from your source.

Generated tests need review

An agent can confirm what it saw. It cannot know what your feature is supposed to do, which assertions matter, or which ones will be flaky on someone else's machine. Treat what it writes as a first draft.

Install

The MCP SDK is an optional extra, so a normal install stays small:

pip install 'vericue[mcp]'

Point it at an application

Three ways, matching how veriCue is used generally.

Start the application yourself (simplest)

vericue mcp --run ./your-qt-app

This starts the application through vericue run and drives it. The launcher keeps sole ownership of the compatibility checks, so the same targets are supported and the same refusals appear - MCP adds no envelope of its own. When the MCP server exits, the application it started is stopped.

Everything after -- goes to the application:

vericue mcp --run ./your-qt-app -- --config prod.ini

Attach to a running application

Over local IPC, which is the default an injected Linux run announces:

vericue mcp --endpoint /run/user/1000/vericue/vericue-4213.sock

Over TCP - and the supported transport on Windows:

vericue mcp --port 4242

Configure your MCP client

The server speaks MCP over stdio. A typical client configuration:

{
  "mcpServers": {
    "vericue": {
      "command": "vericue",
      "args": ["mcp", "--run", "/path/to/your-qt-app"]
    }
  }
}

vericue mcp is the canonical form. A vericue-mcp command is also installed for clients that take a bare command with no subcommand; it accepts the same arguments.

We do not list which AI products this works with. Any client that speaks MCP over stdio should work, and naming products we have not actually configured would be a claim rather than information.

What the agent gets

A deliberately small tool set. veriCue speaks 42 protocol commands; exposing all of them gives an agent more ways to get lost than to succeed.

Tool	For
app_info, list_windows	orient: what is running, which windows exist
object_tree, find_objects	find things by name or class
get_properties	read state back
screenshot	see it, as a real image
click, type_text, key_press	act, as real Qt events
set_property	set up state directly
wait_for_property	wait for something instead of sleeping

Plus a vericue://pytest-pattern resource and a write_a_test prompt that tells the agent to work from the running application rather than from memory.

Replies are bounded

object_tree and find_objects trim their output by default - four levels and 200 nodes, 50 results. A real Qt tree is thousands of nodes, and handing that to a model spends its context on layout objects and spacers before it reaches what you asked about.

When a reply is trimmed it says so, with truncated: true and a count of what was dropped. A trimmed tree never silently pretends to be the whole application. Narrowing with root= is usually better than raising the limit.

Authentication, sessions, platforms

--token, or VERICUE_TOKEN, is passed through to the Runtime. It is never written to tool output or logs.

An MCP session is a concurrent automation session like any other client. On a trial licence, with its single session, an MCP server and a pytest run cannot both be connected. A connect that arrives while a previous session is still being released is waited out with a short bounded backoff, exactly as the Python client does elsewhere - the server's accounting stays authoritative.

When the server starts the application itself, it waits up to 15 seconds for the first window before answering discovery. vericue run announces the endpoint before the application exists, so the Runtime can be reachable while the UI is still being built - and an empty window list reads to an agent as a fact about the application rather than a moment in its startup. The wait is bounded because an application may legitimately run without a window: if none appears, list_windows returns the empty list and says why, so an agent can tell "still starting" from "windowless". Attaching to an endpoint that is already listening never waits.

Platform support is whatever vericue run supports, because that is what starts the application: Linux x64 and Windows x64, dynamically linked Qt. Linux prefers local IPC for a same-host run; Windows is TCP only. macOS has no launch-time path - attach to an embedded Runtime instead.

Limitations

• The agent sees what veriCue can see: QObject properties, the object tree, rendered pixels. It does not read your source.
• Recording and baseline management are not exposed. Both need a human deciding what is correct.
• A screenshot proves what was rendered, not that it was right.