Searchable transcript of 5 Ways to Connect AI Agents to Tools: From APIs to MCP — IBM Technology (11:28). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by IBM Technology. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 Agentic systems are emerging everywhere now and are being integrated into our enterprise processes. Now there are lots of ways to connect agents to tools in these processes. And today we're going to count down the top five patterns for connecting agents to the tools. Let's start with number five. And this is a direct connection. Basically what this is saying is that we have a user.
00:35 They're interacting with an agent. And that agent is connecting directly to a tool. And this is a model that we saw really early on in AI when we were doing gen AI, when we're doing RAG models, even some of our agentic systems, where we built an agent and we used existing ways of connecting to that tool like API keys, service IDs, whatever we needed to go connect and extract information, use an LLM to kind of process the prompt and the response and give that back to a user.
01:11 And this was a very, very simple and straightforward model. So. Let's look at some of the pros and cons for using this. First, let's start with the pros. Well, it is a straight forward connection. It really doesn't take much more than what we already have. We build an agent, we connect a tool, we use our existing ways to do that, and everything works really great.
01:39 Now, let's think about some of our cons with this. Well, the first con is that we do not have any visibility to the user. In other words, this agent is interacting with the tool, but it's using its own credentials to access the tool. The tool has no idea who the user is and whether they're allowed to access anything or not. And the way we got around this is basically we only, especially early on in the Gen-AI days, is we only allowed information to be accessed that was generally public or available to the entire
02:12 company. So we were able to work this out pretty well. All right, so that was number five. Let's go to number four. Now, number four is still a direct connection, but now what we're gonna do is we're going to add OAuth flows. And what this is really saying is now what were adding into the process is we gonna add an identity provider so we can do authentication of the user.
02:44 We know who the user is, but we're really gonna tie this in over at the tool site. There are several tools that we work with, GitHub, Jira, Slack, that have their own OAuth abilities to do an authentication. So what happens is the agent talks to the tool, the tool comes back and says, okay, who is this user? Let's authenticate it. That comes back to the tools, the tool issues an access token.
03:08 Now the agent is able to use that to connect to the Tool. Now... We've seen this model in other areas as well. So if you're using any kind of tools for doing development with vibe coding, if you are using Claude, Claude will go out, it'll interact with the tool, get an access token and store that locally. So now it has a way of interacting with the tool and know who the user is.
03:34 So let's look at some of the pros and cons for this. So, well, first pro is that it leverages OAuth flows. This is really nice. This is an established pattern. We know how to do this, and it really starts setting up a way to actually authenticate. The user. So this is really nice. Now we've added a little bit over on top of what we did for pattern number five.
04:03 So what does this mean from a cons perspective? Well, one of the things now is that we've add impersonation. We've eliminated no visibility to the user, but now we're doing impersonation. So what does this mean? Well, basically as far as the tool is concerned, it's seeing the user. The agent is really impersonating the user when it's interacting with the tool.
04:30 So the tool has no visibility to the agent or what the agent is trying to do or what agent is allowed to do. It really is impersonating to user. The other thing that we're seeing here Is that we're starting the introduce long-lived credentials. Now with the NoAuth flow, and especially in some of the tools, GitHub, you can actually get an access token created that can live 90 days longer, depends on how you have it configured and set up.
05:03 So yes, the agent can go interact, do the authentication, bring it back and store it, but now you have a credential that could live for quite a long time, and that becomes a con for this pattern number four. All right, so now let's go to pattern number three. We're going to remove the direct connect part of this. And we're actually now going to add MCP, Model Context Protocol, into this.
05:31 And we are going to do the same thing in our drawing in our model here, is we're going now add MCPs into the middle of this. Now, nice thing about this is everything basically stays the same. The agent is talking to the tool, we're doing the OAuth flows, we're authenticating against the application, we're bringing an access token into the mix, but now we're adding MCP into this layer.
06:01 And this is really nice because in the way that we were looking at this before, the agent had to know the tool specifically. It had to know... how to interact with the tool, and every agent had to know with whatever tools it was interacting with how to react with this. When we bring in MCP here, then we start talking about bringing an abstraction layer into this.
06:29 In other words, the agent only needs to know MCP. It doesn't need to know anything about the tools itself. It just needs to understand You know how to interact with MCP. And this is nice because the thing that it takes away then is now the agents don't have to know everything about the tool. So we've added another feature to what we're trying to do.
06:52 All right, so now this brings us the pattern number two. We're now going to eliminate. The OAuth flow of this, and we're gonna add on behalf of, and we gonna add a token exchange into this. All right, so let's look at what's happening here. So first thing is we're gonna bring in a token exchange into this. And a token exchange, and this whole system now is going to interact.
07:30 Now we're gonna require the agent to authenticate itself. So now we're going to know who the agent is, and it's going to operate on behalf of the user. So it's gonna do delegation. Basically, a user is going say now, I'm gonna delegate to this agent work that I wanted to do against the tool. So now, we know who user is, and we also know who agent is.
07:53 And the other thing that kind of comes into this with a token exchange then is that now as we move tokens. We have an access token. We're bringing this all through now. We're kind of making sure that the flow of that token is secure the token exchange adds a layer security onto this, to kind of make sure it's flowing correctly. So let's look at what we're doing now as pros for bringing in a token exchange.
08:18 Well, first thing is that we're going to authenticate the agent. So we've authenticated the user before. We've actually started getting rid of some of these other mechanisms. We're getting rid of the straightforward connection. We're actually now not going to just totally rely on OAuth as an application. Now we're going to start building out a token flow.
08:42 And so now we have an authenticated user. We have an authentic agent. We also have the agent operating on behalf of the user. So this is really nice. Now we're bringing this into the mix of everything and we've added a token propagation. Now when we start thinking about the cons that we had with this, well, we've gotten rid of the visibility user, so now we have visibility of the user.
09:12 Now we're eliminating impersonation. Now the system has visibility to the user and the agent, what they're allowed to do, everything that's going on. We have full observability and transparency now so we can really start seeing the system work the way we are starting to really want it to work. Alright, so let's get now to pattern number one, our top pattern.
09:38 And this is basically what we're gonna do is we're now going to add a vault. And this comes in, if we look at our picture, now we're going to bring in a vault here. And it's going to interact with MCP. So what's happening? So as we discussed, the way this was working with OAuth flows and even in the previous, in pattern number two, we were having to bring an access token for the user and store it for a long period of time.
10:08 And this is something we really don't want to happen. We really want tokens to be very short lived. So if they're intercepted and replayed, then they only last a short time and then there's no longer the ability to do that. So what we introduce now is instead of the tool, instead of this whole flow, bring in an access to come back here, we store that long term token in a vault that we can really lock down and control, and then the vault issues a short-term credential to MCP for the user.
10:39 So now this agentic flow is using only short-lived credentials, and this is a really nice pro that we are bringing into this whole pattern. Is short-term lived creds. And of course, adding that eliminates that whole piece. All right, so there you have it. A countdown of the five most common patterns for connecting agents to tools, each providing a little bit more security than the one before. Thank you very much for watching.