Model Context Protocol with Dev Agrawal

Episode Description

Anthony and Dev explore MCP (Model Context Protocol), walking through its core concepts, a Node.js tutorial, and discussing its potential as the standard for connecting AI apps to data.

Episode Summary

Anthony Campolo and Dev Agrawal discuss MCP (Model Context Protocol), Anthropic's open protocol for standardizing how AI applications connect to LLMs and external data sources. After catching up on Dev's new consulting role at Xolvio, they set the stage by examining the MCP documentation, breaking down key terminology including hosts, clients, and servers, and drawing analogies to familiar web development concepts like GraphQL clients and REST APIs. They walk through Anthony's Node.js tutorial built with the MCP TypeScript SDK, covering how to define resources (data sources identified by URIs), prompts (reusable prompt templates for specific tasks), and tools (executable functions like adding numbers or calling APIs). Along the way, they debate context window strategies versus vector databases, discuss the growing adoption of AI tools among senior developers, and highlight projects like Open Control from the SST team as signs of the ecosystem maturing. Dev shares his vision for a personal AI assistant capable of asynchronous tool execution — queuing actions during meetings to update project boards and send emails — while Anthony previews his Ryan GPT project. They close by reflecting on why MCP matters beyond simple tool calling: it's designed for AI applications, not just models, making descriptions, resource management, and prompt engineering first-class concerns.

Chapters

00:00:00 - Stream Setup and Dev's New Job

Anthony and Dev get the stream running across both their channels after a brief technical hiccup with StreamYard. Dev shares that he recently started at Xolvio, a consulting company with a history of working closely with Apollo and the GraphQL ecosystem. He's excited about finally being on a team that practices event sourcing and domain-driven design, concepts he'd only been able to explore in side projects before.

The conversation touches on the company's background in GraphQL consulting and their connections to developer tool companies, though Dev notes his own work may not heavily involve GraphQL. Anthony gets briefly nerd-sniped looking up Xolvio's connection to Apollo's supergraph adoption efforts, setting a lighthearted tone for the rest of the stream.

00:04:41 - Introduction to MCP and Early Impressions

Anthony introduces the main topic — MCP (Model Context Protocol) — and recounts first encountering it when Anthropic announced it in November. He explains why he didn't adopt it for his own project AutoShow, having already built out a custom Node Fastify server, but recognizes its value as a standardized protocol for the broader ecosystem. Dev recalls watching an Anthropic workshop on MCP that gave him crucial context most Twitter commentators seem to miss.

They discuss how MCP is more than just standardized tool calling — it's designed for AI applications, not just AI models. Dev pushes back on critics who suggest REST APIs or hypermedia could serve the same purpose, arguing those approaches don't cover everything AI-driven applications need. They also note the growing wave of prominent developers like Kent C. Dodds and Dax from SST going all-in on MCP as a signal of its significance.

00:11:03 - AI Adoption Among Developers and Context Windows

The conversation shifts to the broader trend of senior web developers embracing AI tools. Anthony traces the shift from skepticism in 2023 to widespread adoption in early 2025, citing Theo's T3 Chat as a cultural turning point. Dev provides a reality check, noting that outside the Twitter bubble many developers at established companies still aren't using AI coding tools extensively.

They then explore context window strategies, debating the merits of shoving entire codebases into LLM context versus using vector databases. Anthony advocates for tools like Repomix and large context windows, especially on flat-rate plans, while Dev raises concerns about token costs and response speed. Both agree that growing context windows will make this approach viable for most projects, though enterprise-scale codebases will remain exceptions.

00:19:27 - MCP Architecture: Hosts, Clients, and Servers

Anthony shares his screen to walk through the MCP documentation on modelcontextprotocol.io, starting with the USB-C analogy for how MCP standardizes connections between AI apps and data sources. They work through the architecture of MCP hosts, clients, and servers, with Dev clarifying the distinction: hosts are consumer applications like Claude Desktop, clients are the objects maintaining one-to-one connections with servers, and servers expose the actual tools and resources.

Dev draws a helpful parallel to GraphQL — facebook.com is the host, the GraphQL client is embedded within it, and it talks to a GraphQL server. They also discuss how MCP servers can themselves be clients to other servers, creating orchestration patterns similar to microservices. The section closes with a look at the TypeScript SDK that Anthony uses for his tutorial.

00:24:14 - Resources, Prompts, and Tools Explained

Anthony walks through MCP's three core primitives. Resources are data sources identified by URIs — files, databases, APIs, images — that give applications explicit visibility into what context is available. Dev emphasizes that resources are what distinguish MCP from simple tool calling, enabling client applications to show users exactly what data is in context rather than burying it in scrollable prompts.

They then cover prompts as reusable templates that encode specific workflows, comparing them to how AutoShow already structures prompts with instructions and examples. Dev frames prompts as a halfway step toward AI agents, providing curated prompt engineering so users don't have to figure out optimal prompting themselves. Tools round out the trio as executable functions — from simple addition to weather API calls — with schemas defined using JSON Schema and Zod validation.

00:31:23 - Open Control and the MCP Ecosystem

Dev highlights Open Control, the SST team's open-source project, as the closest existing implementation to what he wants to build. He reveals that he opened feature request issues on the repo representing his ideal additions, and that he's been in regular conversation with Dax about MCP. Anthony notes Open Control's architecture — an MCP server connecting to databases and APIs with models hitting a generate endpoint — as exactly the kind of template he wished he'd found for the stream.

The discussion frames Open Control alongside other ecosystem signals like Theo's T3 Chat and Kent C. Dodds' pivot as evidence that the open-source community is rapidly consolidating around MCP. They also briefly discuss the evolving landscape of MCP learning resources and how tools like Open Control will smooth out the rough developer experience of working with raw MCP servers.

00:35:38 - Walking Through the MCP Tutorial Code

Anthony opens the actual tutorial code, starting with the package.json dependencies — the MCP SDK, OpenAI, and TypeScript tooling. They walk through defining resources (a static hello-world resource and a dynamic echo resource with URI templates), listing resources, and creating a prompt that accepts a question parameter. Dev explains why one resource doesn't appear in the list — the template-based resource needs an explicit list function.

They encounter real rough edges: broken features from outdated docs, logging that doesn't work, and the need to paste raw JSON into the terminal to interact with the server. Both acknowledge this is bleeding-edge territory, with Dev noting that the TypeScript types were essential for figuring out undocumented APIs. Anthony shows the tool definition for adding two numbers with a full JSON Schema, and they discuss how JSON-RPC 2.0 underpins all MCP communication.

00:55:53 - Connecting an LLM and Reflecting on the Tutorial

Anthony demonstrates step five of the tutorial — wiring up the OpenAI completion API to the MCP server. He shows the familiar pattern of system and user prompts, noting how the completion API has been effectively standardized across providers like Grok, Mistral, and others. They briefly discuss OpenAI's adoption of MCP support and the competitive dynamics between OpenAI and Anthropic, including OpenAI's new Codex coding agent.

Dev then delivers an extended reflection on what separates a good MCP server from a basic one. He argues that descriptions become a core interface rather than documentation afterthought, and that tools must encode workflows rather than mirror REST endpoints one-to-one. He suggests future tutorials should involve defining tools and immediately testing whether an AI can discover and call them from natural language prompts — iterating on descriptions until the AI reliably understands when and how to use each tool.

01:10:12 - GraphQL, AI Assistants, and Future Plans

The pair discuss GraphQL's potential role in the MCP ecosystem, noting that while structured nested data could benefit from GraphQL queries, MCP resources span many formats beyond JSON. Dev then shares his vision for a personal AI assistant that connects to email, Slack, Notion, journals, and more, with a key innovation being asynchronous tool execution — queuing actions collaboratively with the AI rather than executing them one at a time synchronously, particularly useful as a meeting assistant that updates project boards in real time.

They wrap up discussing open-source strategy in the fast-moving AI ecosystem, with Dev arguing that productizing AI tools is nearly futile when projects like Open Control can appear and democratize the same ideas within months. Anthony previews his Ryan GPT project and a code review agent he built, and they plan future streams covering Open Control, deeper MCP exploration, and potentially getting Dax or Ryan Carniato on as guests.

Transcript

00:00:03 - Anthony Campolo

Well, welcome back to AJC and the Web Devs. I jumped the gun and hit stream right when Dev dropped off for some reason, but he'll be back any second now.

We're talking about MCP today, and Dev is coming online right now. I will probably say MPC a lot, but MCP is the correct thing. Sorry, I hit literally go live right when you were like, wait.

00:00:34 - Dev Agrawal

Yeah, it bugs me every time. Every time I hit login on StreamYard, it just immediately kicks me out with no warning at all.

00:00:43 - Anthony Campolo

That's funny.

00:00:44 - Dev Agrawal

At the very least, I would expect you to open a login pop-up instead of throwing out everything I was doing.

00:00:50 - Anthony Campolo

Anyways, yeah, stream from your channel as well. I don't know if we can do that now. We've already gone live.

00:00:57 - Dev Agrawal

Yeah, that's why I was logging in. That's what I'm setting up right now.

00:01:03 - Anthony Campolo

Okay, cool. Hang tight, people. If you aren't able to do it, just hang tight. Oh, it looks like you're able to.

00:01:08 - Dev Agrawal

All right. We're good.

00:01:09 - Anthony Campolo

Do it. Let me check your YouTube real quick to see if it's going. So, how you been, man? How's the new job treating you?

00:01:19 - Dev Agrawal

It's pretty good. I'm liking the new job. It's only been two days, but it's an exciting move.

It's the first time that I'm getting to work with a team that really understands things like event sourcing and domain-driven design. That's probably what I'm excited about the most. These are things I've always wanted to bring into my projects, but I've only had that kind of leadership or autonomy in my side projects, not my work projects. It's really hard to get buy-in on things people don't fully understand.

00:02:01 - Anthony Campolo

Yeah. Can you tell me how it's pronounced?

00:02:04 - Dev Agrawal

Xolvio.

00:02:06 - Anthony Campolo

Okay, so it's like a Z, but it's spelled with an X.

00:02:09 - Dev Agrawal

Yeah.

00:02:11 - Anthony Campolo

Yes. And this is "Deliver APIs That Matter."

00:02:16 - Dev Agrawal

Yeah, I don't know if their website is actually fully up to date or fully represents what they do. I was brought in to work on a very specific project, so I actually haven't learned too much about the entire company and what everyone does.

So far, my exposure is just that this is a team that works really closely. They have worked in the past with the Apollo team and even the StoreDB team, so they directly get clients from these dev tool companies as well. That's kind of their history — doing a lot of GraphQL and now event sourcing. The GraphQL super API thing, I haven't really heard too much about that since I've joined.

[00:03:14] That's a little disconnected from what I do. It's just a consulting company in general. It's very similar to my last place.

00:03:23 - Anthony Campolo

Okay. Very cool. Is that supergraph? Is that what you're talking about?

00:03:30 - Dev Agrawal

No, I'm talking about Xolvio the company. It's just a consulting company. The supergraph stuff, I honestly don't know much about that.

00:03:39 - Anthony Campolo

Okay. Honestly, because you said super API, but I think you meant supergraph. Maybe I'm wrong.

00:03:45 - Dev Agrawal

API.

00:03:46 - Anthony Campolo

I'm just googling around, so it's not super important, but I always get nerd-sniped by GraphQL. It looks like it says "How Xolvio drives supergraph adoption" — this is an Apollo blog post. So yeah, this is what you're talking about.

Looks like we got some people in the stream. What's up, guys? Thanks for joining. Here's a link for people who are curious. That's cool that you're doing work with Apollo. You know, I did.

00:04:19 - Dev Agrawal

Yeah. I'm not working with Apollo. I mean, the company is — I'm honestly just trying to see if we can avoid GraphQL, but if that ends up not being the case, then no problems. I guess we are going to need it.

00:04:31 - Anthony Campolo

I meant the company, not you. Yeah.

00:04:35 - Dev Agrawal

Yeah, yeah. The company has a history of working with GraphQL and Apollo for sure.

00:04:41 - Anthony Campolo

Awesome. I'm excited to hear how that goes as you get more spun up and more into it. Today we're talking about MCP. I was joking with Dev — I'll probably accidentally say MPC a bunch because it sounds like NPC, so I can remember it's like ICP, Insane Clown Posse.

00:05:06 - Dev Agrawal

Yes, that's a good reference point.

00:05:09 - Anthony Campolo

Yeah. Also, last time you were on, we were talking about you. You had that secret AI project at your old company, so it sounds like you probably moved on from that entirely now.

00:05:20 - Dev Agrawal

Yeah. Now it's more of a personal ambition to build that thing as a side project.

00:05:25 - Anthony Campolo

Okay.

00:05:26 - Dev Agrawal

So now I guess it doesn't have to be secret anymore.

00:05:30 - Anthony Campolo

Oh, great. I don't know if you want to talk about too much, but I only bring that up because you had mentioned seeing MCP and being like, oh, this could be cool for this project that I'm building.

I had first seen MCP back when it was announced. It's really new — it was only announced back in last November, so it hasn't even been six months. I'm building my own AI thing, AutoShow, and I was like, okay, this is kind of cool. It's like a pluggable way to connect LLMs to all this different crap — different tools, different resources, data sources. But I'd already spent, at that point, six months — now at this point like a year — building out basically my own Node/Fastify server that does all those connections. So I would have had to rip all that out and start from scratch to adopt MCP.

[00:06:19] And then I built this tutorial. I am very glad that I did not try and do that because I definitely made the right decision. But I see how it's incredibly useful as a protocol because it's something that's standardized that anyone can kind of plug into.

So what's been your take, just kind of seeing it out in the Twitter hype sphere and everyone talking about it?

00:06:42 - Dev Agrawal

Yeah. First of all, I think the first time I got introduced to MCP was around the same time that Swyx's AI Engineer YouTube channel published a workshop that some guy from Anthropic did.

00:07:04 - Anthony Campolo

Right.

00:07:06 - Dev Agrawal

Yeah. You shared that with me, of course.

00:07:08 - Anthony Campolo

Yeah.

00:07:09 - Dev Agrawal

That was right after I found what MCP was. Watching that entire workshop gave me a lot of context that, if I missed it, I wouldn't have gotten the entire point of MCP. I feel like a lot of people that talk about MCP don't really get the full context of why it exists, where it came from.

00:07:29 - Anthony Campolo

People on Twitter are talking out of their ass about new tech.

00:07:34 - Dev Agrawal

I know, right? It really shows that this was designed after a long period of collaboration between all the different people who are trying to build AI applications or AI agents, and really trying to find the core primitives that drive everything.

So, there's a lot of people that are just saying, just use a REST API or just use hypermedia and what else. I don't think any of them quite fulfill everything that AI-driven applications really need. The other thing is that people focus a lot on tools, which makes sense because that's kind of the core way you expose things to a model. But MCP is a little more than that. It's not just a server for a model to use. It's a server for an AI application to use, not an AI model.

[00:08:37] And that already makes it more than what you have. You actually need to start building an AI application with a specific use case to really see the utility of every different part of MCP, and not just a way to standardize tool calling, which is how most people are treating it. But yeah, it's something I've been super interested in.

The thing I'm trying to build on the side is fully aligned with, or has to be built on top of, something like MCP. We can get into detail about that later, but I definitely want to talk about that as well.

00:09:23 - Anthony Campolo

Cool. I see where people are coming from when they say that, like, why not just build a REST API? Because, like I said, that's kind of what I did for AutoShow, but they're just thinking in their own specific narrow use case. This is trying to solve a problem for the entire ecosystem, which is a very different thing.

It's more about trying to give us HTTP for LLMs, something that we can all use and build a massive ecosystem around, which I think is cool. I'm still not sure how useful it will be to me individually as a programmer, but I'm open to getting deeper and deeper into it. We'll probably, if we want, do a whole part two on this, because where we get to in my tutorials is barely the absolute basics.

00:10:13 - Dev Agrawal

Yeah, yeah. It's also really nice seeing people like Dax and the SST team and Kent C. Dodds and David Cramer kind of go all in on MCP and spend a bunch of time upgrading their own things. Kent has just completely transitioned over — like, hey, websites and web applications are not going to be needed anymore, everything is going to be an MCP server.

It's the position that I really wanted to take two months ago, but I was too scared to. Now I'm seeing someone as big as Kent C. Dodds go fully in that direction, and it's really interesting to see.

00:10:49 - Anthony Campolo

Yeah, I've been seeing Kent tweeting about it as well. He was way in the weeds with OAuth flows and all this kind of stuff. And I'm just like, go, go.

00:11:00 - Dev Agrawal

You know, literally it reminds me of Swyx two years ago.

00:11:03 - Anthony Campolo

Yeah, totally. Honestly, over just the last year, this kind of slow progression of watching the web community fully embrace AI. I feel like, especially like Theo building T3 Chat, that was pretty big for a lot of people to be like, okay. People who obviously are senior devs and can code themselves are finding a lot of use out of LLMs.

The original conversation was like, oh, they hallucinate. They're trained on stale data. They only give you broken, crappy code. There's no reason a senior dev would ever use this. That was overwhelmingly the conversation throughout all of 2023. I was already vibe coding all throughout that entire time, and I'm like, you guys are tripping. This is great.

Then 2024, more people started picking it up. I feel now that we're in Q1 and Q2 of 2025, the tide is totally shifted. Most legit senior devs now are saying, regardless of what drawbacks these LLMs have, you'd be stupid not to try and adopt it in some respect for some part of your workflow.

00:12:17 - Dev Agrawal

Yeah, and I would tend to agree with that. But then I joined this company, Xolvio, and they have a lot of AI stuff on their website as well. So I joined thinking, okay, these guys are already all bought in on AI.

Then I start talking about how I use Cursor, and they're like, yeah, I tried using Copilot a little bit here and there — it didn't quite work, so I'm not spending too much time there. So from the Twitter sphere, it does feel like a lot of people who know what they're doing are switching to a lot of these AI tools, but that's still within the Twitter sphere, it feels like.

00:12:57 - Anthony Campolo

Yeah.

00:12:57 - Dev Agrawal

Yeah.

00:12:57 - Anthony Campolo

I should caveat that. It's still the type of people who are into new tech and who would have been the type of people trying out new frameworks back in the day. You're totally right about that. You go to any enterprise company, and I'm sure very few people are using it. There's all sorts of red tape and crap like that.

00:13:15 - Dev Agrawal

Yeah. That's a big advantage.

00:13:19 - Anthony Campolo

Yeah. It shows that we're still early. Cool, cool. What's up? Looks like all of these people are coming in from your stream. Sweet. Let's get some screen sharing going.

I'm going to try and keep the chat open here. Well, I got this guy. So first thing I want to do is, so we can all kind of be on the same page, I just want to step through a bit of the docs and read some of their definitions for it. We kind of set our own context here. I think this will be useful for people as well.

So this is modelcontextprotocol.io, and it says here MCP is an open protocol that standardizes how applications provide context to LLMs. I find that pretty interesting. You know, those are the two key words: model and context. Most people know what a model is. Context can be a bit of a squishier word. Because when I think of context, I think of what is the conversation you have already had with the LLM or what are you putting in, like, your first message that you give to it?

[00:14:32] I had my buddy Eric Michaud on a previous episode, and he confirmed to me that the term "in-context learning" is correct, the way I've been using it. You can just slap a huge message to it right at the beginning — that kind of preloads things like docs and examples.

Something I have been getting a ton of mileage out of is this thing called Repomix, which will take your project and kind of shove it into a single file that you can use in context. When people use the term "llms.txt," they're kind of talking about something that's also giving links so it can reach out to the internet to understand different things. This is more of what I think an llms.txt should be — it's just a single file that you copy-paste into your chat. So that's kind of what I think of when I think of context.

00:15:26 - Dev Agrawal

I'm curious to hear your thoughts on this approach of llms.txt. It doesn't seem like something that would scale with a bunch of docs or a large codebase. Even if you could fit it in the context, it would just make the responses really, really slow, wouldn't it?

00:15:46 - Anthony Campolo

It really depends. Like you said, a very big factor is how big your docs are. How big is your project? I kind of hit a point with AutoShow where I was starting to have trouble fitting the whole codebase in context, and I've now decoupled the CLI from the server and the web. So I can develop each of them individually, and as they grow, eventually I'll have to figure out another solution for that.

But it's a pretty large project at this point, a pretty decent sized codebase. Another thing to think about is that the context window continues to get bigger. When GPT-3.5 first came out, you could fit like 4,000 tokens or something, which was totally ridiculous. Gemini in particular gets up to the hundreds of thousands of tokens. So I have definitely leaned very heavily into this approach and very heavily away from things like vector databases.

I think if you're working with something like Ryan GPT, where I have like 500 hours of transcripts, obviously that's essentially the context. So there's definitely a threshold you'll hit where this will stop making sense at a certain point. But what I like about Repomix is that you can configure it so you cut out your test files and your config files and all this stuff that's kind of tokens that you don't really need. If you just keep it to your src and your main logic, then you can get pretty far with that.

So I'm of the opinion that as context windows get larger and larger and larger, there will be very few codebases that aren't going to be able to work in this approach. And those will be things like if you're working at a company like GitHub, like obviously GitHub's whole codebase has to be millions of lines of code, or Google's codebase. Google had to build their own specific tooling so that people could work with it. But I think your average dev building their own stuff, you can get pretty far with this approach.

00:17:53 - Dev Agrawal

Yeah, that's an interesting point. I fully agree that for a lot of the smaller projects that I work on, it's completely fine to shove it all in the context. But I feel like, yeah, I do agree that context windows are going to get bigger. But I feel like maybe the cost of that many tokens and how slow the, I guess not even the slow AI responses, but mostly the cost of passing that much token context back and forth, versus the cost of just running a vector search. I don't know. It's going to be interesting to see how this pans out.

00:18:31 - Anthony Campolo

Yeah, that's true. If you're someone who's paying by the token or you're using an API or you're hooking into something like Cursor, this is one of the reasons why I like my approach, because I'm on the $200 plan with ChatGPT and you're not paid by the token and you have essentially unlimited tokens that you can use. So that's not really an issue for me the way I'm doing it.

If you can afford the $200 a month, you're not really going to hit that limitation. But you're right that for a lot of people, the input cost can get prohibitive at a certain point. Input tokens are much cheaper than output tokens, so there is some wiggle room there. But depending on your own setup and how you're financing your LLM use, that can be an issue, definitely.

00:19:17 - Dev Agrawal

Mm-hm. Okay, a long discussion on long context windows. Let's move. What else is here?

00:19:27 - Anthony Campolo

Yeah, it's saying that MCP is like a USB-C port for an AI application. Everyone used to have a computer with like eight different plugs for all this different stuff, and now a lot of things are being standardized to a single plug. A lot of people had to be dragged kicking and screaming to that world, but I think a lot of us probably like it better. At least I do. I like having fewer cables.

00:19:52 - Dev Agrawal

Yeah, I think that's a really good analogy.

00:19:54 - Anthony Campolo

Yeah, yeah. Okay, so this is important. There are MCP hosts, clients, and servers. The tutorial we're doing today is entirely an MCP server built with Node.js, so we're not going to deal with clients at all. And I think you asked me about desktop right before we started. I'm assuming you're referring to the MCP hosts.

00:20:19 - Dev Agrawal

Okay. I don't think I ever got to this part. I'm curious: what's the difference between a host and a client? Clients maintain a one-to-one connection to the server. Okay, so a host has a bunch of different clients — but a host is the complete application, like Claude Desktop or Cursor. Yeah. I'm spending a lot of my time thinking about the hosts and not as much about servers, because that's the part where I feel like there is so much untapped potential. But today I think it's a good idea to focus on the server just to get a shared understanding of what MCP even is.

00:21:02 - Anthony Campolo

Yeah. This is why I think if we end up wanting to do more, a multi-part series would be cool. I haven't dived into the host at all yet, but the way I'm thinking of it is: hosts are like Electron apps, clients are React apps, and servers are Node apps in JavaScript terminology.

00:21:20 - Dev Agrawal

I think it's more like the host can be either an Electron app or a React app, and the client is the JavaScript class or object that talks to a single MCP server. That's what I'm getting from the spec: protocol clients maintain a one-to-one connection with servers. And obviously an MCP host can talk to a bunch of different servers. So for every MCP server, you have one MCP client, and that client is embedded inside a host.

00:21:55 - Anthony Campolo

You're probably right. I don't entirely understand what you're saying, but you're almost definitely right. I'm probably wrong, so this is something I'll have to learn more about.

00:22:05 - Dev Agrawal

You can think of it as a GraphQL server, a GraphQL client, and then a GraphQL application. So facebook.com is a host, but it's embedding a GraphQL client that talks to a GraphQL server.

00:22:21 - Anthony Campolo

Okay.

00:22:22 - Dev Agrawal

If that makes sense.

00:22:24 - Anthony Campolo

It doesn't. Theory? Yeah.

00:22:28 - Dev Agrawal

It's confusing terminology. We can forget about hosts. I think that should make the discussion easier and just go with the client and a server.

00:22:37 - Anthony Campolo

Yeah, totally.

00:22:38 - Dev Agrawal

I think the reason they make this distinction is because an MCP server can also be an MCP client itself. You can take a bunch of different MCP servers, write some code that talks to all of them, and expose your logic as an MCP server itself — kind of like an orchestrator. If you think about microservices, they have patterns like this. I think that's the reason they make the distinction: clients can be anywhere, but hosts are like consumer apps. For our purposes, we don't have to worry about that distinction. Let's just go with an MCP server and an MCP client app like Claude Desktop.

00:23:20 - Anthony Campolo

Yeah. And someone's saying here: my Node server can make requests. Exactly, yes. So that's like your client being kind of embedded in your server.

00:23:28 - Dev Agrawal

Yes. So the thing that's making the fetch request is the client, and the entire application is the host.

00:23:35 - Anthony Campolo

Okay, cool. That's great. Last link and then we'll get into the code. This is the TypeScript SDK, and this is what I'm using to build up the tutorial. It's got a little quick start here. We'll be building something fairly similar to this example we see here, but it's going to go step by step and build up each piece.

The more important terminology, actually, I do want to go back here, and we should talk about the difference between resources and prompts for you guys. Say something.

00:24:13 - Dev Agrawal

Now go ahead.

00:24:14 - Anthony Campolo

Yeah. So these are kind of the two, and then tools also. But tools is something that, if you've been using things like tool calling and things like the Vercel AI SDK or even just the OpenAI SDK, that's a more easy term to understand.

The resource is not complicated, but more involved because it includes a whole bunch of stuff. This is things like your file system, a database, your APIs, screenshots or images, log files. So this is the stuff that makes it very internet, very web, because it's similar. You look at this, this is almost like an HTTP or HTTPS link. You got your protocol, host, and path. So this is pretty cool. This is fairly intuitive to me when I was first learning this.

00:25:12 - Dev Agrawal

Yeah. I think added resources is where the distinction between MCP being for AI models versus MCP being for AI applications really shines, because obviously a model can use a tool to fetch data and put it in its context, but that doesn't help us using Cursor or using Claude Desktop to really figure out what the different pieces of data are that are in the context right now. We can see the data in the prompt, but that's kind of about it. Whatever data is fetched by the model is going to be in the prompt, and we have to scroll to see what data was used here. Maybe it doesn't show, and there's no standardized kind of representation of that.

So I think resources are really important for the application that you're using, like the client or the host, whatever you want to call it. It's very important for that application to show, okay, here are these.

[00:26:13] Ah, here. Here's the exact data that we are using right now. So instead of that being through the prompt that you have to scroll to see, you can exactly see these are the resources. This is the URL for each resource. And this is what's included in the context right now. And that also means you can control it yourself, or you can attach resources, you can remove resources, or the model can automatically figure out what resources to attach. At least this is the way that I've been thinking about resources and how they differentiate from just tools fetching data.

00:26:47 - Anthony Campolo

Okay, cool. Yeah, it's showing an example here. There's a direct resource service exposed list of concrete resources via the resource list. This is one of the first things we'll do in the tutorial is run this, and you have your unique identifier for that resource URI, similar to a URL. URI is, I think, a more general term than URL.

And then you have name, description, and MIME type. So that is all pretty standard stuff. And then prompts is just like people would expect: a prompt is what you're sending to the LLM itself. Accepts dynamic arguments, include context from resources, chain multiple interactions, guide specific workflows. So your service has UI elements like slash commands. So have you used Claude Code at all?

00:27:50 - Dev Agrawal

I have not.

00:27:52 - Anthony Campolo

Yeah. So I used it once. It was cool. It didn't quite fit my workflow for what I was trying to do, but it seems pretty legit. I would recommend at least giving it a try. They use slash commands. I'm assuming that's because Anthropic created MCP originally, and Anthropic are the creators of Claude. So I'm assuming Claude Code is the killer app for MCP, at least from Anthropic's point of view. I could be totally wrong.

00:28:24 - Dev Agrawal

Claude Desktop is supposed to be the one. But yeah, Claude Code is the more developer-oriented version of that. From their perspective, Claude Desktop is supposed to be their flagship MCP client.

00:28:40 - Anthony Campolo

Interesting. So Claude Desktop is just the Claude AI running in a desktop app, because that's what desktop is basically.

00:28:49 - Dev Agrawal

Yeah. But because it runs on your desktop, it can talk to MCP servers that you have running locally. We are still probably a few months away from remote MCP servers being super mainstream, at which point we don't have to worry about these desktop apps being the only way to use MCP.

00:29:12 - Anthony Campolo

Yeah, I tried ChatGPT desktop when it first came out, which I think was about a year ago now, and it didn't seem like it was any different than just using the web app. It was like using the Discord app versus just running Discord in your browser. That may have changed now, but the idea that Claude Desktop is actually connected to your local file system like that makes a lot of sense and would be very useful.

00:29:35 - Dev Agrawal

Exactly. Yeah.

00:29:37 - Anthony Campolo

I do custom YouTubes... Yeah, I don't know, man. Thanks for joining, but not really interested. Hey, we can...

00:29:47 - Dev Agrawal

We can do it. GPT has gotten really good at custom art these days.

00:29:52 - Anthony Campolo

Yeah. And the new one, because I used to have a lot of trouble creating thumbnails with the old image model, but it can definitely do some pretty realistic ones now, because the tech can actually spell words now, which was kind of a problem in the past.

00:30:10 - Dev Agrawal

Yeah, it's really funny. We did an entire stream on AI image gen, and then a couple of weeks later, ChatGPT just changed the entire game.

00:30:19 - Anthony Campolo

I mean, they didn't. Now that it's available for the API, which just came out today, everything we did, you just gotta switch out the model name. So we're totally good to go.

And someone was asking in the chat about Open Control. We mentioned Dax and SST. I haven't tried this out yet, but I think everything they do is highly legit and intrinsically worth checking out. So I would recommend people, if they're interested in this kind of stuff, to look at this project.

We see here they're set up with an MCP server in the middle that connects to your database and your API. Then they've got your models connected to a generate endpoint — this seems pretty sweet. Honestly, I should have looked at this for the stream because I couldn't find a really good MCP template to use, but this is exactly what I want. It's just using a Hono server and stuff, which is really nice.

00:31:23 - Dev Agrawal

Yeah. So Open Control is probably the closest thing to what I'm hoping to build — even to the point where if you scroll up to the issues tab, I basically took all the ideas that I had in my head that I wanted to implement, and I opened them as issues here. So literally, these are the four things that, if added to Open Control, that's basically what I wanted to build. That's literally all that I have in my head. This is my ideal AI tool: Open Control plus these features.

00:31:58 - Anthony Campolo

And I just find it funny — these are all by default assigned to Dax, so Dax has to read all your issues.

00:32:04 - Dev Agrawal

Yeah, that was Jay. It looks like he opened them last week. But yeah, Jay assigned them to Dax a couple days ago.

00:32:11 - Anthony Campolo

Awesome. Very cool. This is great stuff. I should see if I can get Dax on stream to talk about this. That would be great.

00:32:21 - Dev Agrawal

Yeah, I've been chatting with Dax a lot about MCP and all the stuff for the last couple of months — basically since they launched Open Control, because that was another moment, like Theo releasing T3 Chat. It's a community of senior open-source people who are suddenly now fully bought into AI.

00:32:49 - Anthony Campolo

Yeah, definitely. It's social proof, you know.

00:32:53 - Dev Agrawal

Mhm.

00:32:56 - Anthony Campolo

Okay. We have some tabs here. Okay. I think that's probably enough throat clearing, as they say. We can get into the actual thing here. So I can just open this all the way. I'm going to start by showing the projects. We don't have to necessarily step through the tutorial exactly, but the first step is... actually, first, let me just do the package.json.

So our dependencies here: we have the Model Context Protocol SDK and OpenAI, and then your TypeScript tooling.

00:33:44 - Dev Agrawal

Typical.

00:33:45 - Anthony Campolo

At some point I'm using Zod, which I'm not sure why is actually working even though I haven't imported it. So that's weird. But this whole thing works. So strange.

00:33:56 - Dev Agrawal

It's possible the MCP SDK depends on Zod, so it's in there by default.

00:34:02 - Anthony Campolo

Yeah, that would make a lot of sense because I basically just created this by dropping in the readme.

00:34:08 - Dev Agrawal

Oh yeah. OpenAI depends on Zod. I was just going to say that.

00:34:12 - Anthony Campolo

Yeah, that's true, but that doesn't answer the question, because the first iteration of this did not have the OpenAI SDK.

00:34:19 - Dev Agrawal

Okay.

00:34:20 - Anthony Campolo

So I think you're more correct. That applies more to MCP because the OpenAI thing only comes in at step five; it's not using it before. But this is not super important.

00:34:34 - Dev Agrawal

So it's fine. Half of the ecosystem depends on Zod these days.

00:34:38 - Anthony Campolo

So, a lot of the stuff here is kind of stuff we already talked about. So we can skip the intro to the tutorial. After I went through all this, I realized I didn't quite do it in the right order, because it doesn't actually build a server until step four, and it uses the Express app. And this part we're not actually going to get to in the tutorial at all.

So what I would like to do is kind of rework this and have step one give you an endpoint, because the way it's actually set up is — let me show this. When you actually run the server for this first one, it literally just hangs, and then you throw JSON directly into it to get responses, which is obviously a terrible dev experience. So I actually want to have it give you an endpoint that you can curl.

[00:35:38] But that's just for time constraints. I wasn't able to get there. So I just wanted to show here: you start the server and you hit it. This is step one. This is not even using resources or prompts. This is literally just how you can run the server, period. I'm going to step through the actual tutorial code from here, because the JSON will be formatted a little nicer.

00:36:05 - Dev Agrawal

But I think tutorials on top of MCP — or learning resources — something like Open Control has a lot of potential there. Because first, they set up all the infrastructure needed to run the MCP server over HTTP. And second, they have an embedded client. So once you start running your server, it also opens a mini AI chat app that you can use to talk to the tools you have defined, which really takes away a lot. You don't have to paste JSON into the terminal to talk to it — you actually use prompts.

So yeah, I think the learning resources around MCP and the tutorials are going to evolve a lot thanks to things like Open Control. But that's for the future.

00:37:02 - Anthony Campolo

Yeah. Very cool. This is one of those things — we're on the bleeding edge right now. That's why we're showing really what is happening at the model context layer. And as these actually get more server-y, then we'll get more of the niceties that we expect from a JavaScript server.

00:37:21 - Dev Agrawal

Exactly. So these are details that most people will not have to worry about in the near future, but it's helpful from a technical perspective to know what's going on.

00:37:34 - Anthony Campolo

Yeah. So Open Control is going to be like the next step — the MCP reactor, or whatever analogy you want to use. I don't hate that analogy.

Okay, cool. So this was what we actually sent to it. This is JSON-RPC. You have an initialize method and you're just kind of saying, hey, here's the thing. And the response back is just saying, hey, here's the thing. You have a server, here's the version, no other information whatsoever.

So what you really want is some resources and some prompts. So now we do: once you initialize the server, you set server.resource. And then this is creating our Hello World resource, creating a URI here. So this is what we're looking at. Before we were saying this is kind of like a URL. And all it's going to do is just return the text "Hello from your MCP resource."

[00:38:44] So someone's asking, please explain what this is about. Yeah, so we're explaining MCP. We just did a whole half-hour explanation of what that is, so we're not going to do all of that again. But you're welcome to check out the recording once it's up.

00:39:01 - Dev Agrawal

Yeah. And you're welcome to put any specific questions that you have as well, and we'll try to answer those.

00:39:08 - Anthony Campolo

Cool. So we're defining two resources here. The first is just going to give you back this text, a static kind of answer. And then the second one is more like feeding in a parameter. So you can give it a message. You want to say, echo some message, and then it's going to give it back to you. So this is nice.

00:39:30 - Dev Agrawal

It's literally like routing.

00:39:32 - Anthony Campolo

Yeah, exactly. So this is like creating your routes. That's pretty sweet because anyone who's worked with Node.js servers, all this code should be pretty comprehensible and pretty simple. You see here, if you echo test, then you'll get back the word test.

And then lastly is the prompt. So this is going to have us accept a question that could be fed to an LLM. So it says, could you answer this question for me, and then it gives it the question that you're giving it. And it's named ask question. So this here is just explaining kind of what we just explained there.

And then a couple of things you can do: you can list your resources here. Now I'm not sure why this is happening; it's only listing one of the two resources I defined, so I need to figure out why that is. But both resources do actually work. So when you do resources list, you may also see that it's only listing one. I'm still figuring out why exactly that is.

[00:40:39] But then you can also list resources.

00:40:40 - Dev Agrawal

I think it's because the resource that you have with the template — like with the dynamic parameter that you put in — it needs... Oh yeah, you see, it has the list undefined. So the list undefined tells the server that it doesn't have a way to list the echo resources. This is where you pass in another hook, another function that returns a list of the resources you want to show the model.

00:41:09 - Anthony Campolo

Okay, I see. The template thing, I hadn't even seen until we were just looking through this. So the URI template.

00:41:19 - Dev Agrawal

That's not it. That's just the template standard. It should be, if you look for list in this. It's definitely in here somewhere because I've implemented listing a resource template. Let me look for that as well.

00:41:42 - Anthony Campolo

Here: a list of available resources. To develop some skills. So I am at the right place.

00:41:53 - Dev Agrawal

Oh, it's on the GitHub.

00:41:57 - Anthony Campolo

The GitHub.

00:43:44 - Dev Agrawal

Noticed.

00:43:47 - Dev Agrawal

There are some breaking changes.

00:43:49 - Anthony Campolo

Also, when I originally had it vibe-code this first tutorial, the first requests were broken because they used an old feature. I'm assuming it pulled that from the docs, but maybe not.

00:44:01 - Dev Agrawal

Exactly. And list undefined, if I remember running into this. It's a good thing it's TypeScript, because I could figure out from the type signature what this should look like, and because there's no documentation for it.

00:44:19 - Anthony Campolo

I had issues getting logging to work as well. This is super early here. So anyone who's like, oh, MCP is already a hype thing and it's too late, it's like, this is so early. If you want to become an MCP expert, you are well within the first 1% of devs who will know anything about this.

So now this is our prompt. I asked, and this is funny. I didn't write this, but what is the airspeed velocity of an unladen swallow? I'm curious, was this from the original docs? No, it was not. ChatGPT just felt the need to write that. That's funny.

And then we see here in the text, could you answer this question? Line breaks. What's the airspeed velocity of an unladen swallow? Cool. So now we still have our resources and our prompts, but now we have a tool.

00:45:15 - Dev Agrawal

Before we go to tools — what do you think about prompts as part of the server? That's probably the one thing that REST and GraphQL, the things that people say we should use instead, don't have a concept of. So what are your thoughts around that? What are prompts, and why are they important?

00:45:41 - Anthony Campolo

I think it makes sense to make it its own primitive. The reason why prompts don't exist in the HTTP world when people are just working with APIs is because, for the most part, you had to learn the difference between a system prompt and a user prompt. Then you have to construct your code in a way where your prompt would be essentially the text that the endpoint receives, and then it inserts that into your prompt.

You could also build all this kind of logic around dynamic prompts that accept different parameters and things like that. It made sense not to have a primitive around it in that respect, because it already is what you were building everything around. That is how you're interacting with the AI as you send it prompts and you get responses back.

So now that we're in this world where we have other stuff, where we have things like resources and tools, it doesn't make any sense to just also have prompts in the mix, but it just being something where you have to figure out how your prompt is going to get into the context and interact with the tools and the resources.

[00:46:55] So to me, it makes sense why it's a primitive for that reason.

00:47:01 - Dev Agrawal

Yeah, for sure. I feel like I think of it almost as a halfway step towards AI agents — not that AI agents are going to replace it, but it's more like how agents are designed to be single-purpose. They have a very specific functionality, and they're prompt-engineered in a very specific way to achieve that task.

I feel like that's kind of the role that these prompts are supposed to fill. If there's some complicated task, I don't want to have to figure out what's the best prompt I can give the AI to achieve it. So instead, there's a library of prompts that I can use that either understand the task very well, or they understand the data — like the resources or the tools available to achieve the task — or some combination of both.

So, for example, if I was writing an email client for Gmail or Outlook, I would have a bunch of prompts specifically around handling emails: looking through email chains to find some information, coming up with a professional follow-up or a reply.

[00:48:10] These are things that I would just put as detailed prompts, and then the user doesn't have to figure out how to exactly prompt the AI to achieve that certain task.

00:48:23 - Anthony Campolo

No, I totally agree. And this is exactly how I built AutoShow — I built all of these prompts, and I even separate each prompt into two different things: an instruction and an example. And then I have what I want: titles, a summary, chapters. So yeah, I totally agree with you. And this is why I created the concept of a prompt primitive within AutoShow.

00:48:46 - Dev Agrawal

Yeah, exactly. So with something like this, an application like AutoShow could also just be an MCP server that I can use with any client, because it's a set of prompts and a set of ways to interact with data. And that's pretty much it.

00:49:04 - Anthony Campolo

Yeah. And the resources would then be YouTube videos or audio files on your computer or things like that.

00:49:11 - Dev Agrawal

Right.

00:49:13 - Dev Agrawal

Or even the markdown files that you generate at the end.

00:49:16 - Anthony Campolo

Yeah, totally. There's a ton of potential there. And once the MCP has been built out more — maybe in six months or so — I may think about trying to create some sort of integration with AutoShow. There's definitely a ton of overlap. I just think the tech is still pretty new, and I'm not quite sure about putting it in production yet.

Okay, so we can go to tools now. Tools are really confusing to me, honestly. Back when I first heard the term — like a year ago when I was first starting to do more AI streams — I did one with my buddy Monark, and he built this framework called Ragged, which was a lot of it based around tool use. I started to understand it better with him. I like the example here because it's dumbass simple.

[00:50:12] This tool is literally just going to add numbers together. So really, when they say business logic, that's kind of how it's working here. The tool can also refer to things like reaching out to internet search — that's a really common tool — or getting the weather API or things like that, because the AI SDK from Vercel lets you do tool use, tool calling.

00:50:43 - Dev Agrawal

They have the classic example of the AI doesn't know the weather, but it can call the tool to figure out the weather in a location. Oh, there you go.

00:50:51 - Anthony Campolo

Exactly. So that's all good. Tools now make perfect sense to me. When I first heard the term, it was a little confusing.

00:51:01 - Dev Agrawal

But it's always confusing with things that are so generic. It's literally calling a function. It can do so many things, and it's hard to think of specific cases where that would help. It almost reminds me of AWS Lambda, where it's such a generic tool that it took us a few years to figure out what to do with them.

00:51:20 - Anthony Campolo

No, I totally agree. Lambdas are so confusing to me at first, until I was literally just like, oh, you mean it's just like an endpoint that runs Node? It's cool.

So now we see here this is a bit more involved because now we have a whole schema. This is also probably where Zod is super useful because we have, you know, we have an A and a B, both of which are numbers that we're going to add together.

So we see here we're actually getting an input schema with an object and properties being A and B, which are type number. And they're both required because obviously you can't add two numbers together if you only have one of them. And then they're even giving us the JSON Schema link here. This link is actually going to work. Let's see. Yeah. So do you use JSON-RPC much?

00:52:22 - Dev Agrawal

No, it's something that I've been vaguely familiar with for a while. But MCP is probably really driving the adoption of JSON-RPC these days. It's something that we've always had better alternatives to — GraphQL, tRPC, gRPC.

00:52:51 - Anthony Campolo

Or JSON, like an actual dev.

00:52:53 - Dev Agrawal

Yeah, exactly. So we're either too simplistic, too fast-moving, to use any sort of RPC layer, or we just use GraphQL. Why settle for a mid-range choice? I guess you either don't pick an RPC layer, or you pick the best one.

00:53:16 - Anthony Campolo

Yeah, yeah. I want to put a pin in GraphQL and talk about that a bit later. The only experience I'd had with JSON Schema and JSON-RPC prior to this was Dash, actually — the cryptocurrency I work with. Their whole platform is built around JSON Schema. So if you've used JSON, JSON Schema is not going to be very complicated to figure out.

But all these requests that we've been sending all have JSON-RPC 2.0 in the request because you have to make sure they know what schema you're using and that kind of stuff, and they come back in a very specific format. They usually include things like these schema links that explain things. It's very self-referential — which I imagine is really useful for LLMs to have all this stuff clearly defined.

00:54:16 - Dev Agrawal

Yeah. And thanks to MCP, I think every schema validation library is building an official way to convert their schemas into JSON Schema. With Zod, I was using an external library. The new release of Zod just built it in natively: take a Zod schema, convert it to JSON Schema, and use it wherever.

00:54:40 - Anthony Campolo

I think Titanium just joined the stream. What's up, man? I actually had a call last week with Dan. I don't know if you've talked to him since the events.

00:54:51 - Dev Agrawal

I talked to him.

00:54:52 - Anthony Campolo

He's doing well. I think he's doing very well. He's on a good path.

00:54:56 - Dev Agrawal

I'm very happy to hear that.

00:54:58 - Anthony Campolo

So he said, join in. Yeah. No, thanks for joining, Jan.

Okay, so right now, this tool, you just add two numbers together. This is going to add 10 and 32, which will give us back 42. So nice. That's nice and simple.

Okay, so this step four ended up kind of being stupid because the logging didn't work and the transport, I didn't actually get to. And then the review code, I was like, I'm going to skip this step entirely because I need to refactor this part of the tutorial. But that's okay because no one gives a crap. We want to actually use a freaking LLM. This is what we're here for. Let's use an LLM.

Okay, so step five. This is the most important. I'm just going to go into my terminal or my editor for this now. The most important thing, obviously, you got to have your API key for this.

[00:55:53] This bothered me for some reason — you cannot use the built-in Node.js --env file flag. For some reason I couldn't get it to work. I had to actually use dotenv. That's just a weird bug I could not figure out.

Anyway, if we look at this tool, this is the goods right here. So the chat completion endpoint — this is the bread and butter. This is what I was talking about before, with your system prompt and your user prompt. This is the type of code I've been writing with AutoShow.

And the awesome thing about the completion APIs is they've pretty much been standardized. Anthropic has a messages API, which is a little different. But if you're using Grok, Mistral, Cohere — I don't know about Gemini — a lot of the other LLM providers have basically just ported the exact endpoint that ChatGPT has here.

[00:57:00] So yeah. And that's it. So you see here, this is not a whole lot of code to get our LLM connected, which is really nice.

00:57:09 - Dev Agrawal

Yeah, I mean everything is cross-pollinating, right? I was very happy to see that when OpenAI finally released MCP support for their APIs as well.

00:57:19 - Anthony Campolo

Yeah, and I bet there was a lot of pushback from some people internally because it was built by their main competitor. There's a lot of weird bad blood between the two companies, because a lot of people kind of jumped ship from OpenAI to create Anthropic. That's at least what my buddy Eric was telling me — he's very much on the inside track with this kind of stuff.

00:57:41 - Dev Agrawal

They have a code competitor now.

00:57:45 - Anthony Campolo

Oh, yeah. Oh, that's right, they do. Yeah. Do you know what it's called?

00:57:49 - Dev Agrawal

I forget. Is it...?

00:57:57 - Anthony Campolo

Codex? I think that's it. Oh, wait. No, that's not it.

00:58:03 - Dev Agrawal

No, that's theirs. That's not the thing.

00:58:05 - Anthony Campolo

That was old. Actually, Codex coding agent, Codex CLI, I think, is what it is.

00:58:15 - Dev Agrawal

Yeah, probably that.

00:58:18 - Anthony Campolo

Yeah, this is it. Lightweight coding agent that runs in your terminal. Yeah, because that's pretty much what I got from Claude Code. It's basically just like a terminal thing. Obviously it can interact with your codebase, but it's not really like Cursor because it's doing a lot of stuff. It's for people who really love Vim. I bet it's great for sure. For me, it didn't quite feel like the right layer of abstraction for what I'm doing.

00:58:47 - Dev Agrawal

Yeah, for me, I like to take it either just in my editor, like Cursor, or a web app.

00:58:53 - Anthony Campolo

And Dan, so it's not necessarily for sending data. Well, it is for sending data. That's a good way of putting it, for both sending data to LLMs and just letting LLMs access your data and also just access other services broadly.

So it's kind of like a glue layer between lots of different pieces. If you look at the MCP server examples, I think this is actually really illustrative that it's not necessarily like, it's stuff like Google Drive and GitHub and Puppeteer, Slack, Google Maps, it's all sorts of stuff, you know, Cloudflare, this Elastic Beanstalk right now, I'm not sure what that is, Prisma, Stripe.

So, yeah. The idea being that it's something that both lets LLMs talk to data, but also lets everyone kind of standardize around this one protocol that lets all these applications talk together. And so that's why, you know, going back to what we first talked about, some people say why not just build a REST endpoint.

[01:00:02] It's like, well, you're going to build a REST endpoint that integrates with every single thing you see on this list? No, of course not. That's absurd.

01:00:10 - Dev Agrawal

I mean, you can also think of it as it's for sending data to LLMs and for LLMs to send data to the outside world.

01:00:19 - Anthony Campolo

Yeah. Okay, gotcha. So if my MCP is in your app, you can swap out LLMs for it.

01:00:26 - Dev Agrawal

Yeah. The user can swap out any LLM and any LLM-based application. So you can go between Cursor and Claude Desktop and Claude Code and really any other application that supports MCP or that's considered an MCP host.

01:00:43 - Anthony Campolo

Yeah. Switching out the apps is especially the big thing because what I did in AutoShow is I just built some utility functions that call different endpoints, and that wasn't very hard. Switching out different models and different LLM providers, especially if you're sticking with the completion endpoint, is not very challenging, actually.

So it's a good use case, but it's really not the killer use case for MCP. It's really about all the different applications that you can now kind of combine with each other.

01:01:17 - Dev Agrawal

Yeah. And in terms of the MCP host, the ability to switch out different models is probably going to be more relevant if you can make that decision smartly, like if you can somehow figure out whether a certain prompt or request should go to a smaller model for faster response, or it should go to a reasoning model. This is something that I've been thinking about for the last couple of days, because I saw that tweet about, hey, please stop saying thank you and sorry, you're wasting a bunch of GPU hours.

01:01:52 - Anthony Campolo

Yeah. So it's like, just send the thank you to GPT-3.5, you know?

01:01:55 - Dev Agrawal

Exactly.

01:01:56 - Anthony Campolo

Yeah. Totally. For me also, it's useful in AutoShow because I think it's useful to surface the different model choices to the user because it's a credit-based system. So you can kind of show them directly: here's a cheap model, here's an expensive model. Choose which one it makes more sense for what you're trying to do. Right.

01:02:15 - Dev Agrawal

Exactly. Yeah.

01:02:16 - Anthony Campolo

Mhm.

01:02:17 - Dev Agrawal

And maybe a combination of both. Okay. Figure out if this should go to a more expensive model. Ask the user, hey, do you want to switch to a model for this request?

01:02:29 - Anthony Campolo

Yeah. There's something called OpenRouter that I know of as well. Yeah, yeah.

01:02:34 - Dev Agrawal

So this is what chat is using behind the scenes.

01:02:38 - Anthony Campolo

Ah yeah, I thought that might be the case. Yeah. Cool. Okay, so we see here, I sent this request with a prompt saying, write me a short poem about doing the doodly doo because I like whimsy in my tutorials. So in the quiet of the afternoons, we gather around for the doodly doo whimsical dance. The playful step circles and twirls as spirits are kept.

01:03:03 - Dev Agrawal

No, I'm not doing the screen share.

01:03:05 - Anthony Campolo

Yeah. He said he got confused because he's watching on your channel.

01:03:08 - Dev Agrawal

Oh, okay.

01:03:10 - Anthony Campolo

Yeah, yeah, yeah, we're going on both of our channels right now. We're combining our powers. We're putting the rings together. Yeah. So that's my whole tutorial. So cool. How is that? Did that help elucidate some concepts for you?

01:03:30 - Dev Agrawal

Give me a second. Yeah, no, that's...

01:03:39 - Anthony Campolo

We're both wearing shirts right now. This is my Remix Netlify shirt.

01:03:46 - Dev Agrawal

We're doing a tutorial review. Kind of. I mean, it was a pretty quick tutorial review. Some of it was.

01:03:52 - Anthony Campolo

It's a crappy tutorial I'm gonna have to do some work on, but yeah. This is like the first I've found this new kind of rhythm where I like building. Right? I vibe code a tutorial, and then I go through it on stream with someone, and then I kind of find places to iron it out. And then I'm going to publish this probably in like a week or so. So Dan, if you want to go back and watch this guy and then give me notes, you're more than welcome to.

01:04:15 - Dev Agrawal

Yeah. No, I think that's a pretty good, very bare-bones introduction to MCP. It shows not only what it's kind of about, like how to define things for the models, but also how to interact with it on a technical level. I think the major missing point... Yeah. Go ahead.

01:04:40 - Anthony Campolo

Sorry. You should monologue on this. I just want to go off screen for like two minutes. Sorry. I want to keep going. So you fill time. Yeah. Go ahead.

01:04:49 - Dev Agrawal

Yeah. So I think the major point about MCP that's kind of been missing — and that I've brought up a couple more times — is how it's different from things like REST APIs or GraphQL. And obviously the big difference is that it's meant for LLMs. What that means is that you don't define your tools and resources the exact same way that you would define your REST API endpoints. Adding descriptions is one small indicator of that. You don't add descriptions to your REST endpoints — you do that for documentation. But here, descriptions are a very core part of what your tool can do. They very much decide when the model chooses to call that tool or to use that resource, or when the user decides to bring that resource in, or how the model understands that resource. So descriptions are no longer something just for documentation that can be ignored or treated as an afterthought.

[01:05:54] It becomes a core interface to the tool. And in a similar way, because we are not writing code to interact with these tools and resources — we are just handing them to our models — they also have to be designed a little differently. You cannot just have a one-to-one mapping between your REST endpoints and your MCP tools. You have to really try to encode workflows and use cases and a bunch of different things into these tools. So, yeah. How to write an MCP server — this is a great tutorial for that. But I think at some point we're going to need a next level, which is how to write a good MCP resource or how to write a good MCP server that you can bring into a client and actually make your life easier, rather than having to school the AI about how this MCP server works. What are the different tools you should use in different situations? I don't know how much sense that monologue makes.

01:06:56 - Anthony Campolo

No, that made perfect sense. This tutorial is really good for helping you understand the terminology and the concepts, but it very much feeds into what we started the stream talking about — which is that someone will look at this and be like, why the hell didn't you just build a normal server? Because that's all it's doing. And that's the same critique people would have of Redwood tutorials: "why are you building a blog? You wouldn't use Redwood to build a blog." Well, it's a learning resource. But I'm really glad you said that. I think that's super useful because I want to think about how I take this to the next step and what would actually be useful. And I like what you said about the descriptions — this is what I just love about LLMs.

[01:07:40] And this new paradigm we're getting into is that natural language is becoming so much more important to the whole process. You're able to talk to things like a person, and it makes things more human, more approachable to beginners. It's just such a good thing across the board. So that's a really interesting thing to key in on.

01:07:58 - Dev Agrawal

Yeah, exactly. I think the kind of tutorial I'm picturing in my head would be something where you define a tool and then immediately hop into an AI app and say something that's more natural to how you interact with people, with chatbots, or some part of your workflow — and then see if the AI can figure out that it should call this tool that you just defined. So it's not just about "go and call this tool." It's more about: here's something I'm doing — can you, based on this prompt, figure out that you need to call this tool? And can you figure out what parameters to call this tool with? And then if it doesn't, go back to your tool definition, update the description and schemas, and keep doing that until the description is good enough that the AI can take a natural interaction and figure out what tools to call.

[01:09:10] So maybe that's how, and same thing with resources. You just define kind of the general thing that you're looking for and see if the AI is able to figure out what the correct resources are that it should fetch. And the other good thing is once you're writing your resources and tools, you can just ask AI to give you these test scenarios, like, hey, give me a natural interaction that I can use to test if the AI can find the correct tools. So I've been using Cursor for this quite a bit. I define the tools that I have or that I'm playing with, and then I ask her, hey, give me some test scenarios for this. And they're a really good way for me to figure out, does the AI know, or can I figure out what to do from here?

01:09:54 - Anthony Campolo

Yeah, man, so much of AI dev, as I've been getting more and more into it, is very much the ouroboros of the snake eating itself, like using the AI to develop the AI. There's such a better feedback loop now. That's really fascinating and would have been impossible before.

01:10:11 - Dev Agrawal

Mhm.

01:10:12 - Anthony Campolo

Yeah. Cool. So I hit two more topics. So I listened to this podcast before the stream. My buddy Dougie, he's now hosting. He used to host Jamstack Radio. He now does Open Source Ready. And his last episode was about MCP, and they cover a lot of the same basics we did. They'll define what it is, really good supplementary material for what people just watched. But there is one point. They didn't go into it very deeply, but they mentioned GraphQL. And Steve, the guest, was basically like, you know, GraphQL is a lot of potential for this and could be pretty useful. But as far as he was saying, he hasn't seen a lot of development on it. There's not really anyone doing it. Brian was like, I should talk to Yuri from The Guild and see if he's on the MCP train. So, yeah. What are your thoughts on that?

01:11:01 - Dev Agrawal

I don't know. I think, yeah, I'm not really sure. I haven't spent enough time with GraphQL to kind of figure out if that's going to be a meaningful upgrade to MCP. It probably is just because it's definitely going to help in terms of if we only need a part of data. But again, resources are not really JSON. It could be anything. So GraphQL is really nice for data that is structured as JSON because you can write your queries to that similar shape. But a lot of MCP so far is like resources could be in any format. It could be a markdown file, it could be text, it could be an image file, it could be video. So yeah. And GraphQL is very much designed to handle deeply nested data where you can look at the entire structure.

01:12:01 - Anthony Campolo

Mhm.

01:12:03 - Dev Agrawal

Yeah. Maybe it's definitely going to be helpful for specific scenarios where you have that kind of deeply structured data. Like knowledge bases. Right now people are messing with graph-based data structures for AI memory, I guess. Yeah, memory is the word I was looking for. So maybe something like that where you want to expose the entire structure of the data to the model and let it figure out exactly what to extract from that structure.

01:12:32 - Anthony Campolo

Mhm. Okay. Interesting. Yeah. And Dan is saying here that Syntax just did an MCP episode as well. Here is the link for that. For anyone curious, I also found there is a repo with about 100 stars of someone who has built out some sort of GraphQL thing, so I'll probably clone that down and play around with it at some point. But the other thing I was curious to ask about: do you want to talk more about the AI app that you were building and what its status is?

01:13:10 - Dev Agrawal

Yeah. If you ask right now — for the models that have a cutoff date that doesn't include the MCP burst — if you just say MCP, it's going to think Minecraft server.

01:13:21 - Anthony Campolo

Interesting. Yeah. I was just a little bit too old to hit the Minecraft phase. I was kind of getting out of video games once it started blowing up. So don't have a lot of context on that.

01:13:33 - Dev Agrawal

Yeah. So the tool that I'm building — the first way you can think of it is like a personal assistant that basically has access to your entire life in some way. I want to give this thing access to my emails, my Slack channels (including work), my Notion, these streams that I do, maybe even my Twitter feed, if that becomes possible. Basically give it as much context as possible about the kind of work I do, my interactions with people, my personal journey. I write journals as well — ChatGPT has actually really upped my journaling strategy. So that's the first part: it's able to know everything about me and do things on my behalf. It can write a draft email for me, make changes to my Notion document, update my to-do list with things that I'm talking about.

[01:14:27] So it can do all those things. And the second thing I was thinking about is what I'm calling asynchronous tool execution. Right now, if you want to execute tools — what I'd call synchronous tool execution — the model comes back and says, here I want to call this tool, and you either approve that execution or deny it. Then if you approved it, it calls the tool and moves on to the next thing. The point is that when the AI requests a tool execution, it stops there until the tool is executed or denied, and then goes on. I want to achieve asynchronous tool execution.

[01:15:17] It's where the AI says that, here I want to call this tool, but it's immediately just put in some sort of a queue, or like I've used the word action plan in the past, but you can think of it as just a queue, and then it moves on. So it can put a bunch of tool executions in the queue. And later, when you give it a different prompt or for any future interactions, it's going to have that queue in context. So it's going to see, it's always going to have the knowledge of all the tools that are in the queue or all the executions. And at any point it can remove things from the queue, or it can add new things, or it can tweak the parameters. So basically you're collaborating with the AI on this list of tool executions over time. And then you can execute them at will. So instead of, like, here, go execute this tool right now, and before I can do the next thing, it's more like in a planning collaboration phase, where you come up with a huge list of things that are going to happen by the end of it or throughout the middle.

[01:16:22] And the original source of inspiration for async tool execution was using it as a meeting assistant. So let's say you get into a 15–20 minute standup with your teammates — you're talking about the work you did yesterday, the work you're planning on doing today, any blockers, progress updates. I wanted, as I say those things in the meeting, for something to be transcribing all of it and then making changes to our project board — Trello, Jira, whatever it is — automatically. Add all the progress updates, move the card tickets around, and I don't have to do any of that. I can just say these are the things that are happening, and over time it does those things on those boards. It can maybe schedule meetings as well, or send emails. So those are kind of the two things I'm hoping to build.

01:17:19 - Anthony Campolo

No, that's super sweet. I'm using some tool — Jen Jannard had something she hooked into our AutoShow meetings that doesn't do all that, but it does just listen to the meeting and gives you a summary at the end. So yeah, kind of does the first part of that whole workflow you're describing. And that's something that AutoShow can do pretty easily — you create a meeting prompt and have it listen. Once the audio file is done, it feeds it to AutoShow. So Dan is mentioning now wearables. There's this guy who had a necklace. I think I know what he's talking about. I remember what it was called, but there was something called Rabbit that was also very similar. It was a pin, not a necklace, but yeah. So is that something you're thinking about that, like you would even have, like something just listening to all of your conversations as well, because then it's like that's really next level, although.

[01:18:11] Because then if you just had a meeting, you would just have to turn your computer sound on and it would always be able to listen to everything.

01:18:19 - Dev Agrawal

Yeah. I mean, I've been using Alexa devices for like three or four years now. So I'm honestly very comfortable with the idea of something that has the potential to always be listening. Obviously right now I have to trigger the Alexa. But I could ask it, "hey, turn on your mic and listen to the next hour of this conversation," and just do whatever. So I'm not entirely opposed to the idea of wearables. I don't know — I'd have to experiment more with them, actually use one for a while, to figure out if it is a good idea or not.

01:18:59 - Anthony Campolo

Just devices sitting around you with microphones that it's just kind of redundant. Yeah.

01:19:05 - Dev Agrawal

That's fair. Yeah.

01:19:06 - Anthony Campolo

Yeah.

01:19:07 - Dev Agrawal

I don't know, the thing about wearables is more like they're slightly more accessible. Like, I don't have to hold the phone in my hand the entire time. Yeah. So there are little hardware conveniences around it. But yeah, it'll be interesting to see where it goes.

01:19:24 - Anthony Campolo

Yeah, for sure. Part of me thinks that's going to be a hard sell for a lot of people because they'll be worried about their data and privacy. But then at the same time, all of our phones are already listening to us, and I think most people have kind of accepted that. People complain about it, but in practice they don't actually care. They will use devices that listen to them 24/7, and then they just convince themselves it's not doing it. So that's the one big difference: if you explicitly buy a wearable that is supposed to listen to you all the time, it's really no different from your iPhone — but you have to make that mental switch to actually give consent to it, instead of just hoping it's not, and knowing in the back of your mind it probably is.

01:20:13 - Dev Agrawal

Mhm.

01:20:14 - Anthony Campolo

Yeah. Interesting. I wonder if Apple would even let you as a watchOS app developer listen in the background. My conspiracy brain thinks every single one of these devices listens all the time, and the developers of these companies are just lying to us. That's a really good question, Dan — and I do not know. I try not to think about it too much because I get paranoid and weirded out when I go down these rabbit holes too deeply.

01:20:44 - Dev Agrawal

Yeah.

01:20:48 - Anthony Campolo

Cool, man. I think this is a good place to start winding down. What do you want to do for our next stream?

01:20:55 - Dev Agrawal

I mean, I want to try to get Peter on again and talk about the new direction of Redwood.

01:21:02 - Anthony Campolo

Yes, we will do that. I mean, separate from that.

01:21:06 - Dev Agrawal

Okay, separate from that. Let's see, I don't know what's been something fun that you've been working on.

01:21:13 - Anthony Campolo

I mean, I'm just heads down still building AutoShow. Most of the stuff that feeds into that we've already done streams about. I would — since you're kind of into it — like to just dig deeper into MCP and especially Open Control. Is that the name of the thing? Yeah, Open Control. I think that could be cool. That's going to take me past a lot of the initial blockers I had just trying to get this hooked up to a server. So that could be fun.

01:22:09 - Dev Agrawal

I mean, there's really no reason not to open source these things, because if I don't open source it, someone else is going to build an open-source version just a few months after me. The AI ecosystem is moving so freaking fast right now. Like, there were tool ecosystems or frameworks — or JavaScript frameworks or whatever — that had their own format for defining tools, and they had an ecosystem of hundreds of different tools that worked with their framework. Those existed, but now MCP has kind of shut down that entire set of possible ways to do business. And Google launched a two-way protocol — I haven't looked into that much, but I'm assuming that might have similar effects. So any business model or product idea you could think of right now — in a few months of time, things are going to shake up so much that that exact idea is going to be democratized, open-sourced, made available for free.

[01:23:21] So there's really not a whole lot. Open Control was a great example of that. I thought I was building this tool with my previous company — we were going to use it internally, we were going to productize it — and then Open Control comes along, building a very similar thing but fully open source with MIT license. And now I'm like, this is what I was building. It's MIT open source. Now what? How am I supposed to earn money based on my thing now? So yeah, it's almost folly not to open-source things you want to build in the AI ecosystem, because chances are other people are building something very similar. It's better to find centers of collaboration — to use projects as ways to collaborate on ideas — rather than build a wall around something to productize.

01:24:18 - Anthony Campolo

Yeah. No, that's great. That's exactly why I've been doing AutoShow totally open source. And I think the real secret sauce for most companies at this point is just going to be UX — actually building a front end that is really slick and easy for people to use. And if someone wholesale copies your front end, that's poor form, although I'm sure people would do it anyway. But yeah, if you end up getting that repo going at some point, we could chat about that on stream. I also wrote a blog post for Semaphore where I did a kind of agent implementation for code review, which is actually really useful — because Theo just posted this a couple days ago about code review being an unsolved problem.

[01:25:11] I would certainly not claim that I have solved code review, but what it does is look at your changes — a PR or commit — and say: what has changed? What are the security implications? Does it make your code more or less maintainable? It just gives you a whole bunch of pieces of feedback about it. Semaphore is a CI/CD company, but I ported it to just a GitHub Action. So that could be a fun one. If we want to do a grab bag episode in a month, we can hit a bunch of topics. But what's this CodeRabbit thing?

01:25:48 - Dev Agrawal

So it's the thing that you were talking about. It's a SaaS version of that. It hooks into your GitHub and provides in-depth PR reviews. Yeah, Theo has been using it for a while. I think they even sponsored Theo for some videos.

01:26:02 - Anthony Campolo

Okay, I should try this. We should look at this on stream and just compare it to the open source thing that I built.

01:26:09 - Dev Agrawal

Yeah. So next month is going to be a little packed. I'm speaking at Stir Trek at the beginning. I'm speaking at Local First Conf in Berlin, which is super exciting. I'm talking about SolidJS and how it integrates nicely with the local-first ecosystem. So that's my beginning and end of May, and I don't think I have much going on in between.

01:26:46 - Anthony Campolo

Yeah, chat after — just give me a week, and we can find a date. And since Dan is mentioning Solid, that just reminded me: also next time I can show you Ryan GPT. I'll hopefully have it deployed and on the URL by then because it basically works. It works locally, I just have to actually deploy it and get it set up. Yeah, dude, I built Ryan GPT. It has all of his stream transcripts. I still have to hook in his blog posts, but it's about 90% done. It's a pretty legit project and I'm super proud of it. I can't wait to put it out into the world.

01:27:30 - Dev Agrawal

Yeah, yeah. Once that goes out, we need Ryan to do an entire stream — or at least like 30 minutes of a stream — playing with it.

01:27:37 - Anthony Campolo

I'm at least going to get him on my own stream. Once we do that and I kind of get him bought in, I'll see if I can get on his stream. Because I've been on his stream to talk about Redwood — it would be cool to get back on again to talk about this. I think anyone who is into Ryan should find this, and Dan is the perfect second person I would want to tell about this project. So I'm really glad he's here to talk about it because he knows Ryan so well. So yeah, I think we've got plenty of stuff to talk about for the next episode. Unless there's anything else you want to say, we can close it off here.

01:28:10 - Dev Agrawal

Keep building cool AI stuff — and please do, because we really need lots of them to figure out what works.

01:28:21 - Anthony Campolo

For real, man. Yeah, the time is now. Super appreciate you being on the stream, Dan. And I appreciate everyone who was here chatting.

01:28:32 - Dev Agrawal

You have enough people to raid you.

01:28:35 - Anthony Campolo

Oh, I mean, I'm going into the StreamYard interface, so yeah — but yeah, go for it.

01:28:50 - Dev Agrawal

All right, give me one. Let me look at my livestream. Oh, I almost forgot my Twitch username. All right, let's raid — over three people, whoever's here.

01:29:03 - Anthony Campolo

Awesome.