MCP from Scratch

Summary

Every AI tool you've wired up by hand (the Slack integration, the database lookup, the "let the model read our docs" hack) is a one-off. You wrote the glue, you own the glue, and the next model or the next client can't use any of it. The Model Context Protocol is the fix: one open standard for how an AI app talks to your tools, your data, and your prompts, so you build the integration once and every MCP-aware client (Claude Code, Claude Desktop, Cursor, and a growing list) can use it.

This is the guide I'd hand a competent developer who keeps hearing "MCP" and wants to actually build one instead of nodding along. We start from the problem it solves, get the mental model straight (hosts, clients, servers, and the three things a server exposes (tools, resources, prompts)) then build a real server from an empty folder: a tool the model can call, a resource it can read, a prompt it can reuse. We test it with the Inspector, wire it into Claude and Cursor, then take it remote over Streamable HTTP and talk honestly about the security boundary you're now responsible for.

By the end you'll understand exactly what's happening when a model "uses a tool," and you'll have shipped a server you can point any MCP client at.

This is a living document and will be updated as the protocol and SDKs evolve.

Loading Why MCP Exists…

Loading The Mental Model: Hosts, Clients, Servers…

Loading Your First Server…

Loading Tools: Letting the Model Act…

Loading Resources: Letting the Model Read…

Loading Prompts: Reusable Workflows…

Loading Testing with the Inspector…

Loading Wiring It Into Claude (and Cursor)…

Loading Going Remote: Streamable HTTP…

Loading Shipping It: Security, Packaging, What's Next…

Do you like my content?

Sponsor Me On Github

Keep reading

AI Project Management: Shipping Software When Agents Write the Code

Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._

Read guide

Mastering Hermes

Most of this series treats Hermes as the place its ideas land. Building Your Agentic OS pivots to it, Running the Fleet orchestrates on it, Self-Hosting the Agentic Stack deploys it. What none of them do is sit down and cover Hermes itself, the whole thing, every feature, the way I'd walk a competent developer through a tool they've never run in anger. That's this guide. Hermes is Nous Research's open-source, self-hosted agent, the one with a built-in learning loop: it writes its own skills from experience, curates its own memory, searches its own past conversations, and builds a deepening model of who you are across sessions. It installs with one command, runs on a five-dollar box or a GPU cluster, talks to whatever model you point it at, and you can message it from Telegram while it works on a cloud VM. That surface is a lot bigger than the rest of the series has needed to show. So here we go wide instead of deep: install and first contact, the model layer and Nous Portal, the terminal interface, the messaging gateway across six platforms, the six places it can run, the learning loop, context files and personality, tools and toolsets, MCP, scheduled automations, delegation and subagents, the security model, day-two operations, and migrating in from OpenClaw. Where a topic has its own field guide in this series, I point you there instead of repeating it. This is the manual that ties the rest together. _This is a living document and will be updated as Hermes updates._

Read guide

Agent Memory: A Field Guide

Two people give the same agent the same task and get wildly different results. Most of the time it isn't the prompt. It's that one of them gave the agent a memory and the other is re-explaining themselves at the start of every session. A model is stateless by default: brilliant for ninety seconds, then a blank slate. Memory is the layer that turns a clever one-off into a teammate that knows your codebase, remembers the decision you made last week, and gets better the longer it works with you. This is a field guide to building that layer on purpose. We start with why agents forget and the taxonomy that makes the rest make sense (working, episodic, semantic, procedural memory) then build it the way you actually should: plain files first, one fact per file, before any vector database. From there we get into the parts everyone underestimates: deciding what's even worth remembering, getting the right memory back out (retrieval is the hard half), and what to do when a memory goes stale and starts lying to you. We cover the scoping decisions, shared brain vs. per-agent, per-user vs. per-project, the read-before-act / write-after loop that makes memory compound, and when to graduate from files to a real store with versioning and redaction. It's a companion to [Building Your Agentic OS](/guides/building-your-agentic-os) and [Running the Fleet](/guides/running-the-fleet), where those build the system around the agent, this one goes deep on the single pillar that most changes how an agent feels to work with. By the end you'll have a memory you can stand up this afternoon, and the judgment to know what to put in it and what to leave out. _This is a living document and will be updated as the tools and patterns evolve._

Read guide