MCP Explained: The AI Agent Protocol Reshaping Identity and Security

Mark Callahan:

Hey everyone. My name is Mark Callahan. I’m on the product marketing team here at Strata, and I’m joined by Granville Schmidt, who’s our chief architect here at Strata. Hey, Granville.

Granville Schmidt:

Hey, Mark, thanks for having me.

Mark Callahan:

Alright, so you and I are here today because we are wanting to talk with the members of our Agentic Identity Private Preview a little bit about something that I think a lot of us take for granted. Like, we all know what it is, but we haven’t given it as much thought. And I’m going to say three letters and you could probably guess what those are. But, Granville, what do you think I’m thinking here as we talk about those?

Granville Schmidt:

Would it be Model Context Protocol (MCP)?

Mark Callahan:

I said letters, not names, but yes, it’s exactly that. You got it. MCP, MCP. So that’s it. You know, it’s one of these things that everyone’s talking about as we think about AI and agentic workflows. And we just aren’t maybe as familiar with what it is. And so maybe setting a little bit of a foundation for our audience so that everyone knows, where we are with this and why we’re talking about it and where it came from and maybe like what problems to solve. So yes, those three letters, Granville, tell me a little bit about like what MCP is and kind of where it came from.

Granville Schmidt:

Yeah. So MCP is this really cool new protocol. It was founded by the team at Anthropic, you know, the creators of Claude and yeah, they’re like Sonnet models and their Opus models. But it started internally by this, by these two people that were like, they’re working on internal developer tooling and like the needing to be able to call different types of systems from models. Internally, when they were working on it, they found like they had to like build out these kludgy different types of like setups to be able to call like certain types of APIs. And they realized that there had to be a better way. And so they created this protocol MCP, which stands for model context protocol. But it was initially started so that developers are able to call these external APIs to get additional context for these AI systems. So imagine you’re chatting with an agent and you’re like, hey, can you go pull this historical fact? Before MCP, it was like, what was the agentic model trained on? So it was maybe the last training run where like they pulled this corpus of information was months ago. It wouldn’t have the latest facts from the news. Exactly. Exactly. And so they’re like, how do we pull more up-to-date information without having to rerun this training model? Because those training model runs are super expensive. And no matter when you run them, they’re always going to be out of date.

Mark Callahan:

Right, it’ll be dated. It was at that point in time, right? Sure.

Granville Schmidt:

And so they created this protocol that allows it to call these external systems. And one of them could be like, hey, go pull the newsfeed, right? Or go pull some data from a database for me.

Mark Callahan:

Okay, so it’s not just like an agentic thing. It’s not just like the autonomous worker agent going out to do something on your behalf. It’s actually, was a training element for communication early on, just how the models are becoming smarter themselves. Is that statement or am I off? Like, I always struggle a little bit where it, you know, where it fit as well.

Granville Schmidt:

Sort of. Yeah, no, it’s a little off. It was really meant like, once these models have been trained and they’re being used in like a tool like chat GPT or cloud desktop, then it was then once that model has been deployed in this like agent, these like chat, GPT or cloud desktop are in your hands, then how do we provide additional context to those models instead of like you Mark, you’re like, hey, I need to summarize this latest events in the news. And you previously, you would have like gone out to the new site, you would have copied and pasted it, put it in there and now said summarize. But now those agents can go out and pull that data and provide that data to the models to be able to do your inquiry.

Mark Callahan:

Gotcha.

Mark Callahan:

And I was a little remiss in the way I was describing it there. that’s, I follow now and where it fits. you know, so what does that mean for like, you know, the traditional security perimeter? And we think about like identity on a whole, like, I guess, where does the MCP fit into all this? Do we think of it as another identity protocol or what is it?

Granville Schmidt:

The context was, you know, it was built to like provide these tools, but it was built for local tools. And what I mean by that is imagine that like, you wanted to provide the model, the ability to read your local files on your laptop, right? Or like, you know, from a, like if you’re writing software, it’s like, I want to be able to read your software that you’re writing. And ask the AI to help augment it or improve the software that you’re writing locally. But people saw this and was like, wow, that’s a really cool protocol that solves this need locally. How can we actually take this and now make it available for more of these network use cases? And so the reason why I’m bringing this up is that it started off as this local thing, but then it switched to this networking aspect. Then once you start adding a networking characteristics to it, now you have to start asking, how do you secure it?

Mark Callahan:

This makes a lot of sense. And as we think about this, kind of in the way I kind of mis-framed it before, was the, where we think about MCP now is like these public agents coming into potentially your APIs, like within your organization and having access to those APIs themselves. it’s, I wouldn’t say crossing domains, cause I know that’s not quite what I mean, but it’s crossing environments is what we’ve got going on here. And that’s where MCP is picking up additional applicability.

Granville Schmidt:

Exactly, exactly. So like, let’s just role play a little bit. So imagine that you are the CTO for a fortune 500 company and you’re tasked with like, Hey, how do we take our current systems and make them accessible to this new world of AI? And AI today those agents and models. They don’t talk to API APIs.

Mark Callahan:

Okay.

Granville Schmidt:

How typical systems that you developed in-house would talk to APIs. the current APIs that you have out there for developer use cases can’t be talked to directly via these models. So that’s where this MCP protocol comes in. It’s like the API protocol for agents to talk to APIs. so when now it’s like, okay, I have these internal APIs, right? So… Let’s just say for instance, like maybe you’re the CTO for a brokerage company, there’s some sort of APIs internally for like, you know, transferring funds. and those APIs typically have, you know, a sender, receiver, some amount in there. And now you want to make it so that these agents like your, maybe some brokers can be like, Hey, agent, I need you to be able to transfer XYZ funds over to, Mark. And it’s, but to do that, you need to be able to expose those APIs via MCP. So now what you need is you have to have some ability to translate MCP to those APIs, right?

Mark Callahan:

Mm-hmm.

Mark Callahan:

So that they actually are speaking this. And I feel like there’s an element here also of, is it just the communication? But is there also like, how do we make sure that like we’re doing the right thing? Is there a human in the loop element here?

Granville Schmidt:

Exactly, yeah, so it’s, it’s a yeah, no, no, no.

Mark Callahan:

And I know I’m going a little ahead of myself because I know the script. yeah, our audience is probably like, wait a minute, where is he going? But yeah, I mean, so the API, you know, started going back to where you were. So if I want to execute that trade and I have, Mark Callahan, stockbroker, and I’m like, Mark 2.0, I want to go execute some trades in mass. And I’m going to have Mark 2.0, the agent, start going out to do that. And it would act and interact, I should say, with those APIs to process those trades. but they’re not an actual stockbroker.

Granville Schmidt:

Yes. And so one thing to clarify real fast is let’s just imagine, let’s put the agents aside. Imagine that I wanted to send that money and I want to use that API. Maybe I’ll go through some sort of authentication and authorization flow through that API. But at that point in time, when I make that API call, you can attribute that call to me. It’s me. It’s me that made it.

Mark Callahan:

Mm-hmm.

Mark Callahan:

It’s you. Yes, exactly. It’s you. Flesh and blood. Yes, you.

Granville Schmidt:

Right. Exactly. But now when we start talking about, Hey, what if I went to another human being now, right? Like, what if I went to Bob and like, Hey, Bob, I want you to go transfer these funds. So if Bob makes that call now, you know, in the typical API use case here, now Bob’s name is tied to that. But what we’re missing here is I’m asking Bob to do this on my behalf. Right. And so this is where we start talking about like this concept of like delegated authorization, right? Like I’m delegating some task to Bob and Bob is then executing it on my behalf, right? So you take that example and now we apply to agents, And so if I want to do the same thing, maybe I have, we’ll just call the agent. it Granville 2.0 for lack of a better name.

Mark Callahan:

Okay.

Mark Callahan:

Grandel 2.0, yes, that’s our agent, okay.

Granville Schmidt:

Gremble 2.0, and it’s our agent. And I’m like, hey, Gremble 2.0, I need you to transfer these funds. So same concept, right? Like I’m asking Gremble 2.0 to do this. Gremble 2.0 will make the request on my behalf. And we need to be able to prove that chain, like end to end, right? So in API design, you can still do that today, right? Like this is completely orthogonal AI systems, right? And completely orthogonal of MCP.

Mark Callahan:

Okay.

Granville Schmidt:

A common authorization protocol you can use is like OAuth. And in OAuth, are RFCs that talk about delegated authorization and where you can do things like impersonation or delegating tasks to someone else. So that already exists. But when it comes to agents and talking to these APIs, beforehand, very rare that you see that in the wild.

Mark Callahan:

Okay.

Granville Schmidt:

Right? Like, because typically when a system is making a request, it’s doing it because of some other authorized events. And you didn’t need that sort of like audit ability of those requests. But in this new world, you now need to have it. So in MCP, now that we’re taking current like API design, and we need to expose it via this brand new protocol, which is specifically designed for agents to communicate to these eight, like these upstream systems.

Mark Callahan:

Follow.

Mark Callahan:

Thank you.

Granville Schmidt:

Now it’s no longer like this optional, like standard in the world. It’s now like required. Right. And because right now agents are typically doing it on behalf of someone else. Right. So let me pause real fast. like, what are your thoughts on that?

Mark Callahan:

So I’m following there. where does the MCP come into play as the agent uses it? Does the agent, like on the agentic platform, like Claude or wherever you’ve built the agent, is that where the MCP is coming from? Or is there like an intermediary? I’m obviously alluding to MCP servers. Like how does that architecture come to play?

Granville Schmidt:

Yeah, yeah, it’s a really good question. so MCP fits on parts. So imagine that you take your current internal APIs at your organization and instead of exposing them the same way that you do today, you could expose them via the MCP protocol. So what used to be like rest endpoints, for example, where it’s like, I have a trade endpoint, I have a…

Mark Callahan:

Mm-hmm

Granville Schmidt:

a endpoint for moving money, right? But now in MCP, there’s three aspects of the MCP protocol. Essentially, there’s this concept of tools, resources and prompts. so tools is really like, I need some action to be done, right? So maybe it’s the trade, right? Maybe you have a tool that’s specifically built to be able to trade different things. And you might have a tool for transferring funds.

Mark Callahan:

Yes.

Mark Callahan:

Okay, what are these?

Granville Schmidt:

So these are very similar to like the current endpoints and APIs. But instead of it being like just stuck with like one particular action, a tool can do a lot of different things, right? The creator of the tool can choose like what’s what sort of workflow should happen when it receives a request for that tool. But it can be as simple as, transfer funds and things like that. Or it could be something far more advanced, like go book me a vacation. Right.

Mark Callahan:

Okay.

Granville Schmidt:

And then there’s this idea of resources. Think about resources as like files for lack of like better word here. It’s like, how do I expose certain data sets to agents? Right? So maybe it’s like, I want to expose a local file to an agent or some particular configuration of something. You can do that via resources. It’s really like static based on what you’re requesting. can, the, content of the document can change. But reality is like, I just need this thing and then I’m going to operate on it. And then prompts are this idea of like, how can I help the AI or the agent be able to help the end user be able to ask the right questions, right? So for instance, maybe if we have an MCP server or your API, right? To be able to the end user that’s talking to an agent make the most use of your

Mark Callahan:

Okay. Okay. No, I get get all that. Now,

Granville Schmidt:

your APIs, could be like, I need to be able to transfer money from point A to point B. And so you can provide these example prompts via MCP down. That way it helps like kickstart the end user when they’re making requests.

Mark Callahan:

where you just let’s keep going with the theme of money and the trading example here. It does seem like there’s obviously opportunity for a lot of security risks that might be unique to MCP as well. Like what are some things to consider there?

Granville Schmidt:

because MCP is so new, like we talked about at the beginning, it started off as this local only protocol. Then over the last several months, we’ve added different sorts of networking protocols to it. So it’s all started as local, then it went into HTTP. If we’re getting nerdy, we’re talking about what’s known as server-sent events. And then recently, it switched over to recommending what’s known as HTTP streaming. And even very, very recently, as of like days ago, there’s a proposal out there for doing WebSockets. So the industry is moving really fast on the transport side of this. But at the end of the day, this MCP protocol is like an RPC protocol, meaning like it’s just request response type thing. But for those three, I don’t know what to really call them, but that’s the tools, the resources and props.

Mark Callahan:

And I want to say resources because yes, because that’s the wrong word. But yes, there’s three categories of items that they have. So with all the changes that we’re seeing, as you said, just even three days ago, there’s a new proposal out. And I know that hearing some of our team talk about it, even three or four weeks ago, they changed it to the point where they decide to externalize security concerns outside of MCP itself. But it’s changing all the time. Our organizations, you know, that as they have their APIs, so I think just keep regretting their APIs to a new flavor or what’s the world there?

Granville Schmidt:

really good question. But before I get there, I want to like, really discuss like your prior question. So like you have these changes in networks, right? These different transports, but then it’s like, how do you secure those APIs? And, the industry landed on for now using a lot as that form of authorization, right? So there’s a few RFCs that are being used in there, but essentially what happens is, is that an MCP server will expose what’s known as this protected metadata endpoint, and it’s going to list out all of their authorization servers. And an MCP client, let’s just say like an agent like Cloud Desktop or ChatGPT, when it calls out to that MCP server to go call a tool or whatnot, it’s going to say, hey, you’re not authorized right now. You need to go and look at my endpoint over here. it’s going to go look at that endpoint and it’s going to be like, I need to go authorize with this upstream IDP. then what will happen is it will go to that upstream IDP. It will then either go through what’s known as dynamic client registration, where it’s like registering itself on that IDP. And then depending on policies on that IDP, it might actually have an end user go through some sort of like authentication authorization process. to grant access to that MCP server based on some level of scopes. And that’s a high level. And so OAuth is really being used the authorization flow for it. And then on the MCP server side, it enforces the access via what’s known as bearer tokens. And these bearer tokens are typically used as JOTs. So a JOT is just like a token that has a bunch of metadata about the actor and the subject in this case. So, you the actor is the agent, the subject is the end user that is making the initial request. if it’s… Exactly, exactly. And so it contains that information. So at this point in time in the flow, we’ve authenticated to an upstream IDP.

Mark Callahan:

Granville and Granville 2.0.

Granville Schmidt:

and we’ve authorized this particular request to that API endpoint. But what we haven’t done yet, think about this as like, does this person have a badge at the company? Are they an employee? That’s about all that does right We haven’t talked about should Granville will be able to call this endpoint or…

Mark Callahan:

Right.

Granville Schmidt:

What is, like, if Granville is calling an endpoint about transferring funds, maybe there’s some upper threshold at which he, like, isn’t allowed to transfer funds without management approval.

Mark Callahan:

And there’s also perhaps a little bit of Sarbanes-Oxley, like the separation of duties that come into this also so that Granville 2.0 can’t play both sides of the thing. But all these things make a lot of sense. mean, you’re talking about the OAuth angle here. I think you’re talking about a lot of things that people in identity are very familiar with as they think about this. So some of these things have been solved for, if there’s a path for these right now, what are the challenges that haven’t been solved for as we’re thinking through this?

Granville Schmidt:

Yeah. So, target enterprises that have hybrid workloads, right? They have them running in the cloud. They have them running on premises. We have them running in super secret areas, right? Where they may not have cloud access. The standards today that are being used in MCP super flexible to some point, right?

Mark Callahan:

Mm-hmm.

Granville Schmidt:

But a lot of the players in the market now, what they’re doing is they still require cloud connectivity at some level. the problem here is for these Fortune 5,000 companies or even the federal businesses or some startups where they have to deploy things on premises and certain types of data only exist there. There is no means and the protocols to be able to get that information and allow that information to be used to make fine grain authorization decisions.

Mark Callahan:

If you can’t reach out to the cloud, it has to be done within the perimeter is what we’re saying. Okay.

Granville Schmidt:

Exactly, exactly. So, the protocols are great, but, you they are only one piece of the puzzle when it comes to like full enterprise adoption. Now the next piece is assume that you’re able to get all the data you need to make a rough coarse grained policy decision. You know, that is really good, right? Like it’s a really good start. But like we an example we talked about a minute ago was what happens if like I ask an agent to go transfer some money, right? Maybe it’s a few hundred dollars. Cool. It gets approved and it goes through. But what happens if later on I make a request to transfer $5 billion, right? $5 billion. Nice. you know, maybe at that point in time, you know, instead of a denied decision that’s being made, maybe you need to go get some other approval, So maybe you have to be able to ping some other system upstream to get management approval, right? It’s like, cool, okay. But the protocol doesn’t have the concept of that, right? So you’re leaving, this system that makes the MCP protocol or exposes that, if you will, to the agent has to build all of that logic in. in this particular case, we have to go do management approval. And that’s a lot to ask of anyone that’s building APIs. Now, let’s talk about something even crazier. Maybe I’ve asked it to transfer some money, but maybe it was delusional. And when I put in $5,000, I thought, oh, $5 billion for whatever reason. Now, what could happen there is like,

Mark Callahan:

Sure.

Granville Schmidt:

based on certain policies, you may want to make sure that I asked it to do that, right? So maybe we need some out of band process to be like, hey, Granville, did you actually approve this $5 billion transfer? And I’m going to be like,

Mark Callahan:

Right. And it’s not just like, yeah, I got you. Yes. It’s like not you being Granville saying like shady and it’s like management saying, no, actually Granville is supposed to move that much money. This is one of those places where you’re like, heck no. Where did the extra commas come from?

Granville Schmidt:

Exactly, exactly. So I’m like, no. And then in which case, you know, that’s an asynchronous flow, right? And eventually by like MCP, like you can send back response saying, hey, you’re not authorized to do that, But let’s talk about another example real fast before we get into like the real technical aspects of it is what happens if we have it, if we made a request like, Hey, I need you to monitor X, Y, and Z. and then at a certain interval, I need you to make transfers, So maybe I gave it this super vague task and it you know, had a mind of its own. And at some point in time, it was, you know, it might’ve been doing everything great up until one point in time, but then it did something erroneous, right? And so that just shows the power of like, you know, even though the agent was authorized and your policy,

Mark Callahan:

Okay.

Granville Schmidt:

And even though Granville was authorized to make that request, right? And ask the agent to do that. Something else might’ve happened there, right? Something outside of my control, the agent might’ve gone rogue or just something happened in which case it was like, it made that mistake. And so then it’s like, instead of it being like the synchronous request response type thing, you know, it could be the middle of the night and I get woken up like, Hey, did you approve this? Right. So you can just see like how there’s like different levels that you need to not just do like this rough, like access control stuff, but like super fine grain authorization and just in time enforcement.

Mark Callahan:

Yeah.

Mark Callahan:

So as we think about the just-in-time enforcement, how is that accomplished today or is it? Is there a means to do that or what? I don’t know. I’m curious.

Granville Schmidt:

if you wanted to do it as an enterprise, you would have to build all of that yourself, right? So not only are you building all of your complex business logic, you’re going to have to then build out your MCP server around that. Then you have to build in all of the authentication and authorization aspects of this. Then once you have that authorization aspect, then you’re going to have to build this concept of a human in the loop to be triggered based on some authorization policy.

Mark Callahan:

Mm-hmm.

Mark Callahan:

that part’s going to potentially happen out of band and even from the flow itself.

Granville Schmidt:

Yep. yeah, like, so all of that you’d have to build all that out of band stuff you would have to build. There’s no one else in the market today that I’m aware of that can solve this.

Mark Callahan:

you’re like basically building like an identity problem and an identity solution there when in fact like if we’re talking about you know a brokerage back to that all that work is not helping them trade faster that’s all like an extra ordinary step that they don’t want to do.

Granville Schmidt:

Exactly. Or you know what, even if they wanted to do it, do you want the engineers that are like building out your core algorithms for trading or like doing all this critical business logic that may not be security experts, do you want them to own your security? Probably not. Right. And

Mark Callahan:

Probably not. Probably not. No, no.

Granville Schmidt:

We acknowledge that these enterprises have these tough problems that they need to ensure that their personnel are focused on. But we also see the needs like, hey, we’ve been building out identity orchestration now for six years, And what’s super unique here is that we see identity orchestration at the center of this agentic era. And so when it comes to these MCP servers, we already have the system called an orchestrator. This orchestrator is like this polymorphic system that can do things like be a proxy. And in this case, it can be an MCP proxy, meaning like it can handle all the authentication, all of the authorization, all of the auditing, all of the human in the loop interactions, right? Offload all of that from your team. We can do that for you, And… That’s pretty cool stuff, right? Like, so if you’re going to build an MCP server, now you’re just focusing on your particular business domain. Let me pause there. Like, I think this is super cool, right? And it’s just one piece of it.

Mark Callahan:

I mean, no, I think this actually is really cool. And, you know, we were talking with analysts all the time. We were saying, this is a real challenge. that’s what I think is so cool about it. And I’ll just speak from my personal experience here at Strata as a product marketer. I don’t want to say, you know, that we ever fell into something, but we knew that from the orchestrators capabilities and our core orchestration solutions, as we’re talking, you know, in those previous six years. where it had applicability. And what you’re describing here is it’s like literally all of that work and all the money and all the time and energy that we put into building the orchestrator. It’s almost like we woke up in this agentic world and it’s like it uniquely solves this challenge as well. Like it just all of sudden got this turbo boost of applicability of like, know, accidental product market fit that was six years in the making.

Granville Schmidt:

No kidding, accidental product market that’s six years in the making.

Mark Callahan:

That’s. I know that don’t take that from the marketing guy. I’m sure Eric’s probably go. Don’t say that, but that’s that’s what it is. It like it works and it’s like holy smokes. Look at how well it solves for those challenges that you just framed. So OK, so we’ve got the MCP proxy that it can play. You were saying is there anything else it can do?

Granville Schmidt:

Yep. Well, a lot more, but let me, let me just, like, let me just laser focus on this MCP proxy, right? So you build that MCP server. You don’t worry about authentication, authorization, doing that human loop stuff, doing the auditing. We’ll do that for you, We’re able to audit the communication from the agent to, your API endpoints or the data that you need to protect and do all the other stuff. That’s cool. Now.

Mark Callahan:

All right.

Mark Callahan:

Okay.

Granville Schmidt:

What’s really cool about identity orchestration is, MCP itself is built on those standards, A lot. today, if you were to hook that up to say a cloud IDP, that’s awesome. You can take our orchestrator, hook it up to your IDP directly, and you can get a lot of value there. But what else is super unique is that our orchestrator can be deployed as an OAuth server. And when it’s deployed as this OAuth server, it’s able to be like this IDP facade to your cloud IDPs. But what’s super cool there is, maybe if you’re getting, if you’re like authenticating into your IDP and you’re getting a token back, it’s only getting the data that’s in your cloud. It’s not getting any of your on-premises data, right? And so… by us being that abstraction, not only can we connect to your IDP, right? Like we are not the IDP, but we can be this abstraction to your IDP. And so not only enforce all of your cloud policies, we can apply other policies that say, hey, anytime that someone over here authenticates an XYZ department, we can pull additional metadata about them from these other on-premises systems, So now all of this additional on-premises data is now available in this JOT token that was sent over to the MCP from the agent. so that’s just one really cool area where like, one other small function of the orchestrator, but it’s a major impact here, right?

Mark Callahan:

It’s a huge one, right? Because I think it feels like, you know, as we’re thinking about context and why is the agent doing Granville 2.0, doing what it’s doing, there’s even potentially more use cases where you’re going to need attributes that don’t exist within the IDP itself. to facilitate that workflow and that transaction and how do you do it at runtime otherwise, right?

Granville Schmidt:

Mm-hmm. Exactly. And so, okay, cool. We can get the data from those external systems as part of that authorization flow. All right, that’s cool. You know what else we can do? Is that when we protect these APIs and these systems, not only are we governed by the standard and the MCP protocol itself, but because we’re that enforcement point, we can do additional things at runtime.

Mark Callahan:

What’s really cool?

Granville Schmidt:

Right? So we’re able to go pull even additional data. some of our customers work in super regulated industries, some of them like super confidential industries. And so like there is no such thing as one network topology that rules them all. They’re all different. Every single one of our customers have different network topologies, where your IDP sets in your environment may be radically different than where your data and your API set. And so by taking

Mark Callahan:

Okay.

Granville Schmidt:

our orchestrator and be able to be that MCP proxy, we can set it closer to these applications, thus closer to additional data stores. So maybe that the IDP system couldn’t get access to some other on-premises system like a database. But when you deploy the orchestrator as the MCP provider next to it, at runtime, we can grab even additional attributes that are just in that database. right there at that MCP server. So now your authorization decisions are not only operating on what’s in your cloud, or in your other on-premises systems, but even the on-premises systems that are as close to the application or endpoint and data that you’re trying to protect, It’s so powerful, right?

Mark Callahan:

Thank you.

Mark Callahan:

Thank

Mark Callahan:

All right, I’m getting a little bit of passion here. I get the so cool aspect of this. mean, this is, it’s really interesting. You know, I was talking with an analyst this morning and one thing I want to be careful, you know, as we talk to everyone who’s joined us, you know, through the private preview here is we haven’t solved everything. Like we’re, there’s a lot of challenges that are still being defined, right? And so as we work with our private preview audience, you know, we really want to get more use cases and examples of what are some of those attributes? What are those places? And that they might need the data from so that we can figure out how to further build really define what the orchestrator is going to do in these models. It’s awesome. It really is. I I have fun just listening to you, let alone hearing what some of our design partners are sharing, what the analysts are sharing. I mean, there’s some really cool stuff. know, Granville as we’re thinking about this,

Mark Callahan:

Anything else that you want to add about like from the MCP side specifically, excuse me, you I will have a chance to talk more, but like just as we’re thinking about the MCP applicability here.

Granville Schmidt:

Yeah, one last thing. So obviously if you’re building an MCP server, that’s great, right? Like we can fit there, we can help protect us. So you focus on the business logic, but what most of our customers have, right? And a lot of our prospects is that they have existing infrastructure, existing tools, existing APIs, And so we have another mode called MCP bridge, which is you have these existing APIs that you want to bring into this agentic world.

Mark Callahan:

Okay.

Granville Schmidt:

Instead of you having to write a single line of code or having to update a single system, we can sit in front of it and do the translation from MCP to whatever those back end systems talk and do all the authentication, the authorization policy, do all the auditing, observability and the human in the loop stuff automatically for it. So now you’re able to bring all of your systems into the agentic world, like overnight. I’m going to pause there. think those are two really cool things to think about. Yeah.

Mark Callahan:

That’s… I think you can mic drop right about there. That is pretty cool. And it’s perfect timing because everyone’s really in this experimental phase. But… you know, as quickly as everything’s moving in agentic, we’re going from experimental to production. Like that could be like a couple of weeks or, it’s going fast, right? And so we are able to offer something that’s both experiment ready, but also production ready. And I love that it’s like, it’s where we fit into this whole mix and how we’re shaping and riding along with the private preview customers as well. This is some cool stuff. I almost said the wrong word there and that, but yeah, that’s how excited we get about this, you know? And so Granville, I love working with you on this. You we’ve got a Slack group that we, our private preview team is members of. Hopefully they can engage with you there as well if they have some questions, you know, as we’re doing this as a community and building together.

Granville Schmidt:

Yeah, please come talk nerdy with me. I’m looking forward to it.

Mark Callahan:

I love that. I love that. Well, let’s talk nerdy some more. Thank you everyone for joining us Granville. Thanks for spending the time here. I mean, we learned a ton about like where MCP got its start all the way through to where we are today and like we’re StratiC and help. And honestly, we still haven’t solved it all. Our call to you all, our customers and our private preview audiences, help us understand what the use case is on because this is all getting defined every single day further and further. And so… Excited to build together. I just am thrilled to do this with you, Granville I’m thrilled to do it with our audience and hope that we get to talk to them soon.

Granville Schmidt:

Yeah, I look forward to it. Thanks, everyone.

Mark Callahan:

All right, take care, everybody. Thank you.