Well, I don't know how this day always comes along so fast.
It feels like just the other day we were starting, we were doing instant gratification and then the
foundations.
And now here we are already.
It's the penultimate day.
It is week three, day four.
It's our last Purple day.
As we embark on the topic of context engineering.
Subagents so much juicy stuff.
And then we begin today, the capstone project that we will complete tomorrow as we wrap the whole thing
up.
Let's get going.
I promised you a big day yesterday and it was a fiendishly big day.
We covered MCP, the model context protocol from anthropic, as they call it, the USB-C for AI apps,
and they also call it the open source standard that connects AI applications to external systems.
Or really, for the part that we really care about is tools.
And I started yesterday by by going through what MCP is not.
And after we laid that to rest, we covered the couple of things that MCP really is, and we put both
of them to use.
And of course, one of them and the main one, the one that is most important and the one that you should
definitely remember, is that MCP gives us this simple way to use tools that have been written by somebody
else.
And so if someone has written MCP tools and they've packaged them into this, this MCP way of doing
things, then it's really easy to connect them in to your app or your workflow.
So it turns out that there's some things where Nan did not have a pre-baked tool that we could just
use, Fire Crawl in particular, but Fire Crawl did have an MCP server, and so we could create an MCP
client node that connected directly to it and just exposed its tools to our LLM.
And it worked great.
And we did it for Hunter.io as well, even though Hunter.io does have a tool in in the library, but
it turns out that it was able to use some tools that aren't exposed to Nan.
So we did get some benefit anyway by using MCP.
So it was it was pretty cool.
But the takeaway here is that this is the way that people use MCP, and this is the thing you need to
know about that.
MCP gives you an ability to use someone else's tools in a really easy way.
As we saw for ourselves.
And then the other thing that you can do with MCP is just the flip of this is to say, if you've built
a tool and you like the tool you've built, and it's something that other people could benefit from,
or maybe you could benefit from it in a different app, then MCP gives you this really easy way to equip
another LLM with your tool to share your tool.
And that is also what we did.
We took everything.
We'd built our prospecting subagent, which itself was using MCP.
It didn't need to of course, it could have been anything.
But we happened to pick that that prospecting agent and we packaged all of that up into an MCP server.
We added an MCP server trigger node, and then we just said, okay, this is MCP server.
And that means that anyone that has that URL can use This can can equip their Lem to use this tool as
part of their workflow and to try it out.
We picked something I picked clawed the the application.
It's anthropic's version of ChatGPT.
We use that, we connected it to our prospecting MCP server, and suddenly Claude was able to hunt for
leads for us using behind the scenes using Fire Crawl and Hunter.io.
Not that it knew that, but all of that was happening and I thought that was just a great end to end
example.
We were sharing tools through MCP, and as it happens, those tools themselves were using MCP servers
too.
They were using Fire Crawl and Hunter.io.
So we were using MCP at two levels, and I thought that was just a just a great end to end example,
and I hope it landed for you too.
And then one more thing to recap on is structured outputs that honestly, I think this is so important.
And they don't get enough air time and they should do structured outputs.
Of course it is this idea that you can say an LLM that normally just generates natural language, you
can constrain it.
So it has to generate JSON and that JSON needs to to fit to a particular structure called the schema.
And you do this in N by turning on that switch that says require specific output format.
And then you can give it a JSON example as I've given here.
And when the LLM generates output it will need to conform to that structure.
And it gives you this incredibly powerful way to put some kind of controls around what is otherwise
very free flowing text.
And you can use that in all sorts of ways.
And in N-r10, it's particularly useful because you can use it to decide what to do next, knowing that
you're going to get an output with a particular structure.
Now, here's an interesting and important point.
You will often find as you build workflows in N-r10, that there are actually two different ways that
you could achieve the same thing.
You could use tools, or alternatively, you could have your AI agent generate structured outputs and
then interpret that output and make some decision as a result.
And I think we did something a bit like that the first time we worked with Fire Crawl, we had that
being and we outputted JSON.
And then that went to some decisions that that called Fire Crawl.
And then later we used a tool.
And you'll often have those two different approaches.
And you may end up thinking, I wonder which one is better.
And you know, the answer is, of course, they have pros and cons, as with with many things.
But but I will tell you, in my opinion, structured outputs is often the one to choose.
It's the more boring answer tools is, the more the more trendy approach.
It's the one where you're giving the most autonomy to your model.
It's optional.
Whether it uses the tool or not, it can have multiple tools.
It can use any of them.
It can choose what order it uses a tool in.
It can call a tool multiple times.
So there's much more flexibility with tools.
But if you describe everything that you want Clearly in a JSON structure.
And then you take that JSON structure and you use that to drive whatever happens next.
That is a more kind of regimented, a more fixed way of doing things where you get to control how flexible
it is or how inflexible it is in a lot of detail.
And so I would describe the structured outputs alternative as the boring but bulletproof approach.
And what I've built these things in production I have to I have to come clean that I almost always use
the structured output style rather than too many tools, because you need something that is reliable.
I would prioritize bulletproof over being being fashionable, so it's something to leave you with.
You'll often find you have to make that decision, and you're wondering and you'll see what I mean about
it being boring.
You often have to do a bit more build work.
It's quite repetitive.
It's it reduces some of the magic of letting an AI agent choose its tools, but it gives you reliability
as a result of that.
And for me, that's the top priority.