Video notes: MCP, agent memory and knowledge management

Tim explains that an MCP server is a program that hands a model a list of callable functions, then builds a Python notes server with FastMCP three times: local over stdio, remote over HTTP, and remote with OAuth sign-in and scopes. The explanation of transports and the auth flow is accurate and more complete than most tutorials. The auth half is a sponsored Descope demo, so it shows one vendor's console rather than the general pattern, and it skips several security checks a public server needs.

Nana explains MCP as a standard layer between LLM apps and existing APIs, so you write one integration per tool instead of one per model and tool pair. The architecture walkthrough (host, client, server, tools/list, tools/call) is accurate and clear. Two claims are oversold: much of the "stateful context" she credits to MCP is really the host keeping chat history, and LLM-friendly responses only happen if the server author designs them.

This Google Cloud Tech explainer teaches the basic shape of the Model Context Protocol: servers advertise tools, resources and prompts, clients discover and call them, and MCP sits on top of existing APIs rather than replacing them. That framing is right and clearly explained. It gets two details wrong (the model is not the client, and "context" is not a separate primitive) and leaves out transports, authentication and security risks entirely.

This 40-minute KodeKloud video takes a beginner from 'what is an agent' to a working FastMCP flight booking server connected to the Roo Code extension, then sketches a Python client. The spec walk-through (JSON-RPC 2.0, stdio and HTTP transports, tools, resources, prompts, roots, sampling, elicitation) is accurate and unusually complete for an intro. It is thin on how the model actually chooses tools, who controls resources and prompts, and how to secure a remote server.

The video walks a complete beginner from chat apps to agents, APIs, MCP and Google's agent-to-agent protocol, then books a simulated flight through an MCP server in VS Code. The API section and the lab are clear and honest. Its core MCP pitch is off: MCP does not remove adapter code, it moves that code into a server someone still has to write.

In this 20-minute conversation, Anthropic's MCP team explains the protocol as a standard way to hand context to an LLM app: tools, resources and prompts. They cover its origin in copy-paste frustration, why it was open-sourced, the move to remote servers, and a roadmap of a registry, long-running tasks and elicitation. It is a good primary source on intent, but light on how the protocol works and on its risks.

Tim Berglund argues that MCP matters less for desktop chat apps than as a way to build pluggable, discoverable and composable agents inside a company. His whiteboard walkthrough of host, client and server, and of who actually executes a tool call, is one of the clearest short explanations available. A few technical details were already out of date or wrong at the May 2025 upload, notably the description of RESTful endpoints and HTTP with Server-Sent Events as the remote transport.

IBM's video explains that MCP and REST APIs are both client-server abstractions, but MCP is built for AI agents: servers list their tools, resources and prompts at runtime, and every server answers the same calls. Its key conclusion, that MCP servers usually wrap existing APIs and so the two are layers rather than rivals, is correct. It undersells existing API description formats and skips the costs of dynamic discovery.

The video explains MCP as a client-server standard, then builds a Python server for a personal assistant with one prompt, three resources and a Gmail draft tool, tested in the MCP Inspector and Claude Desktop. The concepts are accurate and the demo shows a lesson most tutorials miss: Claude calls tools on its own, but you must attach prompts and resources yourself. Its description of remote transport is already dated.

Codebasics builds a small Python MCP server for HR leave management with the official SDK's FastMCP class, installs it into Claude Desktop with one command, and shows Claude picking the right tool from plain-English questions. It is a good first hands-on demo and the advice about docstrings is the most important line in it. It skips everything that matters once the data is real: persistence, validation, authorisation and the risk of letting a model call a write tool.

The video builds a small MCP server in Python with the official SDK's FastMCP class: two tools that add and read notes, a resource for the latest note and a prompt that summarises them, all tested in Claude Desktop. The steps are correct and the troubleshooting is honest. It skips the faster test loop, the stdout trap in stdio servers, and what a notes server needs before it is useful as real memory.

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 video explains MCP as a standard layer between an LLM app and outside tools, so the integration code is written once by the service provider instead of by every app team. Its walk-through of tool discovery, tool descriptions and the three server capabilities is accurate and practical. It skips transports, security and the question of who controls each capability, which you need before building anything real.

In this episode Ross Mike explains MCP as the third stage after bare LLMs and LLMs with hand-wired tools: a shared standard that sits between a model and outside services. The framing is clear and good for non-technical viewers, and his point that service providers now write the servers is the key insight. The translator analogy oversells what MCP does, and several of his open questions, such as whether OpenAI would adopt it, were answered within weeks of the March 2025 upload.

Mahesh Murag explains MCP from the inside: why Anthropic built it, how tools, resources and prompts are split by who controls them, and how sampling plus composability let agents call other agents. The design reasoning is the best part and still holds. The auth, transport and registry sections describe plans as of early 2025, and several of those details changed in later spec revisions.

IBM's short video explains MCP through its three parts, host, client and server, and walks through one tool call from question to answer. The request flow is correct and is the useful part. It wrongly calls the protocol itself a transport layer, blurs the host and client, and at under four minutes leaves out resources, prompts, transports and security.

Google Cloud's episode argues that agent memory has two kinds: exact facts, which belong in a SQL database, and softer understanding about the user, which belongs in a store you search by meaning, with raw audio and video kept out of memory. It adds a useful timing rule: write facts immediately and extract understanding asynchronously, off the live path. The split is right and widely useful, but the video skips the harder parts: contradictions, stale preferences, user control and facts that are also preferences.

The video sorts four ways of giving an agent knowledge by what each one supplies: skills give a procedure, MCP gives access to live systems, RAG gives documents people wrote, and memory gives lessons the agent learned itself. That rule of thumb is sound and easy to remember. It treats the four as separate boxes, though, when in practice they stack, and it says nothing about the risks of letting an agent write its own memory.

The video explains long-term agent memory by dissecting Mem0: three stores (a memory vector store, an entity vector store and SQLite), an LLM extraction step after each turn, and a retrieval score that blends vector similarity, BM25 keyword overlap and an entity boost. The walkthrough of retrieval scoring is clear and unusually concrete. It is thinner on what makes memory hard in practice: updating and deleting facts, which it promises at the start and never covers.

The video sorts agent memory into three layers (a knowledge layer, built-in memory, and an external memory provider) and then installs two providers for the Hermes agent: Mnemosyne, a local SQLite layer, and Hindsight, a server-backed engine run in Docker with a local GPT-OSS 20B model. The layering is a useful mental model and the install notes save real time. The evaluation is a single 'who am I' recall test, so it cannot tell you which provider actually remembers better.

The video draws one diagram of an agent memory system: a working context fed by procedural memory in skill files, semantic memory of durable facts, and episodic memory of dated events, with a summariser that distils episodes into facts every so many conversations. The layering is a good mental model for beginners. It stops before the hard parts: updating or deleting facts that change, deciding what to store, and checking that retrieval works.

IBM's explainer maps the CoALA framework's four memory types onto today's agents: the context window as working memory, CLAUDE.md-style files as semantic memory, SKILL.md skills as procedural memory and distilled session notes as episodic memory. It is a clear, accurate starting taxonomy with good concrete examples. It blurs semantic and procedural memory, says little about retrieval once memory outgrows a file, and names forgetting as the hardest problem without offering any approach.

An Anthropic product manager explains memory in Claude Managed Agents, which stores agent memory as files the model edits with bash and grep, and launches dreaming, a batch job that reviews recent session transcripts and proposes a cleaned-up memory diff. The design choices are sound, especially read-only versus read-write stores, optimistic concurrency and version history. The talk is a launch, though, so the results are customer-reported and the hard problem, bad learnings spreading through shared memory, gets little attention.

The Syntax video shows Beads, a git-backed issue tracker for coding agents, as the fix for to-do lists that vanish when a session ends. The demo covers setup, dependency-aware task selection with bd ready, a terminal board, and a strong workflow that turns Sentry errors with root-cause notes into agent tasks. It is a good tool demo, but the title oversells it: Beads gives an agent durable task memory, not memory of facts, decisions or what it has read.

AI Jason argues that agents start every session from zero and shows a fix: a second knowledge agent that reads each conversation, extracts facts and advice into a vector database, and retrieves them on later turns. He backs it with MemGPT, the CLIN research agent and a short AutoGen teachable-agent demo. The extract-store-retrieve pattern is still the core of agent memory, but the video skips how memories get corrected, scoped per user or checked, and the AutoGen code is dated.

Theo argues that automatic memory in Claude Code does more harm than good for coding, and backs it with an audit of his own machines: 45 memory files in one project, most stale, and memories written about three times as often as they were read. His alternative is a deliberate stack: fix problems in the architecture first, then in lint rules and CI, then in a hand-written AGENTS.md. The diagnosis is solid for code; the conclusion is weaker for knowledge that does not live in a repo.

The AI Automators walk through a talk by Claude Code creator Boris Cherny and push back on parts of it. The headline advice is not really to delete CLAUDE.md for good but to strip prompts, skills and hooks every few months and see what the newer model does without them. The video's best addition is the line between instructions a model can outgrow and enforcement you must keep. It misses a second line that matters just as much: project facts the model can never infer.

Anthropic's short guide treats the context window as Claude Code's working memory and gives a handful of habits: compact when continuing a feature, clear when starting a new one, check usage with /context, put lasting facts in CLAUDE.md, write specific prompts, disable unrelated MCP servers and use subagents for lookups. The advice is correct and worth following. It is thin on the main risk it names, that compaction can drop details, and on what to do before that happens.

The video sorts Claude Code memory tools into six levels, from the built-in CLAUDE.md and auto memory up to a shared Postgres store that any AI tool can query. Its core frame, that every system differs only in where memory is stored and how it gets into context, is correct and useful. It never measures retrieval quality, and it underplays the cost of injecting memory into every prompt.

Chase explains how Claude Code's auto memory stores notes as markdown files behind a MEMORY.md index, why that store fills up with duplicates, contradictions and stale dates, and how the /dream pass cleans it. He then rebuilds /dream as a custom skill from a publicly shared prompt. The explanation of the memory layout is clear and useful. His verdict that cleanup has no real downside is too relaxed: an automatic pass that merges and deletes memories needs version control and a human look at the changes.

The video argues that every line in CLAUDE.md costs instruction-following quality on every prompt, so the file should be short and hand-written. It recommends three sections (a one-line project summary, key commands and caveats) and moves everything else into referenced docs, path-scoped rules and hooks. The advice is sound; the numbers behind it are rough, and the case against /init is stronger than it needs to be.

Alex from GritAI Studio gives a compact, accurate tour of CLAUDE.md: generate it with /init, understand which memory files load and in what order, split rules into .claude/rules with path patterns, and save lessons after every hard debugging session. It is a solid starting checklist. Its favourite workflow, logging every rabbit hole into project memory, works against its own advice to keep the file short, and the video overstates how reliably a memory file prevents repeat bugs.

The video shows how /init scans a Next.js codebase and writes a CLAUDE.md file that Claude Code reads at the start of every session, then tests whether Claude follows it. The demo is clear and the advice to keep the file current is right. It underplays the most visible lesson of its own demo: CLAUDE.md is guidance the model may stretch, not a rule it must obey.

Jeff Su sorts AI memory into three levels: account-wide global memory, project memory, and a file-based system you own, run through agent tools such as Claude Cowork. His explanation of why built-in memory is thin on purpose is the clearest part. His level three setup is sound, but it is a workflow for one person's projects, and it still depends on the AI writing good notes.

IBM's video names four ways a long-running agent's context goes bad (poisoning, distraction, confusion and clash) and pairs each with a fix: validate, compact, curate and prune. The taxonomy is clear and the running example of a database-driver migration agent makes it concrete. The fixes are right in direction but thin on how to do them, and moving notes into files only helps if what gets written there is checked.

The video defines context engineering as shaping everything a model sees at inference time, not just the prompt, and argues that more context often makes agents worse. Its checklist of relevance, structure, timing and compression, plus the ongoing work of keeping context current, is a sound framework. It stays abstract: it names no techniques, shows no failure and leaves out how you would measure any of it.

IBM's video weighs RAG against putting whole documents into a long context window, with three arguments for each. Its conclusion is sound: long context for a bounded set of documents that needs global reasoning, retrieval for large and changing collections. It frames the choice as either-or, though, and most real systems now combine the two or let an agent search with tools.

Lance Martin of LangChain sorts context engineering for agents into four moves: write context outside the window, select what to pull back in, compress what stays, and isolate work into separate contexts. The framework is a useful checklist and the examples from Claude Code, Anthropic's research agent, Windsurf and Hugging Face are well chosen. It undersells the costs: every strategy trades tokens for risk, and the talk gives you no way to decide which one to use first beyond running evals.

Computerphile explains retrieval augmented generation as adding real text to the prompt so the model paraphrases sources instead of recalling facts from its weights, and demos it with LangChain, Ollama and Llama 3 70B on a Wikipedia page. The prompt-template part is clear and correct. But the demo picks the page by hand, so it shows context stuffing rather than retrieval, and it never covers chunking, embeddings or ranking, which are where real RAG systems succeed or fail.

IBM Research's Marina Danilevsky explains RAG as adding a content store that the system queries before the model answers, so responses can be current and cite a source. The two problems she names, stale answers and no source, are the right ones, and her warning that a weak retriever can make answerable questions go unanswered is the most important line. The video predates most practical RAG work, so it says nothing about chunking, embeddings, ranking or how to test retrieval.

The video argues for treating an Obsidian vault as a plain-file backend that agents read and write, rather than a notes pile you never revisit. Its best ideas are a hard split between human and machine folders, an agents file in every folder, and metrics written by scripts instead of the model. The rules are enforced only by instructions, one rule contradicts another, and the dashboard shown is a paid add-on.

Ray Fu walks through an LLM wiki in the style Andrej Karpathy described: Claude Code reads a read-only folder of raw sources and maintains a linked markdown wiki in Obsidian, steered by a CLAUDE.md schema and three identity files. The folder rules and the index-first lookup are sound. But the headline accuracy claim has no method behind it, the key prompts sit behind a link, and the habit of saving AI answers back into the wiki can compound errors unless sources stay the ground truth.

Nick Saraev describes the company knowledge base he calls Engram: connectors pull new data every 15 minutes, a cheap model writes summaries and "atoms" for each item, everything is date-stamped and recency-weighted, and Claude searches it with BM25. The pipeline is practical and mostly right. His claim that this means you do not need RAG is a labelling mistake, since keyword retrieval feeding a prompt is still RAG, and BM25 alone has blind spots his summary step only partly covers.

The video shows how to turn a folder of notes into an LLM wiki that Claude Cowork reorganises and indexes every night, viewed through Obsidian. The core idea, a maintained index the AI reads instead of rescanning every file, is sound and comes from Andrej Karpathy. The how is mostly hidden in a pasted prompt, and the video says little about cost, errors or what "self-improving" really means.

Nate Herk lays out five levels of a Claude Code knowledge setup, from a routed CLAUDE.md over markdown folders up to semantic search, knowledge graphs and an always-on agent, and argues you should pick the lowest level that removes a real pain. That advice is sound, and his warning about chunked vector search losing whole-document context is the most useful part. The levels mix up storage and retrieval, though, and the claim that plain files work with any AI tool only holds for tools that can read your disk.

Nick Milo shows how he points Claude Cowork at his Obsidian vault through a small translation layer: a me.md identity file, a vault map, a skill map and a one-line CLAUDE.md that redirects to me.md. The core idea, keep your identity, maps and skills as plain files you own and rent the AI on top, is right and easy to copy. The portability is less complete than he suggests, the privacy claim needs checking against current settings, and a fair part of the video promotes his paid product.

The video argues that the filing and linking work of PKM can now be handed to an AI agent inside your Obsidian vault, so your job shifts to giving that agent good context: who you are, your voice, your decisions. The reframe from knowledge to context is useful, and the vault tour shows a sensible set of files. But it never names the agent or shows it working, and it treats maintenance as free when it is really delegated and still needs review.

Wanderloots shows how to turn an Obsidian vault into an LLM wiki: raw sources that never change, a compiled wiki the agent writes, and a schema layer (agents.md, templates, skills, a Python tool) that keeps the agent consistent. The structure is sound and the Git plus lint discipline is the best part. The vault firewall is weaker than it sounds, and the claim that this beats RAG is asserted rather than tested.

Matt Wolfe walks through building Andrej Karpathy's LLM wiki pattern in Obsidian, driven by Codex, then adds a journal and a contacts file on top. The core idea is sound: keep raw sources immutable, let an agent compile them into linked pages, and steer it with one instructions file. The build is a good starting point, but it skips cost, review and retrieval limits that show up once the vault grows past a few dozen sources.

The video teaches a two-layer Obsidian vault for Claude Code: a top folder where Claude helps you plan with your goals, notes and journals, and a separate vault per project where Claude only sees that project's files and skills. The scoping idea is sound and the setup steps are concrete. It glosses over permissions, privacy and what happens when the vault grows, and about eight minutes are a demo of the creator's own app.

Tom from ICOR builds a personal knowledge setup live from an empty folder: Claude Code in a terminal, a CLAUDE.md orchestrator, agent files, two inbox folders, a SQLite database and a plain HTML viewer. The core idea, owning your data as files and swapping the AI that works on it, is sound. The claim that notes apps are finished is overstated, and his point that Obsidian files only work in Obsidian is wrong.

Nate B Jones lays out a no-code capture loop: dump every thought into one private Slack channel, let Zapier send it to Claude or ChatGPT for classification, file it into four Notion databases, and get a daily and weekly digest back in Slack. The design principles behind it, especially the confidence threshold, the audit log and separating memory from compute and interface, are sound and widely useful. It is a task and relationship tracker more than a knowledge base, and a few pieces, like the one-reply fix button, are harder to build than the video suggests.

Nick Milo's crash course covers what an Obsidian vault is, how links and backlinks work, two settings to change on day one, the common beginner mistakes, the core hotkeys and his ACE folder scheme. It is an accurate, efficient tour for a new user. Its advice not to import old notes is too absolute, and its short AI section leaves out most of what matters when you connect an assistant to a vault.

Nick Milo argues that AI should be kept out of your own notes but used in narrow ways around them, and shows Claude Code reading his Obsidian vault and writing its output into a separate AI-only vault. The separate vault is a smart, cheap rule worth copying. His privacy framing is too generous: Claude Code sends your note contents to a cloud model, so the setup is only as private as your account's data settings.

Mike Schmitz shares ten lessons from five years of daily Obsidian use, and the best of them are about restraint: start with one workflow, capture elsewhere, keep only about 10% of what you capture, and always make something from your notes. Most of the advice holds up. The "keep what resonates" filter and the one-vault rule are personal preferences presented as rules, and they deserve more caveats than the video gives them.

Andrew Adriance argues that a personal knowledge base only has value when it serves something you are trying to make, and that collecting notes for their own sake is hoarding. The core test he offers is sound and worth adopting. His history is shakier: Luhmann's slip box was a deliberate tool he designed, not just a side effect of passion, and the useful lesson is to design notes around output from day one.

Sam Matla argues that for most people, personal knowledge management in tools like Obsidian, Roam and Logseq turns into procrastination that feels like progress. His fix is five rules: one tool for six months, trust your own thinking, take notes per project, build work capacity before structure, and cap time spent on the system. The diagnosis is sound and the project-based rule is the strongest. The advice is weaker on when switching tools is justified and on how to measure whether a system helps.

Ali Abdaal walks through Tiago Forte's CODE method (Capture, Organise, Distil, Express) using his own Apple Notes setup. The strongest advice is to file notes by the project you will use them for, not by topic or source, and to keep several projects simmering at once. The video is thin on the hard step, distilling, and its opening statistics are shaky, but the core habits still hold, and better search has made his low-effort filing style more defensible since the 2022 upload.

Vicky Zhao gives a clear, short introduction to the Zettelkasten: capture fleeting notes, write literature notes in your own words, then turn them into atomic, self-contained permanent notes linked to each other. The note rules are sound and worth following. The history is blurred: the three note types come from Sönke Ahrens' modern retelling, not Luhmann, and the video leaves out the numbering and linking scheme that made Luhmann's boxes work.

Martin Adams sets up a Zettelkasten in a new Obsidian vault with three folders (fleeting, literature, permanent), two templates, a map of content and a project draft that embeds permanent notes. It is a clear, practical walkthrough of the mechanics. It also bends the method in ways worth knowing: fleeting notes become stores of article highlights, permanent notes are titled as topics rather than ideas, and the folder layout creates duplicate note names.

Shu's short video explains the Zettelkasten workflow as four kinds of notes: brief literature notes in your own words, bibliographic cards, permanent notes connected to what you already know, and fleeting notes reviewed within days. The workflow is accurate and the advice on choosing keywords for retrieval is the best part. It leaves out the feature that made Luhmann's system distinctive, fixed card numbers with branching sequences, and it overstates how simple the method is to sustain.

This 2019 talk is the early version of Tiago Forte's method: save what you read into one notes app, connect notes with tags and links, and use them to make things. The core advice still holds, especially the 30-second capture test and the idea that you only know what you make. The tool list has aged, the statistics are loosely sourced, and his claim that personal knowledge is not an AI problem reads very differently today.

Nick Milo walks through NotebookLM's three panels (sources, chat, studio), eight practical tips and two common mistakes, then shows how he uses it as a short-lived research layer in front of his Obsidian vault. The tour is accurate and the advice to keep notebooks narrow and to treat NotebookLM as a literal researcher is sound. He overstates how far citations remove hallucinations, and he skips the cost of notebooks being separate silos.

Jeff Su's tutorial teaches NotebookLM through real notebooks: health reports, equipment manuals, tax, recruiting, projects and earnings analysis. The practical tips are accurate and useful, especially selecting sources deliberately and saving answers as notes so they are not lost. Two things need care: his size comparison with ChatGPT and Claude mixes up retrieval and context windows, and a cited answer is only as reliable as the source it cites.