How J.W. Pepper centralizes and secures their MCP servers and tools early

Hey, everyone, we'll be getting started here in just a minute. Thanks for joining. Okay, I think we're at a good spot to get things started off.

Thank you, everyone, for joining us today. Today, we're going to be talking about MCP adoption in the real world. I think it's great to hear about stories with folks like the folks we have here from JW Pepper, who are actually on the front lines using MCP tools and hearing from them on what their adoption journey looks like.

And before we get things started, I'd just like to do a quick round of introductions to our speakers today. So we have Marcus, who is the Director of Systems Architecture at JW Pepper, here to share some stories of how JW Pepper is using MCP inside their organization. Tom is the Head of Product here at Tray.ai. Tom's going to talk to us a little bit about some of the problems that organizations are facing with MCP and what our vision and product roadmap looks like for that.

And then myself, my name's Niels. I am the Senior Director of Automation Solutions here at Tray. And we work with customers every single day who are looking to adopt things like automation and AI inside their business, and really help them figure out how that solution works for their organizations.

So Tom's going to get us started. And Tom, I'd like to kick it over to you just to talk a little bit about what's going on right now inside organizations and what some of the big picture things are happening with relation to MCP.

Brilliant, yeah.

Thank you very much, Niels. Well, as you can see from the slide, we're very much in the AI wild west and there's no sheriff and there's no rules. Over the last few years, AI has gone from bleeding edge to being pretty much everywhere.

Your employees are using it to build into many tools and it's happening all over the place, often without IT approval or visibility. And then in the last year, this protocol emerged, MCP, and it enabled people to go from agents which they can converse with and get answers to actually agents and LLMs that can go and take action in various different systems. And immediately, that's a very attractive kind of prospect, but it led to this kind of wild west situation.

We've got vibe-coded MCP servers that have vast levels of access to underlying systems, controls not in place, all access everything through the kind of tool selection, which creates a ton of challenges. And you also got the kind of patience problem as well. Even with clients that connect to MCP servers might have some good controls in place around allowing controlling which tools you can use and when and asking for approval.

Everyone gets that approval fatigue. And it's very tempting just to let the LLM go wild and do what it needs to do in the underlying system. But as soon as you open that gate up, you're really in that kind of situation where anything can happen.

So what's really missing from this space? MCP is incredibly powerful. We've seen this incredible growth of this protocol, but it's completely missing this level of visibility. There's no observability across multiple clients and servers.

People are running things on a local machine and collecting directly into systems and IT teams really have no idea of what's going on. In terms of security, as I mentioned before, people are giving access to full systems. A lot of MCP servers have been designed in a very broad sense.

It's pretty much an API wrapper in a lot of cases. So there's kind of a one-to-one mapping with underlying APIs. And while some vendors are starting to think more about how agents will actually use the underlying services, there's often a huge range of access and you're having to rely on users actually turning off certain tools.

And then there's obviously the complexity problem. You're expanding and exposing an LLM to potentially hundreds of different tools. And we know that once you get past a certain point, you lose that quality.

You see hallucination and the LLM will actually take inappropriate actions because it doesn't understand the kind of business logic or nuances. It's just trying to solve the problem you've set it. And then, of course, there's a compliance challenge, right? You're giving access or your kind of employees are giving access to production systems in a framework and a space you can't control.

So these are the kind of real challenges. And it's the Agent Gateway, which I'm going to kind of walk you through now, that really kind of solves that challenge. So what I just described on the kind of left-hand side, you kind of see that real Wild West in action, vibe-coded servers, different systems being linked up, engineers taking the people taking the path of least resistance to kind of solve the problems they're trying to solve with that complete lack of control within IT.

It's happening. We're hearing some of the horror stories now. We're seeing some of the challenges that are emerging as this technology kind of reaches that kind of, it's becoming so commonplace around anyone kind of building and developing with AI.

And that's where the Agent Gateway comes in. And it's part of the Tray AI orchestration platform, a controlled, structured, visible location for you to track usage and expose MCP safe and securely to all of your clients with complete visibility and complete access to underlying tools. So if you move on to the next slide, and this is a overview of the Agent Gateway and what we actually expose with the gateway itself.

So with the Agent Gateway, you can expose complex composite workflow tools, which are, you know, essentially the business logic built into baked into Tray workflows. You can expose these directly as tools, which takes away some of that LLM determinism. So you're not pushing everything to the LLM to make a decision.

You've got that control built into the tool itself. You can expose Tray connectors. We can expose our entire Tray connector library if you want, which is our robust kind of heavily maintained connectors, which actually map to business processes.

What people are doing in the system is these aren't just API wrappers. They're specific processes that people are performing in the line system. So it makes much more sense to actually expose them to an LLM client.

And finally, you know, thirdly, you can connect directly to MCP servers as well and add that level of control in. So you're not exposing an entire tool set to your users. You're giving them a situation where you can actually control what's available.

Maybe you can restrict it to read-only endpoints. So you're not exposing the ability to actually make changes in certain systems. So you've got that level of control in place.

And ultimately all this comes together to allow you to build these multi-agent orchestration frameworks. I've got more. I want to kind of show you that on about that a bit later, but first I kind of want, I want to hand over to Marcus now to kind of talk through some of the challenges that they faced at JW Pepper and how the Agent Gateways helped them solve some of those problems.

Awesome. Yeah. Thank you, Tom.

And Marcus, yeah, just before we dive into, you know, maybe your MCP journey, if you could just kind of give us an introduction to JW Pepper, what you guys do, what your role is there, and then we can maybe dive into some of the more specific areas around MCP. Yeah, of course. Thanks for having me fellas.

So yeah, JW Pepper, we're a very large sheet music retailer. We are interested in any technical improvements. We've actually been on the bleeding edge of a lot of technology, which has kept us sort of relevant in the industry.

We do not use AI for any generative purpose. I need to call that out. We're very much focused on using AI for operational efficiency improvements.

And we've seen a lot of improvements internally. I think the demands of our employees and even our customers have adjusted to that of the AI landscape. So everybody honestly at, I think broadly at companies, but clearly I'll speak confidently about mine, has kind of adopted their own AI use cases in some cases organically, in some cases by design.

But they likely use chatbots of some kind to help with their work processes. And what

we found honestly, was that people outside of the IT department, perhaps with a little bit less governance, were moving faster than we were within IT and actually creating these useful AI agents. And that IT effectively had to become a service again for this use case, as we were for other use cases at the company that were all technical.

So some technical folks in various departments that previously would have asked me, this service I have as an API, can we integrate it? Is now turning into this service has MCP. And I think at first I found it terrifying that anybody was even talking to me about MCP. As my role, I should answer your question about what my role is.

I'm the director of systems architecture, which means I'm sort of trying to set technical standards for the company and how we move forward. And I needed to figure out what was going on with this MCP and the agentic AI world. And also of course, add governance standardization, just like you wouldn't want other people in the company to integrate their own APIs.

You don't really want them to integrate their own MCPs either. At least you want some governance around that. So now at this point, we're sort of in that arms race and we're competing for what users are going to build themselves versus what we can help them with.

But I think over time where the paradigm is shifting, we're sort of becoming more of the service org again, and really helping people empower their use of AI as opposed to either being fearful of it or having to do things themselves. Yeah, I think that's a really sort of positive way to kind of look at things, right? To look at this not as something to be necessarily scared of, but as something that can empower people in your organization. And I think even when we were sort of meeting and prepping for this discussion, you mentioned something to me.

I think you mentioned something to the effect of just like APIs, right? Like MCP has sort of had this sort of gold rush scenario and you had people coming to you asking you about MCP. And you kind of drew that analogy to people wanting APIs for everything. And now they want MCP connections for everything.

There was a quote on one of the earlier sides, which I think came directly from you. It's like when finance starts coming to you, asking for MCP servers, right? Like we better have an answer right away. So I'd love to kind of hear a little bit about that journey with you guys.

And what are some of the things and challenges that you're thinking about as you have people around the organization coming to you and kind of how you approach this? Yeah. Well, I mean, a philosophy I follow that goes more broadly than just this, and I think it's just a good enterprise architecture philosophy is that almost every problem is reducible to a previous problem. And one of the things that I find interesting about the, you mentioned the AI gold rush is sort of the MCP gold rush is that everybody's, there's all these little companies popping up, trying to be the next best integration platform.

And me being part of enterprise architecture, more of a fan of standardization, I really saw iPaaS platforms as the ones that are embracing AI as a potential easier place for us to start than to just try and use whatever brand new tools there might be that aren't quite as robust and aren't as well tested basically over

time. So, one of the biggest challenges we had clearly was governance. You know, there's just like you'd have data governance or API governance.

One of the challenges with how MCP works that I learned really quickly is that it effectively forwards any access control that the user has to the AI agent. So, if they had access, let's say, to SharePoint and they're using an MCP as a tool that has access to that, they're just given the AI agent, they're effectively saying, yeah, you're me now. And that's not great because then who's actionable for what that does? If it does something untoward or if it even just has access to stuff it's not supposed to have access to, who's responsible for that? Is it the person who gave access to this AI agent or is it the agent that they can just say, hey, I didn't know it was going to do that, right? So, permissions, that was a big issue.

I can keep going. I don't know if you want any other questions before I keep going. Well, yeah, I think, you know, one interesting thing would be that just kind of like what your journey looked like, because I remember early on you guys have, again, put for a company that's been around for a long time, you, as you mentioned, have always tried to keep the company on the bleeding edge from a technology perspective.

So, you guys were early adopters of MCP even before we had a product offering. So, I'm just kind of curious, right, like how did you get started there? And then, you know, we've covered it a little bit on the governance side, but, you know, what, from your perspective, you know, what problems does having something like an iPaaS, you know, vendor who can act as a middleware, as you said, like solving some of those problems kind of fit into solving some of the challenges you saw on your journey? Yeah. So, yeah, as you mentioned, we definitely adopted a lot of this stuff pretty early on.

We have a lot of very talented people here that jump in quickly to any new technology. Honestly, the biggest challenge is, there's a few, but the biggest one I would say is not just as much governance and access control as it is the actual usability of these tools. I think it's clear to me, at least, and I think it should be clear to most folks that any AI agent is not going to know as much as you do about the company and have the domain knowledge to apply any particular action in the company.

And that becomes an issue when even if they have access to systems, they don't know how to use them. And even if you can go and write system prompts all day long and try to give it all the knowledge it needs and train it up and whatever you want to do, create, I don't know, create a well-trained, fine-tuned agent, that's just really cumbersome. And sometimes there are particular actions in the company that benefit from a workflow and actually adding, you know, what you call determinism back into the process.

So, that's why we went with the iPaaS route and specifically with Tray, because we could extend it into a workflow and say, okay, you know what? It's one action. Instead of me trying to spend all day trying to teach this agent how to do it, let me just write a quick workflow and say, hey, this is how you get order information and such. So, really just naturally organically shifted from here's 500 different MCP tools and, hey, AI, good luck, to here's, you know, some fine-tuned workflows and settings and processes that you can use.

So, it makes it more usable and easier to understand what the heck's even happening, too. Yeah. Yeah.

The classic example, you know, that we see a lot of folks who, some of the initial agents they were deploying were ITSM agents, right? Like that frontline person who's, you know, every day, day in and out, helping people reset passwords and, you know, dealing with tickets and, you know, dealing with equipment and you name it, right? Any possible issue that would hit an IT service desk. And so, the classic example we like to give there for this more deterministic thing is like creating a JIRA ticket, right? So, you could give an AI some very explicit instructions and you could give it an MCP server to create tickets in, you know, whatever your JIRA or whatever instance it is that you're using for ticket management. But, you know, to your point, you're kind of offloading a lot of that cognitive load to the agent, which you could probably figure that out, but you might need to, like, look up a user first so that you can add them to that ticket.

And you might need to figure out, well, what project does this ticket exist in? And you might need to then, you know, create that ticket or there may be some, you know, scenarios where you need to involve a human in the loop, right? And so, rather than just trying to prompt your way into that specific scenario for your business that you need, you could build a tool, what we would call a composite tool, or it's just a workflow, right, that can introduce that determinism into it. So, yes, you can give it all these connections to these systems. That's fine.

You can do that. But you can also build business process, you know, that maps to what your business is trying to do. And in your case, I think you mentioned there's a few tools that you guys have for, like, dealing with orders and things like that.

For another business, it might look a little bit different. Yeah. Yeah.

And I think the other piece beyond the complexity is clearly compliance and security. If, you know, I mentioned that getting, for example, just the information into the AI agent about what the business is, that's hard. But then it's like, of course, the simple case of, you know, just saying, yeah, here's full write access to an MCP.

Even if you were to approve a workflow, I've seen, for example, like a SQL database, MCP has a tool that's just raw SQL. So, you approve access to the agent to just write raw SQL, what could possibly go wrong, right? Yeah. So, that clearly is important too, the obvious case.

Yeah. It is interesting from a tech person's perspective to see that it can write and query and do whatever it wants. But maybe from, you know, a more security-minded organization, that could be a little too permissive for a lot of people.

So, that makes sense to me. Okay. So, I wanted to just kind of shift the conversation a little bit.

We're going to have you do a demo here in just a moment. And you've built out some interesting scenarios with the Agent Gateway and Copilot Studio. So, before we see that in action, could you give us a sense of what you've set up here and how you're balancing those more traditional MCP connector tools with this deterministic workflow approach? Yeah.

So, we've set up an

agent. One of the beautiful things about this new MCP Agent Gateway solution is that we can actually meet our customers, meaning our employees, back where they were originally, which is in their chosen AI agent of choice. So, Microsoft Copilot, we're a Microsoft company, so we used the Microsoft stuff.

But Microsoft Copilot's become a really big thing, and a lot of people are creating their own Copilots to do various things. So, we created one. I have one demo today that's specifically for IT support.

This is, for what it's worth, a bit of a fork of the original one, just so that I could normalize it a little bit for this demo. But we are using this, for what it's worth, actually in production. It's hooked up to Microsoft Teams, as well as if you wanted to open up Copilot directly, you can interface with it.

And we have two MCP tools on it. One is connection to our SharePoint, and the other is Tray. And Tray then breaks it out into however many workflow tools I might set up there, whether it be direct connector tools, so just using built-in connectors, which we're currently doing for fresh service and ClickUp.

Or it could be a few workflow tools, which kind of go through some of the examples of why you would create workflow tools, why are those even needed. So, yeah, I'm excited to show it. Nice.

Yeah, I think the everyday employee interfacing with these LLM clients is a great way to think about getting AI adopted inside organizations, right? Because that's where they are, that's where they're using it. Whether it's Copilot, or Claude, or ChatGPT, right? A lot of IT organizations are typically standardizing on these clients, right? And, you know, one of the main ways they're all talking about getting AI in the hands of everyday employees is situations like this. So, I think it'll be, what I'll do is I'll just pass the screen share over to you, and let you hop in, and just kind of explain to folks what's going on.

Sounds good. I'm just verifying if you can see my screen there. Looking good.

Awesome. Okay. So, this is Copilot Studio.

So, this isn't necessarily where the users would be using it, but the cool thing about this is you can see, as I type over here, you can see the tools that it's using on the left. So, I think it's just a great place to demo this. So, what I'm going to do here, I obviously have a canned workflow that I'm going to go through just, you know, for the sake of the demo, but clearly this could be for more than just this.

So, I'm just going to ask it to help me with a ticket that I have, which is... Now, Marcus, before we really get going here, it's important to know, what is the name of your agent? Oh, yes. Clive, or Clivenator. Although, this one's called IQ Support Agent, so not quite as nice.

We had one called Clive before that wasn't as powerful. So, then we're like, what do we call the more powerful Clive? Clivenator. Clivenator.

Yeah. I don't know. It's like Terminator vibes, I guess.

But you can see here, I've just asked it for a ticket, and it's gone through and used trade tools here. So, I just have this hooked up, as I said, as an MCP tool. You can see it's using a built-in connector.

So, I will show this soon, but I have three fresh service connectors and 13 ClickUp connectors. It's just using them directly. So, for viewing tickets, for listing things, honestly, I effectively turned on what was any of the reads, basically.

So, real quick, Marcus, I think it's important if we can just sit on that for a moment, if you don't mind going back to Tray, just to make sure that people understand what this is. So, you're inside Tray. You're looking at our MCP server offering, and there's, again, these two options you have here to expose functionality that you're showing in the demo.

The first one are these connector tools. Would you agree this is kind of like a traditional MCP server, in a sense? Yeah. So, not everything has to be made custom, right? So, if there are built-in connectors, you can hook them up here.

I'd say the biggest difference, and this is coming from an outside perspective, obviously, from Tray, is that it's more robust, because a lot of the companies that have tried to get a piece of gold in the gold rush of AI have created their own MCPs that do something. These are well-trued and tested MCP tools that are used already in iPads, so I think of it as a little bit more robust, honestly. But they're not custom.

Effectively, you just add a connector here to whatever tool you want, and you get any of those built-in connectors that already exist. And you get whitelist ability, right? So, you're opting those connectors in, right? So, you only want the read. You don't want the write or any of the other CRUD operations, basically.

And so, that's the first tool in your demo. Sorry. Keep going, please.

Yeah. And I think the only final thing to say there is you're also not even giving that option to the people that might use it in the company. So, those that would use an MCP tool, let's say, if it was actually a click-up or a fresh service MCP tool, I don't even know if those exist for what it's worth.

But if they did connect them, then they might say, yeah, well, sure, just write access like I have. Just give it everything. And in this case, we're just not even allowing for that, to be honest.

Yeah, that's a good point. Sorry, Marcus. Go ahead.

Which is more detailed. So, these are specific integrations we've created that are exposing new MCP tools that are really just trade workflows. So, we have a few here for a few purposes.

I think it might be better if I go back to the co-pilot, show how these are used, and then I can go into the weeds on what exactly it's doing. But what I did is I looked up a ticket. So, I got that ticket result.

And this is someone who's a Boba Fett called, the Mandalorian, to say status of their order. They aren't able to see their order status. So, I'm just going to say, okay, can you look up the order? And now what it's doing is using a custom tool.

So, this is a custom workflow tool that we've created in Tray to look up the order and get information about that. So, there it goes. And now it's saying, you know, the status of the order.

And actually even says, like, do you want me to do this? Do you want me to update the ticket? Now, I could probably go into the system prompt for this agent I have in some cases and say, hey, you know, do the thing that you think you need to do. And it could use multiple tools at the same time. But in this case, I've made it very structured.

So, it's going to ask me. So, I'll say, yeah, just go ahead and add the order status to the ticket. I'm just asking it to do that for me.

Just go back to the ticket. And this person's asking for status of their order. Let's go ahead and add that.

So, now it's adding a note. And again, I can click through here and actually see exactly what it's doing. So, here's what it typed out.

Saying it was completed. It was placed on our web. It was paid by credit card and shipped via two day air.

Completed on that date. So, it's just typing out stuff I don't even want to worry about. So, it's just doing it for me.

So, we're sort of, you know, big benefit of using AI. So, I did kind of drive it here. Obviously, as I said, demo.

But there's a lot of robustness to this beyond just this one use case, clearly. All of the tools it has access to and the places you can go with that is definitely huge. So, as I mentioned, we have a couple built in tools here.

Viewing a ticket is one. However, there actually wasn't a connector tool. There's not even an easy to use API for fresh service to add a note to a ticket.

So, that was one example of a tool that was just us building a workflow to accommodate a missing feature, right? Which can happen. So, this workflow is pretty simple. This one's just adding a tool, adding a private detail to the ticket as a private note.

We have one that gives access to a documentation repository. So, if the tool needs access to any information that, you know, we've already put inside of a knowledge base in Tray, we can connect this up to that repository to get information. So, kind of expanding upon our previous use of Tray as an iPaaS and workflow solution.

And then I think this one's really interesting. This actually, this tool solves two problems I mentioned before. One is if you need to look up an order and connect to our SQL database.

Right now, if I did that with just an MCP connector, it would be like the raw SQL example. You just put in a SQL command and say, yeah, go for it. Why not? But the second reason is we actually have some complexity in our company, which is if someone provides us with an order number, that could be from any, I think it's one of three systems that we have orders in.

And that's obviously a bit of technical debt. I think a lot of companies have technical debt. But we have different order numbers.

And it could be from the e-commerce platform, it could be from the warehouse, or it could be from our ERP. Now, I could spend, as I mentioned before, all day just documenting in the system prompt. Here's all of the different orders we have and places you can go.

And it probably still wouldn't be deterministic, right? It would be making things up. So instead, what we did is we just created a workflow that basically just queries based on any provided order number. So it will take any order number that might be useful.

It doesn't really matter. In fact, it even says here what it can be. It can be either of these things.

And then it does a few queries, which these are, of course, using actual SQL parameters. So they're well-protected queries. With protecting against SQL injection, for example.

And then we get carts, we get orders. We might say, I think this actually matches on two different things. And then we would just respond with that information.

So it's a simple workflow, really, really simple. And I think what I might call out for a moment is that as I've begun transitioning our use of Tray into this MCP setup, I am finding that our workflows are becoming almost like microservices. They're becoming micro workflows.

They're becoming smaller. Because instead of us trying to build this whole robust all-in-one iPad solution, we're just adding these little drops of determinism into what the agent can do.

That's what I got. That's a great example. And yeah, I appreciate that.

And one, you know, one follow-up question might be is just, you know, how, how do you manage which teams are doing what, and, you know, how you build tools for them, how, how's that been going and just kind of get a sense of, you know, where you see this today versus tomorrow, Yeah, well, I think that the biggest thing is we have shifted the paradigm to ensure that folks in the company are aware of the service that it offers, that we're not just, we are kind of a, we're, we're now becoming not AI first, but we're native to the AI world. We're learning more. So instead of trying to kind of remove those X, Y problems of AI, I have this software, can you build an AI thing for it? It's now here's the robust technology that we're building all of these solutions on top of is a systemic approach basically.

But we've also removed a lot of risks. So from the people in the company that would have been security aware individuals which I like to think is most people they know that they can't just copy paste into an AI chatbot anymore, there's a little bit of governance around that that goes through these tools. So that's obviously one aspect here is we provided some level of governance.

Providing access with some guidance and with some determinism makes it more usable. So people in the company are less likely to just do things themselves with their own chatbots because they're actually seeing use out of usefulness out of the idea of adding these workflows and extending upon that MCP solution to make it more robust. Awesome.

Well, what I thought we could do here for a minute before we kind of kick back to Tom to talk a little bit about our vision and stuff like that is just maybe take a few questions and see if folks would like to know anything either from the Tray team or from Marcus. So let me just start our screen share again. There we are.

And so I do believe we had a question, asking, are you using Tray's LLM or your own? In short, what the thing to know about MCP is the agentic system, right? That is whatever it is. So in Marcus's case, copilot, right? He determines what the LLM there is. And in this particular case, we are LLM agnostic, right? We are providing the connectivity for that agent.

So if that agent is built in Tray, you can use your own LLM. We have this thing called Merlin agent builder where you can easily build and deploy agents internally. It can have connections to the same tools that MCP offers, right.

Or if that agent exists outside of Tray, which is what Marcus shared with us with copilot, or if you're using Claude or you're home growing your own agent, whatever it is. Tray can provide a governed MCP server there and you can use whatever LLM you want. Just to extend upon that a little bit, if you don't mind Niels as well, we've actually seen, we've used both.

And one of the things I guess I forgot to show on the demo, you always forget something is that in that fresh service connector where we're adding a note to a ticket, it actually has to be converted to HTML before it can be added. That's one of the pieces of complexity. So we actually just used a quick little Merlin step to say, Hey, can you convert this to HTML before putting it on the, on the ticket which is to say that basically, you know, it's a little bit of a precursor, I think, to the agent to agent set up where it, your tools itself can, can have embedded.

AI or LLMs. And in a lot of cases, it just makes sense to use a simple Tray one, as opposed to trying to use your own in that particular situation, but yeah, very meta so AI in the AI layered in, but the infused AI into the workflows is an interesting concept, right? Where it's like, okay, I've got this agentic system over here using these tools, but even in the tools themselves, we can infuse AI to make the process, you know, easier to deliver or something like that. I love that.

I really love that specific example. And I think, you know, there's a habit when we approach AI to try and solve the biggest problem straight away, you know, solve everything straight away with a massive system prompt and access to all the tools, but that really kind of quite neat example of I've got plain text, I need to convert it into kind of HTML so I can use it, you know, to add a ticket to a fresh desk or add a note to a ticket is incredibly powerful because if you're building that natively, you know, you're investing time in it, it's going to have tons of bugs, you're going to be kind of iterating over a script that does the conversion, you know, you're going to basically then have something you need to maintain, but it's just perfect. Kind of, I guess, non-deterministic process where you're going to get reliable HTML out of the end because LLMs are naturally good at kind of crafting this, they understand the requirements and you've solved a kind of real complex problem really quite easily without, as you said, with one or two workflow steps.

I really, really do love that example. I agree. Thank you, Tom.

I want to get to some of these other questions here. So I think this is a good question. So what level of experience would you suggest users have before they dive into the wonderful world of MCP Agent Gateway? And I mean, experience with Tray as well as MCP agents.

I'm going to let Marcus give his unbiased opinion here. Yeah, so you need to have your doctorate in MC, no, I'm just kidding. There's, it's, I actually think in a lot of cases, the roadblocks that I had previously, and I think I can say this, we used a different sort of really technical Agent Gateway before Tray that was extremely difficult for us to maintain.

It was like a Docker system that we were running because we do a lot of Kubernetes. And that was clearly very technical. And I would say you do need a doctorate in MCP to get that spun up.

But with Tray, honestly, it was just, it just felt like iPaaS. So I think if you've got a good amount of iPaaS experience or ETL experience, what have you, I think you can natively or naturally, organically, if you will, grow into this agentic world. And it made a lot of sense to me and some of the people that were more of the data architect side of the business, they sort of were able to understand it because it was, there was an interface behind it and there was some robustness to that.

Yeah. I mean, honestly, so I've been using Tray for close to seven years and I was a customer for three years before that. I've invested a lot of time in learning Tray.

In a weird way, it's almost easier because you are kind of letting the LLM handle some of the decision-making that you might've otherwise made in a deterministic, you know, integration. And so, you know, you can really expose somewhat low level workflows, meaning create a ticket, look up an order ID, kind of the, if you look at the tools, they're oftentimes kind of simple, right? Like, you know, they're not these, you know, very robust, big, giant workflows. Oftentimes they're a handful of steps and then some of that cognitive load can be offloaded.

So I don't think you need, like, you know, obviously if you're using Tray to do this, going through our academy courses and learning the fundamentals of the platform are going to help you build the tools, but it's really easy to get it up and going. Okay. Next question.

So great demo. Congratulations, Marcus. I see that the co-pilot console sends the question to the Tray MCP server.

Would you be able to show a little bit about how Tray determines which connector or workflow to connect? And also if you could provide some more details about where the security is enforced. And maybe you can take the first part, Marcus, and maybe Tom, you can take the second part. I can take a little bit of the second part.

Oh, okay. We've taken, and I think that's an easier answer actually for me to give. Some of the security is happening on, because we're a Microsoft shop.

So when we create these agents, at first of all, at the agent level, we can expose the agent only to certain departments and groups. But then of course, at the tool level, Tray has built-in governance. That part I'll let Tom speak to.

But from the standpoint of even just the agent itself, because we're now meeting the customer, meaning the employee, at the place where they were using the agent, we can use built-in access control, like Microsoft Entra access control setups. And then, sorry, the first question, how to determine which connector? That part is kind of just how MCP works. I think it, I may actually defer that one to Tom.

All I'll say at this point is that, you know, it has a more reduced list of connectors than if you just connected an entire MCP. So since we were going through and selecting just a few different connector tools, it doesn't have to assume as much. But in general, that's part of what the LLM does, is it just gets the list of whatever tools you have connected and uses the best one that it thinks is good for the job.

But just because we can restrict that a little bit, you know, there might be some tools that, not even for governance purposes, just because we don't think they're going to be useful, we don't turn them on and it doesn't muddy the waters. Yeah, just to add, sorry, go ahead, Tom, really quickly that, you know, they, in this state, you know, it's not actually Tray which is determining which connector is good. It is the LLM client.

I think you're using a ChatGPT 4.1 and there, if I remember correctly, Marcus. So that's where the determination is happening, which tools to call. And as Marcus says, once you expose the tools via the Tray MCP server, they're inserted as a, you know, as part of the system prompt to, well, as part of the prompt to the LLM with the kind of tool description and the required inputs, the LLM determines which ones to call based on the requirements.

I think in total, you've got, you have the three composite tools and then 16 connector tools in total, I think. So that's around 19. That's around the sort of optimal number of sort of the, the kind of current kind of like top recommendation for number of tools around sort of the 20 mark.

So it's kind of a perfectly scoped kind of MCP server in a sense with a very specific problem with the right level of access to be able to do what it needs, you know, across the, the kind of inbound request that Marcus showed. And honestly, if we were to just connect one of those MCPs directly, even just one of those systems would have been over that threshold. So that's why using a gateway is definitely the way to go.

And then of course, going more into the future of agent to agent to then have sub-agents working on specific aspects of your business, that's also the direction we want to go eventually. Awesome. Thank you, Marcus.

Dave has a couple of questions here, Tom. I think I'm going to point them your way. So what does what authentication protocols does Agent Gateway support and then ask about OAuth2? Yeah, so right now it's token-based, but OAuth2 is coming in the next sort of four to five weeks.

So we'll have full both based token-based and OAuth2 support in place. So that basically increases then that kind of visibility and user piece, because then you'll be able to map you know, individual users to particular, you know particular actions to give you increased visibility. So I actually touched on that slightly in the roadmap section as well.

So I'll cover that some of that there. I can see David also asked about the availability of the Agent Gateway. The Agent Gateway is available right now.

So if you're interested in getting access, reach out to us, we'll get it set up so you can, you can access everything you've seen today. Yeah, it's available right now. Awesome.

All right. Thank you, Tom. That's a good transition.

I'm probably here to kind of wrapping things up. Obviously, if anyone here has questions for the Tray team, you're, please do ask either your account manager or if you're in our Slack community, which if you're not, you definitely should be. It's a great place to talk to other builders and meet directly with folks like Tom and myself.

You can ask in our community as well, but, and we'll help get you connected to start using the product. But just in terms of framing things a little bit for the broader, our broader approach to AI adoption inside enterprise organizations, how Tray can help your organization is a couple of different ways, right? So first in, first in line here is the ability to use the platform holistically for your agentic needs inside your organization. So there's a lot of interesting things, whether it's through Merlin Agent Builder, which is a low code approach to building and managing agents inside your organization, things like the ITSM agent I mentioned earlier.

You can use Merlin Agent Builder to deploy that quickly. Obviously, you know, no matter where your agentic solutions are sitting, data is critical to making sure that you have a good agentic set of solutions inside your business. And an integration platform obviously helps you make sure your data is in a good spot between different systems and readily available to the agentic solutions inside your organization.

We have lots of connectivity, as we sort of showed in this demo today, right? The full Tray connector library is available through MCP or it's available through our general iPaaS for that data foundation or even through for agent development through Merlin Agent Builder. And then, of course, this is all built on top of a shared architecture. We're not building everything with, you know, through acquisitions or different software systems.

Everything's built from the foundation up on the same architecture, which is a serverless architecture that scales quite well. For your organization, everything's composable, meaning we try to make it very reusable. The same tools that you build in MCP can be available to the agents that you build on Tray, can be available as services to your integrations.

And we care deeply about your security and the information that you're passing to these systems. So we invest heavily in ensuring that we're meeting some of the most stringent compliance standards. And this is all what you get when you use the Tray platform.

So with that in mind, Tom, I'd like to maybe just hand it off to you. You sort of alluded to some of this stuff and even Marcus did, too, about where things are going. But I thought I'd let you kind of talk a little bit about where we're going from a roadmap perspective.

Yeah, please. We can jump straight into the next slide. And I think this visual kind of a lot of what you see here, you got through the demo.

Marcus showed a lot of this off. You can see some of the specific kind of tools as well. Capalite Studios on the left hand side, they're interacting with Tray via MCP and it's accessing a range of connected tools and workflow tools, performing some of the functions that Marcus showed you earlier.

Niels just touched on it as well, like we really saw like agents as the evolution of iPaaS and the place to actually build agents. You know, we obviously we've shown the agent builder and many of your customers using the agent builder. It's essentially the layer above the workflow tools and the connected tools.

I mean, a workflow is essentially a collection of connectors with logic in between. An agent is essentially a collection of workflow tools where some of the determination is passed to an LLM. And that's really kind of that core kind of Tray experience, this level of composability across this kind of tool stack.

In terms of what you can really see here, we call it the Agent Gateway because there are competing and emerging protocols in here. So what you're going to see coming soon, and I've got a kind of example of how this will look within the Tray product, is us looking into the A2A protocol as well and actually exposing agent to agent communication. So instead of just kind of having a single agent communicating with a selection of tools, you can actually pass work from one agent to another.

And this is this is really going to be a big focus of 2026. We're seeing lots and lots of customers who are now looking at kind of getting their agents to work together. You kind of see that on the kind of right hand side as well.

You know, agents tend to be kind of primarily conversational right now, but we're starting to see more and more of kind of system based like agent triggering and interactions, events happening in a certain system. You know, a new lead is created. I want to perform certain actions off the back of it.

Well, now you can make this process much more non-deterministic. You can offset things based on a particular, you know, based on a particular lead to an LLM to make decisions. And then you can see how this kind of plays into this stack over here.

So that's a big kind of focus of what's kind of coming up next. We also touched on the OAuth 2 piece. You know, that's coming soon and it's kind of alluded to here with this kind of concept of user identification.

You'll be able to see which users are interacting so you can control which level of access they have. But also who's coming in and then you can obviously build in layers of access. So essentially, you'll get to the point where you'll be able to expose all these tools.

But maybe there's a certain scenario where Marcus wants to expose right tools to a particular user. You can actually have that level of control where as we know who the user is, you can expose that level of access. So that's really what's coming next.

And I think just really quickly on the last slide, I know we're bang on time, but just in how kind of this concept of A2A and this like agent to agent communication is going to look, it's essentially the level above what you saw right now. You're going to be able to define the skills that particular agent has and then how you interact with that agent, what you can pass the agent. And then you're going to make it discoverable to other agents within your organization.

So you get to this point where, again, you're basically bringing that composability a level up and you're offsetting works to different agentic systems. That's something that will be supported entirely through the trade platform. But also, as you saw from the previous slide, you'll be able to expose your external agents to the clients.

Again, as Marcus said earlier, where your users are, that's the real key driver of this and also connect to other agents in other systems. So you can actually use Trace as kind of central organization or orchestration platform for all of your AI. So that's really kind of the future.

And again, I am conscious we've run over. So thank you so much for staying on with me for a couple of minutes to kind of walk through this. Going to be tons more information coming on this soon.

And if you've got any questions, feel free to reach out to me, Niels or the team. Awesome. Yeah.

And thank you, Marcus, for spending some time with us today and everyone for joining. Have a great rest of your day and we'll see you guys in the community.