Workflow and integrations — VisualMCP

`run_plan`: a graph of calls, one round trip

run_plan executes a whole dependency graph inside the server, with no model in the loop. A step is either a tool call — any tool, by name, with the argument names its schema uses — or a shell command. Steps declare what they dependsOn and which paths they write: two steps whose paths overlap never run at the same time, which is what makes parallel edits safe. The plan is validated before anything runs — a duplicate id, an unknown tool or a cycle rejects the whole thing — and a failed step skips its dependents.

{
  "name": "tidy-and-verify",
  "steps": [
    { "id": "simplify", "kind": "tool", "tool": "simplify_code",
      "arguments": { "scope": "project", "projectName": "MyApp",
                     "rules": "IDE0028,IDE0041", "dryRun": false },
      "paths": ["src/MyApp"] },
    { "id": "build", "kind": "command",
      "command": "dotnet build src/MyApp/MyApp.csproj -c Release",
      "dependsOn": ["simplify"], "timeoutSeconds": 300 }
  ]
}

Use it for mechanical work — the same operation over many files, or a build that depends on a set of edits. Steps that need judgement between them are still the model's job.

Planning and memory

The board lives in the solution store, so it survives restarts and is scoped to the solution: cards move across backlog → todo → in_progress → review → done, carry comments and full change history, and board_brief answers “what is missing, what comes next” in one compact call. create_task_checklist puts a multi-step operation on the board as one card with the steps as a checklist.

Memory is the board's second lane: a fact, a decision or a constraint goes to board_remember under a topic — one current version per topic, writing again supersedes instead of duplicating — and board_recall reads it back. Pinned notes ride along in board_brief and in read_project_docs, which is what makes writing one worth the call.

Git, as data

The daily flow and the history operations that usually need a terminal: status, diff, log, blame, stage and commit, branches, squash, amend, reset, merge, rebase, cherry-pick, revert, stash, named patches, remotes, tags, push and pull. The interesting part is what stops being terminal-shaped:

A merge conflict is data. git_conflicts lists the conflicted files with their hunks — ours, theirs, base — and resolves each hunk by strategy or custom content, then stages the file and tells you whether to continue or abort.
An interactive rebase without an editor. git_rebase action=plan takes a JSON list of pick/reword/squash/fixup/drop steps and executes it exactly; reword and squash take their message from the step.
Destructive actions are gated. git_reset with mode=hard and git_sync with force=true require confirm=true; force uses --force-with-lease.

GitHub and other hosts

Repositories, pull requests (with line-anchored reviews), issues, releases, Actions runs and secrets, branch protection — eight tools over the authenticated GitHub CLI, with destructive actions gated behind confirm=true. GitLab, Azure DevOps and Bitbucket Cloud are served by git_host, which reads the provider and project from the git remote. Before reviewing anything, code_review returns the brief a reviewer starts from: changed files, the signals that matter first, the worst methods of each changed file, and the findings that land in them.

Docker

The container lifecycle: status, inventory (containers, images, networks, volumes), inspect, logs, stats, run and control, compose up/down/logs/restart, and a prune that requires confirm=true because it is irreversible. Structured results instead of docker ps output the agent has to parse again.

Files and the three searches

search_text is grep with structure: regex, glob filter, context, file:line. For configs, logs, headers and arbitrary text.
text_index is a full-text index over the whole solution: words are matched inside identifiers, results are BM25-ranked — for “where is this named or documented?”.
reference_index is the symbol index: declarations and typed usages — call, read, write, inherit, implement, override — plus callers, callees, hierarchy and outline.

Around them: read_files for several known paths in one budgeted call, read_tree for the shape of a folder, move_path and download_file.

HTTP and SignalR

http_invoke calls a REST endpoint of a running app — any method, headers, JSON body — and the signal_r_* family connects to any ASP.NET Core SignalR hub, subscribes to a method, buffers the messages and invokes hub methods. This is how an agent tests a live API or a hub without writing a client: run_project → read the listening URL → http_invoke / signal_r_connect.

Audit and undo

command_log — one row per tool call, with the arguments (credential-looking values redacted).
edit_history — one row per file this server wrote, with the tool, the rules and whether it is still revertible.
revert_edit — restore the file to its state before one recorded edit, refusing if the file changed after it.
local_history — whole-file snapshots independent of commits: capture, walk, diff, restore.

Everything the server does to your solution is a row you can read — and, for writes, a state you can put back.

run_plan: a graph of calls, one round trip