Pular para o conteúdo
← Back to Skalablog

Published article

MCP Server Cuts Mainframe Research to 15 Minutes

Software EngineeringClaude Code

An MCP server cuts mainframe research time from 7 days to 15 minutes by exposing legacy code to AI tooling. Vanguard cash program technical lead Gareth Yoder described the shift on the AI Engineer channel in October 2026, and it is the clearest example of what an MCP server can do for a mainframe engineer.

What did the MCP server change at Vanguard?

The MCP server cut a mainframe research cycle from 7 days to 15 minutes by making the legacy codebase queryable from an AI tool. Gareth Yoder, cash program technical lead at Vanguard, described the change on the AI Engineer channel on October 21, 2026. The server in his talk is a Model Context Protocol endpoint that exposes source and documentation to an assistant in the product's own interface.

What the Vanguard cash ledger does

The cash ledger moves money into and out of Vanguard brokerage accounts and between accounts. Gareth Yoder described the system at Vanguard's cash program on the AI Engineer channel in October 2026. It handles ACH and wire payment rails across web, mobile and batch channels, and the services receive up to 30 million calls a day.

Why the MCP server was the turning point

The MCP server was the turning point because it replaced a week-long handoff with a prompt. Before the server existed, Yoder's team asked mainframe engineers to read the code and report back. That loop ran about seven days for each question. Exposing the codebase to an AI assistant through the server let product owners, technical leads and developers get the same answer directly.

Data, producer and consumer migrations ran in parallel

Vanguard ran the data, producer and consumer migrations at the same time because the modernization was an enterprise priority. Each track had its own approach, and the parallel schedule made the research bottleneck more expensive, which is why the MCP server mattered so much. Here is how the three tracks divided the work.

How the data migration was checked

The migration was validated with change data capture (CDC) and daily audits instead of a big-bang cutover. Yoder's team scanned both the legacy and the modern databases, then verified row-level counts for consistency and individual columns for integrity. Amounts, account information, and state and federal withholding all had to match between the legacy database and the Claude Code.

CheckMethodWhat had to match
ConsistencyRow-level counts across both databasesRow totals per table
IntegrityColumn-by-column comparisonAmounts, account information
WithholdingColumn-by-column comparisonState and federal withholding
Ongoing monitoringChange data capture (CDC) plus daily auditsNot a big-bang cutover

His advice was not to over-engineer the migration code, because it would be deprecated once the modernization finished.

How 35 producers were moved to the new gateway

All 35 producers were migrated onto a single gateway that wrapped the existing APIs and wrote through to the cloud database, replacing three separate ingestion paths. The work concentrated on removing untraceable direct table inserts and making every write safe to retry, so multiple producers could feed one destination without collisions.

The legacy producers reached the system three ways, listed below from most to least observable:

PathHow writes arrivedTraceability
Service requestSubmitted through the service request flowClear owner on each request
API wrapperAPI wrapped around that requestIdentifiable by calling client
Direct table insertsRows written straight to tablesHardest to trace; rows appeared without a clear owner

Direct inserts were the hardest to trace because rows appeared without a clear owner. Yoder's team applied idempotency and consistent writing across multiple writers, using a pattern similar to a Snowflake ID for ordering and uniqueness.

How 50 consumers were onboarded and monitored

Fifty consumers were onboarded through three access paths — real-time, batch and streaming — and each was matched to the mechanism that fit its use case. Real-time consumers called a GraphQL API and subscribed only to the attributes they needed; batch consumers received data-share views from the data warehouse; streaming consumers read a Kafka topic of inserts and updates.

Access pathMechanismExample use
Real-timeGraphQL API, attribute-level subscriptionFunds-available balance on a client's account (highest traffic)
BatchData-share views from the data warehouse, shaped by stated use caseConsumer-specific reporting extracts
StreamingKafka topic of inserts and updatesReal-time ingestion by the fraud team

The attribute-level subscription model kept real-time traffic tied to what each consumer actually rendered, and the highest-traffic example was the funds-available balance shown on a client's account. Batch consumers did not query the warehouse directly; views were shaped by their stated use case. Streaming consumers shared a single topic of inserts and updates, and the fraud team used it for real-time ingestion.

What the five lessons mean for legacy code

The five lessons from the talk are a sequence for making legacy code usable, not a list of slogans. Yoder closed with them at the AI Engineer event in October 2026:

FAQ

  • What is an MCP server? An MCP server is a service that exposes tools, files or data to an AI assistant through the Model Context Protocol. Vanguard used one to expose its legacy codebase and migration documentation to its AI tooling.
  • How much time did Vanguard save with its MCP server? Gareth Yoder reported that a mainframe research question went from about seven days to 15 minutes. He described the change on the AI Engineer channel on October 21, 2026.
  • What does Vanguard's cash ledger handle? The cash ledger moves money into and out of Vanguard brokerage accounts and between accounts. It supports ACH and wire payment rails across web, mobile and batch channels, and the services receive up to 30 million calls a day.
  • Why does idempotency matter in a ledger migration? Retries can duplicate a cash movement, so producers, streaming consumers and batch jobs need idempotent operations. Vanguard carried the producer-side idempotency into its event streaming so a failed batch job could retry without creating duplicate ledgers.
  • What did Vanguard do about the two codebases? Yoder advised fixing forward rather than fixing the past. Bugs that existed for decades were fixed in the modernized state, and allowlisting was needed because that practice throws off audit logs.
  • Why treat migration docs like product? Producers onboard through the documentation, so it carries the same weight as the business functionality during the transition. Vanguard first produced manual documentation, later published it in the company wiki, and then exposed it through the MCP server.
  • How important is observability in this modernization? Observability is non-negotiable, in Yoder's words. Knowing who produces and consumes data matters even more once the system reaches business-as-usual and the modernization teams hand it to daily operations.
  • Where do Crazystack Typescript and Gustavo Dev Doido fit this topic? They come from a separate engineering education community. Gustavo Dev Doido runs Crazystack Typescript as a TypeScript learning track, and the same program is also called the Bootcamp do Dev Doido.
  • Can a smaller team copy Vanguard's approach? The mechanics are transferable: expose the legacy code and documentation through an MCP server, keep the migration docs current, and add observability before onboarding consumers. Vanguard's own results come from one large program, so treat the seven-day-to-15-minute figure as a reported outcome, not a benchmark.

Source video