Build1 publisher2 min readPublished
Morgan Stanley pairs MCP with the architecture-as-code path that shipped 110 APIs
Jim Gough says the protocol part of MCP does little beyond client-server exchange, so the year of work at Morgan Stanley went into an architecture-as-code path that has put more than 110 APIs into production.
The Engineer · Build desk
What happened
- Jim Gough, the architect of Morgan Stanley's API program, told QCon the firm has spent the past year rethinking that program around two things paired together: MCP and CALM.
- A little under a year earlier he had presented the plan to deploy every service and piece of infrastructure at the firm using Architecture as Code, with nothing built at that point.
- Gough said the firm has since put over 110 APIs into production that way, with continuous deployments across a combination of architecture, platform and security.
- The session also covers CALM's core concepts, governance and controls including the team's work on gates, and how the platforms are scaled.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint If the protocol adds little above ordinary client-server exchange, then bolting MCP onto an API estate does not shorten the job. What limits an agent-facing program is the path that generates, deploys and approves the server.
- cost Copying this means paying for the architecture-as-code layer first. A year of platform engineering and a named owner for self-service tooling sit underneath the 110-API count, and no SDK supplies either one.
- capability Running A2A through the same pipeline shows that a deployment path built for one protocol can carry the next one without a second program.
- precedent Business stakeholders who ignored interface specifications for a decade are now asking about MCP specs. Spec quality is suddenly in front of people outside the platform team.
Gough described MCP as an open protocol for connecting LLM-based applications to tools and data, running a cycle of discovering what is available, invoking it, and validating in the background [5]. He was blunt about the protocol layer. "It doesn't do very much above that end-to-end piece of communication that we're really used to and that we've seen in many different patterns and protocols in the past," he said [6]. He also said security and governance in the protocol are "now tending towards first class" [12].
That leaves the work behind the tool listing: the service, the path that deploys it, and whatever decides it may ship. Averaged across 52 weeks, 110 production deployments is a little over two a week [7].
For that rate to mean anything in another shop, the services have to be uniform enough that one architecture description generates deployment for all of them. The security review has to run inside that same automated path. And someone has to own the self-service tooling as their job: at Morgan Stanley, Niculcea leads the team's self-service capabilities and has worked on the program for five years [2]. In her introduction she said she is the one who does the work [13].
The published transcript excerpt stops during the MCP introduction, so it does not spell out what a CALM document contains, what the gates check, or how an API is counted for the 110 figure [14].
Gough, co-author of "Mastering API Architecture" and the architect of the firm's API program [1], put the difference in attention this way: "I've not seen anybody get really excited about an OpenAPI spec in the business. There are lots of people jumping up and down about MCP specs and what that means" [8]. I think the description work is much the same in both cases. The difference is who now asks to read it.
The preview demo in the session runs A2A in the background [11]. Gough described the direction as moving from a traditional API program to supporting MCP, and then to future protocols [11].
What to watch
- Whether the full session transcript defines what a CALM document contains and what the deployment gates actually check.
- Whether the 110-API count is ever broken out into MCP servers against conventional REST services.
- Whether A2A gets past the demo and ships to production through the same pipeline.