Build Your First AI Agent from Scratch: Using MCP to Break the LLM Knowledge Cutoff

Why MCP Suddenly Took Off

One of the biggest limitations of large language models is the knowledge cutoff. They know everything in their training data, but nothing about what happened after training ended — like the real-time price of Apple stock right now. MCP (Model Context Protocol) was built specifically to solve this problem.

Instructor Bruce, in a 30-minute hands-on session called "Zero to Agent," pointed out that MCP's adoption has been staggering: the Python SDK alone is downloaded over 300 million times per month, with the Node.js version exceeding 180 million. These numbers make clear that MCP is no longer an experimental concept — it's an engineering standard being adopted at massive scale.

The entire demo is built around one goal: construct your first Agent that enables a model to call external tools and retrieve real-time data.

A Live Stock Price Demo That "Opens the Model's Eyes"

Bruce started with a direct test using Claude Desktop. He asked the model for its knowledge cutoff date — Sonnet replied "late June 2026." He then asked "What's Apple's stock price right now?" Because he had already connected his own stock MCP server, the model automatically found the corresponding tool, called the underlying 12 Data API, and returned a live price: $337, up $8 on the day, with a previous close of $329.

The key here: the model itself doesn't know the answer, but through MCP tool calls, it "outsources" the question to a service that can answer it. This is the core value of MCP for extending the boundaries of LLM capabilities — letting conversations break through the training cutoff date.

Even more interesting is the custom URI. Bruce demonstrated typing stock://GOOG, which returned Google's stock price of $347, up $10. stock:// is not a standard protocol like HTTP or HTTPS — it's a custom URI he defined in his code, meaningful only between him and the model. This provides an elegant addressing scheme for orchestrating multiple MCP servers.

MCP Protocol Fundamentals: Understanding It Through HTTP

Bruce uses HTTP — something everyone uses every day — as an analogy for MCP, and it's a very intuitive framing.

At the messaging protocol level: HTTP has clients (browsers) and servers (web servers) exchanging HTML. MCP has MCP clients (Claude Desktop, VS Code, ChatGPT, or any LLM-powered host) and MCP servers (code you write yourself), exchanging JSON — specifically JSON-RPC.

RPC stands for Remote Procedure Call. The server throws JSON at the client, and the client reads it to invoke remote calls on the server. For example, when a client asks "what can you do?", it sends a tools/list request. The server returns an array of tools, each containing a name, a natural-language description, and an input schema. The model reads both the name and the description, so the quality of your descriptions directly impacts how well the tool gets invoked.

Creating an MCP server requires just one line of code: mcp = FastMCP("any name"). In a complete implementation, you'd also load environment variables, set the API key, and initialize the 12 Data client.

JSON-RPC is a lightweight remote procedure call protocol that uses JSON as its data format. Unlike REST APIs, it doesn't rely on HTTP verbs (GET/POST, etc.) to express semantics. Instead, it specifies the method to call via a method field in the message body, passes parameters via params, and uses an id field to match requests with responses. In the MCP context, every message the client sends follows this structure — for example, {"jsonrpc": "2.0", "method": "tools/list", "id": 1} — and the server returns a result with the matching id. This design makes MCP inherently language-agnostic: whether the server is written in Python, Node.js, or Go, as long as it can send and receive JSON, it can connect to the same client.

Transport Layer: Choosing Between stdio and Streamable HTTP

MCP supports two transport modes, and which one you choose directly determines your deployment architecture:

Standard Input/Output (stdio)

With stdio, the MCP client and server must run on the same machine — meaning local-only deployments. In this mode, stdout is used for the transport channel itself, not for logging, and stdin cannot be used for receiving data. Under stdio mode, you don't need to manually start the server — the client will spin it up.

Streamable HTTP

With streamable HTTP, the client and server can be anywhere — local, on a LAN, or on the internet. But like any HTTP server, the rule is the same: the server must be running before a client can connect. Just like Amazon's servers must be online before you can visit amazon.com.

Setting the transport mode in code is equally minimal: mcp.run(). Without specifying anything, it defaults to stdio; to use HTTP, declare it explicitly.

"Streamable HTTP" is MCP's specific implementation of server-push capability, distinct from traditional request-response HTTP. Traditional HTTP is one-directional — the client initiates, the server responds. But MCP tool calls often require the server to continuously push progress or stream results during execution. Streamable HTTP draws from the Server-Sent Events (SSE) pattern, allowing the server to continuously write data over a single HTTP connection while the client consumes it in real time, without waiting for the full response to complete. This is especially important for long-running tool calls (such as querying large databases or calling third-party APIs), preventing the client from mistakenly timing out.

Tools, Resources, and Prompts: The Three Core Primitives

MCP divides AI-powered functionality into two categories — tools and resources — with a clear distinction:

Tools: When a function needs to read and return a single value (a primitive type like boolean, integer, float, or string), or needs to perform an action (toggle a light, play/stop music, store a record), it's a tool. Declared with the @mcp.tool decorator. Bruce wrote two tools for stocks: get_current_stock_price and get_historical_stock_price.

Resources: When a function needs to access a large data store (a filesystem, database, or codebase) — content far too large to fit in a single string — use a resource. Declared with the @mcp.resource decorator.

Bruce emphasized: strictly speaking, the stock service should be a resource, but not all MCP clients have stable support for resources. Resources also have a unique capability — custom URIs can only be defined through resources. The stock:// magic happens inside the resource declaration, telling the model "when you see this format, call me." He gave an example: a corporate helpdesk could define company://vacation for checking time-off policies and company://expenses for submitting expense reports, elegantly orchestrating multiple services.

Prompt templates: In MCP, prompts aren't what we normally think of as user questions. They're example prompts written in code for the model to read — showing it "how to use this server." Declared with the @mcp.prompt decorator.

Configuration and Security: Helping Claude Find Your Server

For dependency management, Bruce recommends UV over pip — claiming it's 100x faster. Installation command: uv add "mcp[cli]".

Configuring Claude Desktop to recognize your MCP server is straightforward: edit the claude_desktop_config file and fill in the mcpServers section with the run command (e.g., uv) and arguments (the full path to your server script). Once configured, a server named "stocks" appears inside Claude.

On Security and Guardrails

A few Q&A questions from the session were particularly valuable:

• Malicious input: When someone tries to input a path like C:\users\your-aws-credentials, modern models are smart enough to recognize and reject it.
• Malicious tool descriptions: Running a local MCP server requires the user to have a runtime (UV, Python, etc.). With a remote MCP server, users need no local runtime at all — just authentication login. No code is called locally — this is the strictest security approach.
• Explicit guardrails: You can explicitly restrict operation permissions. For example, a database MCP server can be set to read-only, blocking insert, update, delete, and other destructive operations — preventing someone from dropping a database or creating rogue tickets through natural language.

UV is a Python package manager and project management tool written in Rust by the Astral team (the same team behind the Ruff code formatter), released in early 2024 and quickly becoming a community favorite. It achieves dramatic speedups through parallel downloads, a global dependency cache, and avoiding repeated dependency tree resolution — the performance advantage over pip is especially pronounced in projects with many dependencies. For MCP development, UV has another benefit: built-in virtual environment management. The uv run command can execute scripts directly in an isolated environment without manually activating a venv, making startup command configuration in claude_desktop_config cleaner and more portable.

MCP and Skills: Not Rivals, But Collaborators

The final question addressed a common source of confusion: should you use MCP or custom Skills? Bruce's answer: they don't conflict at all — they work together.

A Skill is essentially a Markdown file (with optional scripts) that teaches the model to "always do something a specific way." Because LLMs are non-deterministic, Skills bring consistency. Take a weather MCP server — without constraints, Claude might bypass it and look up the weather on its own. A Skill can enforce the rule: "whenever the user asks about weather, you must call this server."

Bruce noted that the plugin systems in both ChatGPT and Claude are themselves built around pairing MCP servers with Skills. MCP handles "what can be done"; Skills handle "when and how to trigger it reliably." The two complement each other perfectly.

Summary

This compact hands-on session takes MCP from concept to runnable code: the core is using JSON-RPC protocol with stdio or HTTP transport, through three primitive types — tools, resources, and prompts — to let LLMs break through their knowledge cutoffs and access real-time data. With FastMCP and UV, a few dozen lines of code is all it takes to stand up your first Agent. For anyone looking to get started with Agent development, this is a clear and reproducible path forward.