A Claude Code MCP setup built around persistent memory turns disposable AI sessions into a durable record of everything a project did. This article explains how global and project-scoped MCP servers work, how Basic Memory stores plans and decisions, and how one developer runs planning, execution, and parallel agents on top of that foundation.
What MCP servers do inside Claude Code
MCP servers give Claude Code, Anthropic terminal-based agentic coding tool, access to tools beyond the local filesystem: email, calendars, databases, and in this workflow, long-term memory. The protocol behind them is the Model Context Protocol, an open standard for connecting AI applications to external data sources and tools.
In the recorded session, the developer ran the /mcp command and saw every configured server with its scope. Some servers load in every session because they are user-level; others start only when a specific project opens. Both levels coexist, and knowing which is which matters when a tool fails to appear.
The two scopes behave differently in practice:
Global versus project-scoped MCP configuration
Global servers live in the user's home configuration file and load at the start of every session. Project servers are declared inside a repository and initialize only when that project is open, which keeps heavy or sensitive tools out of unrelated work.
A quick comparison of the two scopes as they behave in Claude Code:
Authenticating an MCP server
Servers that touch personal accounts require authorization before they work. In the session, Claude Code flagged in the corner that a server needed approval; the developer completed an email-based login, approved access, and the tool reported a successful authentication.
One practical failure followed: a second session tried to use the memory server before its own login had completed, and the save silently failed. The fix was to press Ctrl+C twice, resume the session, run /mcp to confirm the server showed as connected, and repeat the request. Checking the server status before delegating a save is the habit worth copying.
The same authorization flow applied to the Gmail and Google Calendar integrations, which the speaker used to send email and list the day's appointments directly from the terminal.
Basic Memory as a persistent second brain
Basic Memory is an MCP server that stores notes, plans, and decisions as persistent knowledge the agent can write to and search later. The speaker describes it as his second brain: every plan, debugging session, and finished feature gets saved on request.
The workflow is deliberate. After a planning session, he asks Claude Code to save the plan to a named memory project. After an intense debugging session, he saves the problems encountered, the attempts made, and the resolution. After shipping a feature, he saves the implementation details. The agent then used its memory tools, such as create_memory_project and note creation, to store a workshop plan under a new project name.
The payoff came when he opened a fresh session on a different project and asked for a brag document summarizing his January and February 2026 work. The agent queried Basic Memory across several calls and returned dated entries, including a monorepo migration spike and a January 12 refactoring, plus claimed impact numbers. Because these figures come from the speaker's own demonstration rather than an independent measurement, treat them as first-hand experience, not benchmarks.
Two caveats are explicit in the source. First, memory depends on discipline: nothing is saved unless you ask. Second, the retrieved summary can be incomplete; the speaker noted one saved document lacked details and had to request the agent fill it in.
Why planning and execution use different models
The speaker separates planning from implementation to control cost. Opus handles the planning pass; Sonnet, being cheaper, executes the resulting plan.
In the recorded flow, the plan covered 11 files, 4 modified and 7 created, with explicit steps for schema, list, form, and routes, following existing project conventions like query keys. After the plan was approved, he asked the agent to clean context, keep only the plan, create a task list, run one agent per task in parallel, and make atomic commits after each logical delivery.
One correction mattered: the agents started committing to master. He stopped them with a double Escape, instructed them to create a feature branch, and required a pull request as the final deliverable. The run produced the files, a build check, and a pull request with a meaningful title, summary, and test plan written by the agent.
Superpowers and parallel task agents
Superpowers is a plugin that bundles composable skills and initial instructions for code agents, installable in Claude Code through a plugin install command that pulls directly from its repository. When the execution phase started, Claude Code loaded one of its skills automatically.
The parallelism comes from Claude Code's task system: each task is isolated with its own start, middle, and end, and because tasks are independent, multiple subagents work at the same time. In the session, the agent described dispatching agents in waves, creating all independent tasks in parallel first and mapping dependencies. The speaker reports this as his observed experience with the tool, not a vendor benchmark.
How skills steer agent behavior
A skill is a Markdown file that gives an agent a specific capability. The format has constraints: the file must be named SKILL.md in uppercase, it sits in a folder whose name matches the frontmatter header, and the description field has to be precise, because that description is what the model reads to decide whether to load the full skill into context.
The speaker wrote his own skill to manage a recurring conflict: his fork of a containerized personal-assistant project regularly diverges from upstream, so merges collide. His skill encodes a development flow designed to make those conflicts easier for Claude Code, Cursor, or Codex to resolve. His skills carry a personal prefix to separate them from the ones bundled with the project.
He treats Claude Code as a platform rather than a one-off tool: the same agent runs in his terminal, inside the Cursor via the IDE connection, and inside a Docker container powering a Telegram assistant that answers calendar questions through the same MCP servers.
Common MCP setup mistakes to avoid
The session surfaced a handful of failures worth preempting:
FAQ
- What is a Claude Code MCP server? It is an external tool server that connects to Claude Code through the Model Context Protocol, extending the agent with capabilities such as email, calendars, and persistent memory. Servers can be configured globally for all sessions or scoped to a single project.
- How does Basic Memory persist context between sessions? The agent writes notes, plans, and summaries to named memory projects through the Basic Memory MCP server, and any later session can search and retrieve them. Saving is explicit: you have to ask the agent to store each item.
- Why did an MCP save fail in a new session? The new session had not completed authentication for the server yet. Verify the server's status with the /mcp command before requesting work that depends on it, and repeat the request once it shows as connected.
- Can MCP memory replace a changelog or resume notes? It complements them. In the recorded workflow, one query produced a dated summary of two months of work, useful for a brag document, but the record is only as complete as what was deliberately saved.
- Do MCP servers work outside the terminal? Yes. The speaker ran the same agent inside Cursor's integrated terminal, connected it to the editor's open files, and executed it in a Docker container behind a Telegram bot, with the container isolation cited as a safety benefit.
From recorded sessions to written knowledge
The core lesson of this workflow is that context is an asset: plans, decisions, and debugging history become valuable only when they are captured somewhere retrievable. Much of the same knowledge sits inside recorded videos and screencasts that never get written down.
If you explain workflows like this on YouTube, Skala Blog turns a video URL into a structured, searchable article: paste the link, transcribe the session, and edit the resulting draft.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits