Teaching a 1999 VB6 app to talk to AI agents

SQL Server Comparison Tool (SCT) has been around since 1999. It compares SQL Server schemas and data, and it is still written in Visual Basic 6. It has always been a classic Windows program: you open it, click through some dialogs, and read a report.

This year I wanted to know whether an AI assistant could drive it. Not a chatbot that pretends to know your database, but Claude actually running a comparison and explaining the result. The answer turned out to be yes, and the result shipped in SCT version 6.0. Getting there meant solving a few problems that I suspect anyone with an old desktop app will run into, so here are my notes.

The end result: Claude Desktop runs a saved SCT comparison and explains it (waiting time sped up). Watch on YouTube →

AI assistants connect to local tools through the Model Context Protocol (MCP): JSON-RPC messages over a program's standard input and output. Teaching a VB6 program to do that directly would have been painful. Instead I split the work in two:

That kept the 27-year-old comparison engine almost untouched. Everything new lives at the edges.

A desktop program assumes someone is sitting in front of it. Every MsgBox is a question for that person. Run the same program in the background for an AI and each of those message boxes becomes a hang: the process waits forever for a click that never comes.

So the first job was a headless mode that always terminates:

The interactive program behaves exactly as before. The headless path just routes the same events somewhere a machine can read them.

SCT already produced text reports, and the tempting shortcut was to hand those to the AI. I decided against it. A report written for people mixes layout with facts, and an AI reading it has to guess where one ends and the other begins. Structured data is unambiguous.

Every run now produces a JSON document with a versioned envelope:

{ "schema_version": 1, "sct_version": "6.0.205", "comparison_id": 1, "comparison_name": "Sync check - Northwind vs Southwind", "started_utc": "2026-10-10T23:08:30Z", "finished_utc": "2026-10-10T23:09:57Z", "status": "success", "errors": [], "warnings": [], "results": { ... } }

A few decisions that paid off:

One more point on VB6: it has no built-in JSON writer, so the output is assembled by hand. The detail that matters is escaping. Database object names can contain quotes, brackets and backslashes, and one unescaped character produces a file no parser will accept.

The bridge, SctMcpServer.exe, is a .NET Framework 4.8 console program. I chose Framework 4.8 rather than modern .NET because it is preinstalled on every Windows 10 and 11 machine: nothing extra for customers to install. It has no third-party packages at all. For a local server with two tools, the protocol surface is small: answer the initialization handshake, list the tools, and handle tool calls.

Claude Desktop -> SctMcpServer.exe -> sct.exe (headless) -> SQL Server JSON-RPC over stdio writes JSON result

Once the first build worked, Claude could list my saved comparisons from a chat window. Then the comparisons themselves started failing.

From a command prompt, everything worked. Started by Claude Desktop, every comparison failed with:

ADO error 3706: Provider cannot be found. It may not be properly installed.

The provider was certainly installed; the same machine ran the same comparison seconds earlier. The difference turned out to be the environment. Claude Desktop starts MCP servers with a stripped-down set of environment variables: about 17, compared with about 60 in a normal interactive session.

One of the missing variables was %CommonProgramFiles%. The OLE DB provider SCT uses (SQLOLEDB) is registered with a path that relies on it. Without the variable, COM could not resolve where the provider lives, and ADO reported that it didn't exist.

The fix is a small block at the start of the MCP server that restores the standard Windows variables before it starts sct.exe. A simplified sketch of the idea:

// Simplified: restore standard Windows variables that the // host process may not have passed on, before starting sct.exe var psi = new ProcessStartInfo(sctExePath, args) { UseShellExecute = false }; SetIfMissing(psi, "CommonProgramFiles", Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles)); SetIfMissing(psi, "ProgramFiles", Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)); SetIfMissing(psi, "SystemRoot", Environment.GetFolderPath(Environment.SpecialFolder.Windows)); // ...and the other standard ones

static void SetIfMissing(ProcessStartInfo psi, string name, string value) { if (string.IsNullOrEmpty(psi.EnvironmentVariables[name])) psi.EnvironmentVariables[name] = value; }

The general lesson for anyone writing a local MCP server on Windows, especially one that touches COM, ADO or anything registry-driven: don't assume your process inherits a normal environment. Log the environment you actually received the first time something works in a terminal and fails under the AI host. It would have saved me a lot of guessing.

The part I spent the most time on wasn't code. An AI agent connected to production databases should make any DBA nervous, and it made me nervous too. So the design starts from what the AI must not be able to do, even if it misreads a request or is manipulated by text it reads somewhere:

These limits also made the integration easier to explain to customers. "It can only do these two things" is a much shorter conversation than a list of safeguards around a powerful tool.

The rest was ordinary release work: a code-signed build, log rotation so diagnostic logs can't grow forever, a configurable timeout for very large databases, and a setup guide. For users, connecting Claude Desktop comes down to one entry in its configuration file:

{ "mcpServers": { "SQL Server Comparison Tool": { "command": "C:\Program Files (x86)\SQL Server Comparison Tool\SctMcpServer.exe" } } }

If you maintain an old desktop app

Leave the core alone. Put a thin, modern layer in front of it instead of rewriting it.

Headless means it always exits. Find every place the program waits for a person, and turn it into an error.

Give the AI facts, not reports. Structured, versioned output is easier for a model to explain correctly.

Test under the real host. A server that works in a terminal may still fail when an AI app starts it.

Start with what the AI can't do. A small, safe surface is easier to build, to trust and to sell.

SCT is a VB6 program that predates most of the tools now talking to it, and it didn't need a rewrite to join them. That may be the most encouraging part of the whole project.

Try the AI Agent Integration on your own databases.