API Evangelist Conversation with Manu PK on Standing Up an Enterprise MCP Registry and Governing AI Inside a Mission-Critical Company

My name is Manu, and I work at Schneider Electric, which is a global energy and industrial technology company. We’re into electricity from production to distribution to supply — data center infrastructure, buildings, everywhere. We’ve deployed GitHub Copilot to our developers globally; we have around five to six thousand developers in different offices. As the news of MCP emerged, a lot of people started asking us, “we also want to use MCP” — they see the videos, this is really useful, this is going to make us productive. I was also tracking it as part of my own exploration. So we started talking to GitHub about how to approach it. But we were very clear we didn’t want to just allow everything, because there’s a very high possibility of supply chain attacks — MCP sits right in your IDE and can really influence the LLM to inject code that may not be safe. So the starting point was: we need to do this in a secure way.

The need really came from two directions. We were understanding what the technology actually is, and at the same time people were requesting to use it. Contractually we couldn’t use it while it was still in preview — GitHub releases features as preview, keeps them for a few months, and then they go GA, so we had to wait for that. But the bigger driver was security. Because MCP reaches right into the IDE and can influence what the model does, the risk of a supply chain attack is real. That’s the filter that shaped everything: okay, we need to do this in a secure way. In a company like Schneider, where we build a lot of mission-critical systems, it’s important that only approved servers can be connected to Copilot. That was the starting point of the whole thought process.

GitHub Copilot is specifically for our developers; the non-developers and business folks use Microsoft 365 as their primary tool, and they don’t have MCP access at this stage. The registry itself is a community-built, open source application — essentially a list of URLs that says “you allow this, you don’t allow this.” It’s basically a JSON file. The actual package that gets downloaded sits in our internal JFrog, so your package registry can be separate from your MCP registry. Distribution turned out to be fairly easy: once you add a server to the registry, when a developer opens VS Code and types the MCP command in the extensions window, it shows up right there, and they can install it. We did have to write some extra guides for cases where they need to configure tokens, but the discovery side worked well.

As long as a server is on the list, we let teams use whatever they want, or not use it if they have concerns — they have the autonomy. Our work was to create the policy around which ones we’ll allow, because obviously there are hundreds of them, and to scan the packages for vulnerabilities. If it’s a vendor-provided server, it’s much easier. If it’s a community version, we need extra carefulness — you have to look at how much contribution there is behind it and whether you can trust it. So those were the checks we ran before approving anything. It’s really classic governance, just applied to a new artifact: an allow-list, a vetting process, and a vulnerability scan, with the teams keeping the freedom to choose from what’s been cleared.

If you look at the developer workflow, you start with Figma, which we recently enabled, for your user experience. Then you have the Atlassian MCP for Jira and Confluence. Then GitHub MCP, where you can easily talk to your repos for pull request comments. Those are the main ones. We also have a lot of utility servers — Tableau, for example, gives you a lot of BI access. But our first target with the registry was wherever the developer workflow is covered. That’s the through-line: we want to light up the path a developer actually walks every day — design, tickets, source control, data — rather than just enabling MCP servers for their own sake. Cover the lifecycle first, then expand outward into the utilities people ask for.

This is the interesting point about APIs in the middle of all this. If AI is making a lot of calls, we haven’t really seen how that impacts the performance of the underlying APIs. A human using a screen only makes limited calls. But take Jira: people have backlogs with three hundred issues sitting there forever that nobody has opened. Now they ask Copilot, “go look at all three hundred issues, find me the duplicates, find what’s high priority.” Imagine you’re the Jira administrator — that’s a huge number of API calls coming in, because everyone is going to try the same thing. So very soon I think we’ll have to look at this from the other angle: the API administration angle of the actual application on the receiving side, and how that load is going to be treated. That’ll be an interesting thing to watch.

What I realized is there’s a lot of information about personal use — all the videos show you pulling from Jira and doing something, very individual — but there wasn’t much content on the enterprise side. For me it took two to three weeks, maybe a month, to get some of the servers in, because you have a process to add anything. A lot of vendors give you the developer snapshot: “here’s the configuration to put in your VS Code.” They haven’t put much effort into telling the registry administrator what they have to do. That was a new thing we had to figure out. So when we did Playwright — a very simple MCP with no identity to worry about — we thought, let’s write this up, and if somebody finds it useful, let them find it. That was the whole thought process: fill in the gap the vendors left for the people running this at scale.

We had that debate in the developer community — some people saying “MCP is dead, use CLI,” all of that. I used to be a top one-percent Stack Overflow contributor back around 2013, 2014, as a Java developer. One of their founding ideas was that you don’t debate whether Java is better or .NET is better — you state the problem, you give a solution. So what I tell people is there are multiple ways of doing things; just find what’s useful for you and use it. Personally I’m not a command-line person, I like IDEs a lot more, so I find MCP in the IDE gives me much more control. Schneider’s policy is that if you’re committing code, you need to understand it — at least read it once — and an IDE is a much better place for that. So we enable everything, including CLI, but it’s up to people to use whatever works for them.

I’ve been a developer and architect, did about five years of engineering management, and came back to the solution architect role last year — right as AI was taking off. Like everyone, I’m blown away; there was a moment around December–January where I thought, this is real, this isn’t a sci-fi movie. But I worry about the gradual decay of skills and cognitive abilities — I used to debug JVM memory issues ten years back; would anybody do that ten years from now? I doubt it. At a company like Schneider, the human in the loop becomes even more important. We build the brains that go into a machine that ships to an OEM and ends up in some oil plant in a desert — so the software has to be treated like hardware. As you move down the stack toward firmware, there are a lot more concerns, and being able to quickly evaluate AI results is going to be a critical new skill.