Cloudsmith CEO Glenn Weinstein on How MCP Servers Are Transforming AI-Driven DevOps

Hey guys. Thanks for the throw. We're here with Glenn Weinstein.

He's the CEO for Cloud Smith, and we're talking about model context protocol, MCP servers. They're everywhere, but no one's quite sure what they mean just yet. Glenn, welcome to the show.

Thank you, Mike. It's great to be here. All right.

You guys have been working in the space of DevOps observability and, and everything related to application development for some time now. And you too are also seeing MCP servers, and I believe you have one of your own, but what are the implications for all of this? Is it just for AI purposes or is there something else going on here?

Yeah, well, AI is a means to an end here, Mike. I would say it's the tooling, but what this is really about is recognizing that people develop software very differently today than they did even a few years ago. Um, cloud Smith is in a position to help software development teams to develop faster and more secure Morely.

And I think tools like Cloud Smith and really honestly a whole bunch of other tools need to expose ourselves to the AI agents of the present and the AI agents of the future. MCP is just a way of making sure that we do that, um, correctly and efficiently. It seems like a lot of these AI agents that we're seeing, and even the copilots before, are lacking context.

And as a result, what happens is they seem to generate some code, but it doesn't happen to run in the environment intended because each environment is well as Snowflake. So, uh, we will, tools like yours surface up the data through an MCP server that the AI agent needs to get that missing context. E exactly.

That's, that's definitely one sense of the C in MCP, the con the contextual, uh, background of, uh, the development environment that a particular developer is working in. We're not talking about AI is like the, like, uh, Google Gemini running on the Google search box answering generic questions. We're talking about developers saying, how many Cloud Smith repositories do I have?

Is this Docker container image in one of my Cloud Smith repos? Has it been scanned for vulnerabilities? Questions like that require a lot of context.

What, what do you mean by Cloud Smith repo? I wanted to see my repos, not someone else's repos and that sort of thing. So an MCP server allows us to provide the context so that the AI can come up with a relevant and meaningful answer.

Does this also mean that maybe I don't have to be as much as a rocket scientist as I used to be able to use these tools? I mean, this theoretically, I should be able to use natural language to ask the agent to go answer many of those questions, right? You Know, that's one use case for, uh, something like the Cloud Smith MCP server, which is just to straight up use your AI LLM, your Claude or, or, or a chat GPT Pro and just ask questions about your Cloud Smith environment.

Maybe give natural language direction, go create a repository, go migrate this, this package, things like that. But I think that the longer term power is gonna be more than just answering questions. It's really agentic and it's this idea that developers and you, we already see it on our own team, um, are increasingly relying on agents to perform multi-step processes.

And one of those steps may be to pull or push a package to Cloud Smith. And we want clouds Smith to work well in the context of an agent talking to another agent, talking to an MCP server from another vendor, and the humans don't get involved in the, in the intermediary steps. This ensures that degree of integration too.

So as a developer, yeah, you can ask natural language questions, but it kind of goes beyond that. Like you can perform entire tasks that you would normally have done step by step and just let your AI agent do it for you. Hmm.

Will there be multiple AI agents that need to talk to each other? And, you know, we hear a lot now about something called the agent to agent protocol, but, um, is that complimentary to all this? Well, we need both.

'cause it seems like one's for talking to agents, the other one's for agents talking to data, Highly complimentary. You need both. Um, you need MCP first.

That's really, in my view, the more urgent, uh, requirement here. But a to a is a great evolution. Google just donated the entire project to the Linux Foundation, a definite step in the right direction to open source this.

Um, what we can do today is we can help individual developers that are working in copilot or working with whatever developer tools are working to make sure that Cloud Smith plays well in that environment. Um, where it really will become relevant to companies like Cloud Smith in the future is when we develop our own agents. So you see this a little bit like, uh, you know, our, our, um, uh, you see this in sales tools and things like that where the company will brand an agent with their own name.

Our, our internal leading candidate for a name would be Smithy, uh, an agent that answer those questions about your Cloud Smith environment. That's, that's temporary. And I, I don't run, uh, luckily we have a, a chief marketing officer here, but, but, so we don't have that today.

But, but if and when we think it makes sense to have our own native agent, that agent is gonna want and need to talk to other vendors' agents to properly answer questions and provide a meaningfully contextual answer. So that's where eight A really is gonna come into play, where every vendor has their own agents, and I just need my agent to kind of talk to your agent to steal a Hollywood phrase. Do you think we'll also get to the point where I feel like observability, it's been a core tenet of DevOps for such a long time, and yet for the most part, we're all still stuck on monitoring predefined metrics and we're just kind of getting our heads around observability.

I wonder though, in the age of AI with AI agency becomes essential because when I talk to folks, they're like, well, it's great that the AI did this thing, but I don't really understand how it did it and now I'm being asked to debug it. Yeah, yeah. I mean, uh, so AI tools are, they're getting so sophisticated so quickly and it's, it's great when you see AI tools give you the full explanation and references of how they can, how they drew their conclusions.

But to, to think about observability specifically, I think I think MCP servers and, and LLMs in part in in general are an amazing observability tool. Your pro your products has to create the data in the first place. We have, you have to have rich client logs.

You have to have an API that can access them. But the, the last mile and all that is getting all that data into a human's brain and answering the question that they meant to answer. That's where people tend to get lost.

It's sort of like assuming, um, that, um, normal mere mortals can write their own SQL queries. It, it's not the way the world works. You need tools that kind of help you with that.

And I think that, uh, using an LLM to say, this is really what I want now, go to my data sources, go to my APIs and get me what I want, there'll always be a role for whether it's a human or an AI to assist in those kinds of queries. And so it doesn't replace APIs or having really rich data, it just makes them accessible to mere mortals. How long will it be before all this comes to fruition?

I feel like we talk about it like it's all here tomorrow, but it will take some time for all of this to come together in a way that's consumable. So where are we on the journey, Um, in general, AI assisted tools? I mean, they're already here for software developers and, uh, if your, if your team isn't experimenting with and using them to be more productive, you're, you're falling way behind.

What, what's not quite here yet is this use case that you and I are talking about right now, which is really cool idea, and I think, we'll, it will come soon, which is, uh, the one I led off the interview with. Like, Hey, cloud Smith, tell me about my repositories. Tell me if this package is in there.

Um, I do think we're gonna see that in, in, and I think it's gonna be in months, not years, that customers are gonna start relying on our MCP servers capabilities to integrate with their AI agents to answer questions like that. I just think the generation of developers that's coming up now, getting hired, moving into jobs, they just assume AI agents are going to be their companions. And, uh, that those, these generational turnovers, at least in my experience in the tech industry, they happen quicker than you think.

Um, it's, it's, it's not long. It's months, not years. Well, we need to rework our DevOps pipelines and workflows for all this.

'cause it seems to me that the AI will be building code orders of magnitude faster than, than we have in the past. And we kind of were, you know, basically happy if we released, you know, once a day and probably once a week something went wrong. But in the age of ai, won't the volume increase to the point now where maybe I gotta revisit how all those pipelines are actually constructed.

That trend has been underway for a while now. The idea of doing more and more builds every day. We work with customers that do hundreds of builds a day and really don't think twice about it.

Um, so I think this will be a continuation of that trend, which is a distinct trend. I mean, I remember more than a decade ago, it was the world that you've described. You know, you do, you maybe we'll do a build next Friday.

Um, but so we'll see and we'll see a continuation of the trend of more and more frequent builds, larger builds, um, listen and not to be too self-promotional about it, but that's gonna put pressure on the artifact management systems. And that's why your artifact management has to serve up packages super fast. Well cashed globally.

Everything needs to be as efficient as possible. We're all getting hooked on the drug of AI doing things quicker than we could do them ourselves. We, uh, the amount of logic and, and uh, kind of smarts that go into ag agentic ai, uh, tasks is just really awe inspiring.

And you don't wanna get to the end of that and then have your bill take 15 minutes. That's, that's just not gonna work in the AI in the AI era. Um, so yeah, it's, um, it, it's gonna change the expectations rather.

I do wanna answer the other part of your question though, definitively, which is I don't think the fundamentals of software development are changing. You still need to know, uh, business requirements. You still need to translate them to technology.

You need to do a build, you need to d deploy to production. Those fundamental pieces aren't changing. The assist is what's changing.

It's like working with a whole team of junior to mid red level developers that are just helping you be faster. Does that artifact repository you described become more crucial? Because in my mind we kind of never really leveraged it to its full potential.

In theory, we should have been checking it for all the vulnerabilities that are in there and now AI components, while, you know, they'll probably be created by things that might be hallucinating and there could be packages that don't even exist and all kinds of weird things happening. Does the artifact repository become the place where we can kinda, uh, bring some a layer of order to what might be potentially chaotic? Absolutely.

And you're right, we have not fulfilled the full potential here. So the legacy players in this space are jfr Artifactory and so type nexus, they were built in kind of a pre, uh, pre open source pre vulnerabilities era. They really were built, uh, from an on-premise mindset to just say, just get the packages where they need to go.

'cause we kind of can't rely on the internet. They never really made the transition into true, um, secure the software supply chain solutions. And you now see an explosion in that ecosystem.

And relatively few of those customers use the artifact management platform for security, which is a huge opportunity. 'cause you should, um, what better place to have a data plane and a control plane for what's going into your software and what you're building than at the artifact management layer? So, uh, so the phenomenon you've described is real, uh, to absolutely real, where the, your copilot, uh, agent will su suggest either packages that are outta date or they're not well maintained or that kind of nobody's using and they're falling outta fa favor or fashion, but you know, somehow they picked up a little tidbit about it and they'll suggest the wrong package.

Or just hallucinate a fake package, which is then opens up this whole, um, lop squatting opportunity. Bad actors create that package and now it's a real package and a malicious one. So all of that pressure is gonna be put on software development teams to secure their bills when agents are making 90% of the decisions.

So we better get some protections in place. Hmm. So what's your best advice to folks right now as they kind of look at all of this?

'cause I think everybody's excited about the coding side of the equation, but they may not have gotten through the, um, downstream impact and effects just yet, but what should they be thinking about now that they can see that? Well, as far as I can tell just about every developer's using some sort of AI coding tool, it's just a question of what degree. Yeah, That's probably the entry criteria here are use and experiment with, um, AI tools.

Our most cynical senior developers who poo-pooed the idea of AI assisted development a year ago are, are now sold. There's, there's not a lot of cynics or skeptics left. So, so get on board, uh, with, uh, with what they can really do, like try it out for yourself and, and just figure out what they can really do.

And then I think, um, uh, the call to action here is start to think about the full tooling ecosystem. It's not just about GitHub. Uh, it's not just about your IDE, it's about all of the tools that you work with.

Raise your expectations for how they should be participating in agent workflows. Um, I think, um, within, you know, a couple years tools that have not kept up, uh, don't really have a true API first, uh, architecture and haven't fully implemented an a, a secure MCP server in eight a are just, they're not gonna play anymore in the future ecosystem. All right, folks, you heard here it might be time to take a minute and figure out what the cause and effect here is gonna be, because we are definitely gonna have a lot more code than ever.

It's just a question of how much of that code is gonna show up in a production environment, how fast and how good this quality gonna be. Hey, Glenn, thanks for being on the show. Absolutely pleasure, Mike.

Thank you for having me. All right. And back to you guys in the studio.