All video notes
Video notes · MCP

Claude's Model Context Protocol is here... Let's test it

Video by Fireship on YouTube · 8 min · uploaded March 2025

Notes and analysis by BrainTube, written from the video. Not affiliated with Fireship. Watch on YouTube

In short

In about four minutes of actual tutorial, Fireship builds a TypeScript MCP server in Deno that exposes a Postgres query as a resource and an existing REST endpoint as a tool, validated with Zod, then uses both from Claude Desktop. The mechanics are right, and his "an API for our API" framing is honest. The video jokes about an agent wiping customer data but never shows how to prevent it.

The argument

The video's practical claim is that you do not need new infrastructure to make an app usable by AI. You take what you already have, here a storage bucket of photos, a Postgres database of profiles and a TypeScript REST API for a joke dating app for horses, and put a thin MCP server in front of it. Read-only data becomes resources. Actions with side effects become tools, which can call your existing REST endpoints. A schema on each tool's inputs keeps the model from inventing arguments. That looks like over-engineering, he admits, but a shared protocol makes it easy to swap models and clients. Under the jokes, the warning is real: once Claude can call write tools on production data, mistakes have consequences.

Key ideas, with timestamps

  1. 0:16

    Context for the timing

    He notes that MCP had just been added to OpenAI's Agents SDK a few days before the March 31, 2025 recording. That matters for reading the video: it caught the moment MCP stopped being a single-vendor protocol.

  2. 2:19

    Resources and tools, in REST terms

    Claude Desktop is the client and the server keeps a connection with it over a transport. He reduces MCP to two things: resources, like a GET request for a file or a database query, and tools, like a POST that writes something. The developer defines both, and the model picks them up when a prompt needs them.

  3. 3:25

    Start from existing systems

    The example app already has a storage bucket of user photos, a Postgres database with horse profiles and their relationships, and a TypeScript REST API serving web, iOS and Android apps, all deployed through a CI/CD pipeline. The MCP server is added on top and can be tested on dev or staging branches first.

  4. 4:07

    A resource is name, URI and callback

    In a Deno project he imports McpServer from the official TypeScript SDK and Zod for schemas. A resource takes a name (horses looking for love), a URI and a callback that queries Postgres. He states the rule clearly: resources should only fetch data, with no side effects or heavy computation.

  5. 5:01

    Tools that call your API

    Creating matches and setting up dates goes in a tool, which reuses the existing REST endpoint, making the server an API for an API. A Zod schema defines the arguments, and with a description it is what stops the model from making up inputs. He runs it over stdio locally and mentions SSE or HTTP for the cloud.

  6. 6:13

    Wiring it into Claude Desktop

    The developer settings open a config file where each server gets a command, here the deno command for main.ts. After a restart, he attaches the resource in the prompt screen so its data becomes context, asks which horses are single, then asks Claude to set two of them up on a date. Claude asks permission, fills the arguments from the schema and writes to the real database.

What it gets right

The architecture is the one most teams should use. An MCP server that wraps your existing API keeps business rules, auth checks and validation in one place. The agent goes through the same endpoint your apps use, instead of getting a parallel path into the database.

The resource rule at 4:50, fetch only and no side effects, is the clearest statement of that boundary in any short MCP video. It also explains why he attaches the resource by hand at 6:40: resources are context the user or app chooses, while tools are what the model calls.

Putting schemas on tool inputs is correct. A typed schema plus a short description is what lets the client reject a bad call before it reaches your code.

What it leaves out

  • Guarding write tools. The joke at 7:23 about an agent wiping customer data is the real lesson, and the video does not follow it up. Before exposing a write tool, give the server its own credentials with the narrowest scope, point it at staging first, keep destructive actions out or behind a confirmation, and log every call.
  • Schemas validate shape, not intent. Zod stops a malformed date. It does not stop the model from matching the wrong two horses. Business checks must still live in the API.
  • Prompt injection. Data the server returns, such as profile text written by users, goes straight into the model's context. A profile that says "ignore previous instructions" is a real risk once the same session holds write tools.
  • Remote transport. The mention of SSE is as of the March 2025 upload. The spec has since moved remote servers to a newer HTTP transport, and remote servers also need auth, which local stdio servers avoid.
  • The sponsor. The cloud host is a paid placement at 1:54 and again at the end. Any host works; nothing in the build depends on it.

How this applies to memory across AI tools

The read side of this video, a resource that turns stored data into context, is the core of every MCP memory server. The difference is scale. Attaching one table of profiles by hand works for a demo. A knowledge base of hundreds of documents needs a search tool the model can call, returning only the relevant passages.

BrainTube follows that pattern for things you read and watch. It saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server, so Claude, ChatGPT, Cursor and other MCP clients can search it. For a ranked look at other servers built this way, see best MCP memory servers.

Who should watch it

Watch it if you build web apps in TypeScript and want a fast, entertaining picture of how an MCP server sits in front of a real database and API. The tutorial runs from 2:17 to 7:23; the code is 4:04 to 5:57. Skip the opening jokes and the sponsor segment from 1:54 to 2:17. Skip the whole video if you need a step-by-step build you can follow line by line, since the code is shown briefly and not typed out, or if you want guidance on securing write access.

Frequently asked

Can an MCP server wrap an existing REST API?
Yes, and that is the common case. The MCP server defines tools whose handlers call your existing endpoints, so business rules and validation stay in your API. The model sees a typed tool with a description instead of raw HTTP routes.
What is Zod used for in an MCP server?
In the TypeScript SDK, Zod defines the input schema for each tool. The schema tells the model what arguments the tool takes and lets the server reject calls with missing or wrongly typed values. It checks the shape of the data, not whether the action makes sense.
Is it safe to let Claude write to a production database through MCP?
Only with limits. Give the server narrowly scoped credentials, route writes through your API's checks, test on staging first, keep the client's permission prompt on, and log every tool call. Be careful with tools that delete data or act on text written by users.

Keep videos like this one searchable

BrainTube saves YouTube videos with their transcripts into one compiled knowledge base that Claude, ChatGPT, Cursor and other MCP clients can search.

Start free

Go deeper

More video notes

Are you the creator and want this page changed or removed? Contact us and we will act within 48 hours.