Okay, so I hope you're in a good frame of mind.
We're going to go through our different technicalities, each of our three slides with three different
concepts to get across.
And this is the first slide, the first technicality I want to go through with you in that there are
three parts of MCP, three pieces of the puzzle and they are called the MCP host, the MCP client,
and the MCP server.
Let's go back the MCP host client and server.
What are they?
Let me explain.
The MCP host is the overall environment where your agents are running the overall software product that's
controlling your agent environment, which might be Claude.
If you're using Claude, either Claude on your desktop or using Claude through anthropic, the website.
But that is like an AI product that you might be using.
You might be using an AI application that might be like a, like some some software SaaS product that
you're paying for, that you're using.
Or it might be n810, you might have an n810 workflow, and that would be considered an MCP host.
It is like an AI environment which is running an MCP client is something within that host.
It's a small component of software that runs within that host, and there are potentially many of them.
There's one of them for each of the tools that you want to run, or each of the sets of tools that you
want to run from the third party, or to be specific, there is one for each of the MCP servers that
you are running and an MCP server.
That is the business.
That is where it all happens.
An MCP server is a particular group of tools offered by somebody under one kind of umbrella term that
is set to to carry out some, some functionality for an LLM that is described in language by the author
of that MCP server.
So the MCP server could be someone like say, fire crawl, fire crawl that we that we worked on before.
Fire crawl allows you to to search the internet.
Fire crawl has a few tools.
They could package them up, put some English to describe how they work, turn that into an MCP server,
and then something like N810 could have an MCP client in there that connects to an MCP server that runs
the fire crawl tools, and you can do the same thing for many other kinds of tools.
So that is the definition of the three different pieces of the puzzle the host, the MCP client, the
MCP server.
That's what they are.
Okay.
Technicality two is really quite a technicality.
So forgive me.
If you're not interested in this, then just put me on two x zoom through this.
There are different ways that MCP clients and MCP servers can talk to each other, different ways that
they can connect.
And that matters because some MCP servers are only available with some types of connection, and these
things are called the transport mechanism.
Sounds very high tech transport mechanism.
And there are three of them.
And the first of them is sometimes called stdio, sometimes called studio.
It stands for standard input output.
It's the simplest one.
It's when the MCP server runs on the same computer as the MCP host.
It runs on your computer, and the way the client talks to the server is what's called standard input
output, which is one of the simplest ways that things can communicate.
And so that is the first way and it's the simplest.
The second one is called SC and it's a legacy approach which is no longer used.
Sorry.
It's deprecated.
It is still used.
I shouldn't say it's no longer used because it is it's no longer recommended for new build outs, but
it is very much still a thing.
And the third one is the replacement for se Streamable http.
It is the updated version and numbers two and three.
Those two techniques can happen with the MCP server running somewhere completely different to the MCP
client.
That is like a remote connection, whereas number one only works if it's running on the same computer.
And that's the big difference between one, two and three.
And that's really all you need to know about it.
That one runs locally and that two and three run remotely.
And that three is the new one.
And that's that's that's pretty much it.
With one other little fact that we're going to get to.
And now for the third slide, which is more practical, which is about.
All right.
Okay.
So now I've told you all this fancy lingo.
How about how do we actually use MCP within N810.
And there are three different ways.
And the first way is that you can have an MCP client tool attached to your agent.
So we know we have these AI agent cluster nodes, and that one of the things that come off them is tools.
And we know that we can put in different tools in there.
And so it should be no surprise to say, hey, you know, one of these tools can be an MCP client,
and that means it's going to connect to someone else's MCP server, which is going to give us access
to someone else's tools.
And so that's cool.
That is that is one way we can use it.
And that is the most common way.
And that is the that is the great way.
That is the way that allows you to use other people's tools within an A10 through an MCP client, by
having that as your tool.
So hopefully looking at that image makes sense to you.
It's like, okay, I get it now.
That picture we saw before that is the MCP client inside Nan as the MCP host.
All right.
That's the first way and the most important way by far.
The second way is that you can say, hey, my whole my whole workflow can itself be an MCP server.
Somebody else's MCP client can talk to me and I can provide tools to them.
Right.
It's like the flip side, you can write tools that other people reuse.
Okay.
And how do you do that?
Well, there is a special kind of trigger called an MCP server trigger.
It's saying you want to be an MCP server.
All right.
I you can I can have a trigger.
And it only has one thing that you have to attach to it.
And that is the tools the tools that you are offering as this MCP server.
And so you can put some tools in there.
And in this screenshot I put in one that's just an HTTP request, that generic HTTP request that we're
then going to offer up as tools to as an MCP server that way.
And that would then become an MCP server that other people could attach to with an MCP client in MCP
host.
So that's the second way that you can use Nan.
Not nearly as common as the first way.
And there's a third way.
And the third way is just like an extension of the second way.
So no need to worry.
It is just saying there's also a cool setting that allows you to kind of apply this, this approach
globally, across your workflows or to a subset of your workflows and say, hey, I want I want to be
able to give the outside world access to any of my workflows and treat them as MCP servers so that I
could go to Claude and just talk to Claude and have Claude run any of my workflows.
And that's like a setting, a global setting that's on the settings page in.
I don't think we're going to use that.
We're going to we're going to build the first thing for sure.
And I think once we're going to do the second one as well, just to show you what it's like.
And this third one is the same kind of thing for, for for everything if you wanted it.
Okay.
So those are the three ways to use MCP with n and n, keeping in mind that that first one is the most
important one.
And now at this point, you might be thinking to yourself, hang on a minute, this this MCP client
tool at the top there.
Just explain to me how is that any different to the other tools that we've already put there?
We've put a bunch of different tools there.
What's the difference between those tools?
And using an MCP client tool that connects to an MCP server?
And that's an excellent question.
And and you're absolutely right to be confused about that.
And I wish to clarify here it is the where you have a tools node that you can add in.
That means that the team at Nh10 have built a custom node specifically for that tool.
They've described it for your AI agent, they've put in the language.
They've they've built this tool and made it so you can click and add it in.
And sometimes there's also community nodes, which means people in the community have written them and
they've done the same thing and they've packaged it up.
And that is all part of what you get with N810.
You get all of these tools that come out of the box that people have written, and that's great.
And that is what you should always choose as your first preference.
If someone has made a baked tool that you can just drop in here and use in Nw10, that's always going
to be best.
That's the thing to use.
The time that you use MCP client is if you want some other set of tools, a set of tools that someone
else has written where nobody has packaged it for N810 you don't have a node available before MCP,
you are out of luck.
That was it.
Or you'd have to write code for it or something like that.
Before MCP, you didn't have a way to get around it if there wasn't a node there.
With MCP now you can just drop it in to N810 as an MCP client and then connect MCP server.
And you can do something very similar in all of NS competitors and any other product like this, because
it's a standard.
So everyone is doing it the same way for MCP.
Whereas before you might have to make an n node and you might have to do something different for other
products that you wanted, like Zapier, you might need some other kind of thing in there if you wanted
your tools to be exposed there.
But because of MCP, there's one way of doing it.
And then anything that supports dropping an MCP client in there, you can use it right away.
So that's the key distinction.
I'm sorry to ramble away about it, but I do hope that's clear in your mind.
First and foremost, use any tools.
They are the ones that have been specifically packaged for you, but if they don't exist, then as a
fallback, if you find an MCP server that has the functionality you need, you can just use an MCP client
here as like your generic connector to any MCP server.
That's the idea.