Notion MCP: Turning Your Workspace Into Claude's Memory

The Notion MCP server is the short answer to a long-standing founder frustration. You have been writing things down in Notion for two years. The meeting notes are there. The decisions are there. The client playbook you rewrote in January is there. But when you ask Claude a question about your business, it has no idea any of that exists, and you end up copy-pasting pages into the chat every single time. The Model Context Protocol fixes the connection. What it does not fix is the structure underneath.

This is the piece most guides skip. Plugging Notion into Claude is a fifteen-minute chore. Arranging your Notion so that Claude can actually find the right page, read only what it needs, and give you a grounded answer is the real work. Founders who skip it end up with an assistant that pulls the wrong meeting notes and cheerfully fabricates a decision you never made. Founders who do it well end up with something closer to a chief of staff who has read every document in the company and can cite it.

What follows is the workspace blueprint we use and install for clients. Four top-level pages, a consistent schema on every page, a three-part tagging rule, and a pattern of prompting Claude that keeps context lean. It requires discipline about where things live and how they are labelled.

Why a Notion workspace is Claude's best long-term memory

Claude's own memory is short. A single conversation holds a lot of context, but close the window and it is gone. Anything the assistant needs to know across sessions has to live somewhere outside the model. Founders typically try three options. They keep a long prompt with company facts glued to the top of every chat, which rots within a month. They use Claude's project feature, which is good for reference files but not for things that change weekly. Or they connect a Notion workspace through MCP and treat it as the source of truth.

The last option wins for three reasons. Notion is already where most founders write, so you are not creating a second system. Notion has structured search, so Claude can query it rather than receive a dump. And Notion is editable by Claude through the MCP's update and create tools, which means the memory updates itself when you and the assistant agree on something new. A decision made in chat can be written to Notion the same turn, and retrieved the next week when you forget why you made it.

The catch is that Notion only becomes a good memory if it is structured for retrieval. A workspace with three hundred pages scattered across fifty sub-pages and inconsistent tags is indistinguishable from no memory at all, because Claude's search returns noise. The structure is what converts raw Notion into queryable memory.

The four top-level pages, and nothing else at the root

The first rule is brutal. Your Notion sidebar has exactly four top-level pages. They are called Projects, Contacts, Decisions, and Playbooks. Every other page in your workspace lives underneath one of those four. Nothing else sits at the root. No "Ideas" page, no "Inbox", no "Personal", no "Archive". If it matters to the business, it has a home under one of the four. If it does not matter, it does not belong in the business workspace.

Projects holds time-bounded work. A client engagement, a product launch, a fundraising round, a hiring sprint. Each gets its own sub-page. When the project ends, it stays where it is but its status tag changes. Contacts holds people. Every client, investor, advisor, contractor, and interesting stranger gets a sub-page with the same schema. Decisions holds the big choices you have made and why. Playbooks holds the reusable how-to content that does not belong to any specific project.

The reason this taxonomy works for Claude is that it maps to the questions founders actually ask. "What is the status of the Acme project" goes to Projects. "When did I last talk to that lawyer" goes to Contacts. "Why did we pick Stripe over Paddle" goes to Decisions. "How do we onboard a new client" goes to Playbooks. Claude's search does not have to guess where information lives because there are only four directions to look, and each has a clear purpose.

The common objection is that four pages feel restrictive compared to a fully-branched hierarchy. The restriction is the point. Hierarchies expand to fit the person making them, which means every user ends up with a bespoke mess that only they can navigate. Four fixed buckets are navigable by anyone and, crucially, by a language model that has never seen your workspace before.

The page-schema every page needs at the top

Structure at the sidebar level is half the work. The other half is structure inside each page. Every single page in the workspace, regardless of which of the four parents it lives under, begins with the same property table. We call this the page-schema, and it is the difference between Claude returning a useful search hit and returning a page it cannot interpret.

The schema has five properties. Owner is the person responsible for the page, written as a single name so the tag system can match on it. Status is one of four values: active, paused, done, or archived. Project-slug is a short hyphenated identifier for the project the page belongs to, such as acme-onboard or q4-launch, and it stays the same across every page that relates to that project. Last-updated is a date that you bump whenever you edit the page meaningfully. Summary is two sentences, written in plain prose, that describe what the page is about.

The summary line is the hardest habit to build and the one that pays off most. When Claude searches Notion, it sees the title and the summary first. A good summary lets the assistant decide whether a page is relevant without reading the body. A missing or lazy summary forces Claude to fetch the whole page, which burns context and slows everything down. Two sentences, front-loaded, written as if for a colleague who has never heard of the project.

You can implement the schema as a Notion property table at the top of the page, or as a fenced YAML-style block that you type manually. The property-table version is nicer to look at and plays well with Notion databases. The typed block version is portable between workspaces and survives copy-paste cleanly. Either works. What matters is that it is in the same shape on every page, because Claude will learn to look for it.

The three-part tagging rule

Notion's tag fields are free-form by default, which is a problem. A founder who tags one page "client" and another "customer" and a third "acme client" has three separate tags in Notion's eyes, and neither a human nor Claude can cleanly filter across them. The fix is a tagging rule with exactly three parts, always applied in the same order.

The first tag is the project-slug, the same hyphenated identifier that appears in the page-schema. Acme-onboard, q4-launch, seed-round. The second tag is status, drawn from the same closed vocabulary as the status property: active, paused, done, or archived. The third tag is the owner's name. Three tags, no more, no less, and in that exact order.

The reason the order matters is that Claude's search returns tag lists as strings, and a consistent string pattern is easier for the model to parse than a random one. When every tagged page reads "acme-onboard, active, sara", the assistant can reliably infer which project, which state, and whose desk it sits on. When the tags are in random order or use inconsistent vocabulary, the assistant has to work harder and gets it wrong more often.

A useful side effect of this rule is that you can now ask Claude to run workspace-wide queries that would be tedious by hand. "Show me every active page owned by Sara" becomes a single prompt. "List every project with status paused for more than thirty days" becomes another. The tag structure turns Notion from a pile of documents into something closer to a database you can interview.

The search then read pattern that beats pasting

The most common mistake new MCP users make is to treat Claude like a human reader. They open a Notion page, copy the URL or the whole body, and paste it into chat with a question. This works for a single page but breaks the moment the question touches anything the founder has not already found. It also burns through the context window on a page the assistant may only need one paragraph of.

The pattern that actually works is search then read. You give Claude a question in natural language, without pre-selecting a page. The assistant uses the Notion MCP's search tool to find candidate pages, reads the summaries in the page-schema, picks the most relevant one or two, and only then fetches the full body. The founder sees the whole chain in the chat: which search terms were used, which pages came back, which summaries were scanned, which body was read. Every step is auditable.

The shift feels unnatural at first because it means typing less context into the chat. You have to trust that the workspace is well enough structured that Claude can find what it needs. This trust is earned gradually as the page-schema and the tagging rule prove themselves. Within a few weeks, pasting starts to feel as antiquated as copying a URL into a browser instead of clicking the link. You stop doing Notion's job for it.

A prompt template that trains this pattern, for founders who want one, is roughly this. Ask Claude to search Notion for the topic, list the top three hits with their summaries, state which it thinks is most relevant and why, and only fetch the full page after you confirm. The extra step takes fifteen seconds and saves you from the class of error where the assistant confidently quotes the wrong document.

Decision pages, the highest-leverage surface

Of the four root pages, Decisions is the one founders underinvest in and the one that repays structure most. Most founders do not write decisions down. They make them in a meeting, send a Slack message, and move on. Six months later someone asks why the company picked vendor A over vendor B, and nobody remembers the real reasoning, only the outcome.

A decision page has its own schema on top of the standard one. Context is two or three sentences describing the situation that forced the decision. Options lists the real alternatives that were considered, not just the chosen one. Choice is the one-sentence answer. Reasoning is the why, written plainly, including the tradeoffs you accepted. Date is when the decision was made.

The magic of decision pages is that Claude becomes extraordinarily good at answering "why" questions about the business. Why are we on Stripe. Why did we skip SOC 2 this year. Why is the pricing page structured around seats rather than usage. These are questions that would normally require the founder to be in the room, or at least on a Zoom call. A well-maintained Decisions folder answers them in one search, with citation back to the original reasoning.

The discipline is to write the decision page at the moment the decision is made, not later. Claude itself can help with this. After a conversation where you and the assistant work through a choice, ask it to draft the decision page in the correct schema and create it via the MCP. The decision becomes part of the memory the same turn you make it.

Playbooks versus projects, and why the distinction matters

The last structural rule is the one that most often gets broken once the system has been running for a few months. The distinction between a playbook and a project is always the same: playbooks are reusable, projects are time-bounded. The playbook for onboarding a new client lives in Playbooks. The actual onboarding of Acme Corp, which uses that playbook, lives in Projects.

Conflating the two is the single biggest reason Claude pulls irrelevant context. When the Acme onboarding notes are filed under Playbooks because "that is where onboarding lives", every future onboarding project finds them and assumes they are the template. When the generic onboarding playbook is filed under Projects because "we are using it for Acme right now", the next client finds Acme-specific details in the template. Both failure modes pollute retrieval.

The rule of thumb is that anything written in second person ("you") or imperative ("send the welcome email") belongs in Playbooks. Anything written in past tense ("Sara sent the welcome email on Tuesday") belongs in a project page. If a page contains both, split it. The fifteen minutes of splitting pays back every time Claude searches the workspace afterwards.

A weekly hygiene pass that keeps recall sharp

A structured workspace decays without maintenance. Pages get written without the schema. Tags drift into new vocabulary. Status stays on "active" for projects that shipped two months ago. The hygiene pass is a fifteen-minute weekly ritual that keeps the system honest. Friday afternoon is the traditional slot.

During the pass, you do four things. You walk the Projects folder and update any status tag that no longer reflects reality. You skim the top of every page you edited that week and confirm the summary line still describes what the page is now about. You archive anything with status=done that is older than thirty days by flipping it to archived, which keeps it searchable but out of the active set. And you glance at Decisions to make sure every meaningful call from the week was written down. Anything missing gets drafted with Claude's help and filed.

Fifteen minutes a week. That is the maintenance cost of an AI memory that actually works. The alternative is pasting pages into chat forever. -> WitsCode Notion structure engagement.