First-Tree vs a Wiki / Notion (with MCP)
A wiki or Notion wired to an MCP server lets your agents fetch shared context. But MCP solves delivery — getting the context to the agent — not whether that context is canonical, owned, and reviewed. That's the gap First-Tree's git-native context tree fills, and it serves over MCP too.
"I already have a wiki — Notion, Confluence, whatever — and if I front it with an MCP server, my agents have shared context. So why do I need First-Tree?" It's one of the most common, highest-intent objections, and it deserves an honest, technical answer rather than a handwave. The short version: MCP and a wiki are real and useful, but they solve delivery, not the context problem itself. First-Tree solves the part that's left — and it composes with both.
First, the category error: MCP is a protocol, not a store
The most important thing to get right is that MCP (Model Context Protocol) is a transport protocol, not a storage layer. An MCP server is a standardized way for an agent to fetch context — and that server can front anything: a wiki, a database, a search index, or a Git repo. MCP standardizes the connection. It has no opinion about what flows through it.
So the real-world stack people describe is "MCP + a wiki": MCP solves how the agent gets the context, and the wiki is where the context lives. That's a genuinely good delivery setup. But notice what it doesn't touch: whether a given page is the one your team actually stands behind, who's accountable for it, whether anyone reviewed the last edit, or whether a paragraph quietly went stale six weeks ago. MCP can't fix any of that, because none of it is a transport question.
MCP is the connection. First-Tree is what's worth connecting to.
If your context is flat and ownerless, serving it faster over MCP just gets your agents to the wrong-or-stale answer more efficiently. The fix isn't a better connection — it's giving the context structure, ownership, canonical status, and review. Then serve that over MCP.
What a wiki (Notion / Confluence) does well — and where it breaks for agents
A wiki is excellent at what it was built for: humans browsing and
editing prose. It's searchable, linkable, and low-friction. For a
solo developer or a single repo, a wiki — or even a CLAUDE.md —
is often all the shared context you need. We'll come back to that honestly.
The trouble starts when a team of agents has to depend on it. Wikis are flat, and ownership stops at the page, and that has concrete consequences for agent context:
- No canonical signalThree pages can answer "how we do auth," all different ages — and nothing tells an agent which one your team actually stands behind.
- Ownership the agent can't seeA page may have an owner, but the agent reads the text, not the governance process. There's no review gate before the agent consumes a change.
- No review / version controlEdits land live. There's no pull request a node owner approves, and no real diff history agents (or you) can reason about.
- No regression test for stalenessA paragraph that drifted out of date has nothing that fails. It just keeps feeding agents a confidently wrong answer.
Add an MCP server in front of all that and the failure modes don't go away — they get faster. Your agents now fetch the same flat, unreviewed context with less latency. Delivery improved; trust didn't.
What First-Tree does: a git-native context tree
First-Tree's answer to "shared context for AI agents" isn't another doc store — it's a git-native context tree: every node is a plain Markdown file in Git, so the properties a wiki lacks come from your repo for free.
- Canonical, structured nodesKnowledge is a tree of nodes with explicit canonical status — one authoritative answer per concept, not a pile of competing pages.
- Owners in the repoEach node has an owner — human or agent — accountable for keeping it true. Agents read it knowing someone stands behind it.
- PR review + historyEvery change is a pull request a node owner reviews before agents consume it — with the full version history Git already gives you.
- Served over MCPThe same tree can be exposed through an MCP server — so agents fetch trustworthy context through the standard protocol they already speak.
That last point is the whole reconciliation: First-Tree doesn't replace MCP, it gives MCP something worth serving. The protocol delivers; the tree is what makes the delivered context canonical, owned, and reviewed.
Wiki + MCP vs First-Tree, side by side
| Dimension | Wiki / Notion + MCP | First-Tree |
|---|---|---|
| What it solves | Delivery — how the agent fetches context | The context itself — structure, trust, ownership |
| Structure | Flat pages | A tree of canonical, owned Markdown nodes |
| Canonical signal | None — any page can claim anything | Explicit canonical status per node |
| Ownership | Page-level at best; agents read text, not owners | Node owners accountable in the repo |
| Review & version control | Edits land live; no PR gate | Every change is a reviewed pull request in Git |
| Storage | The wiki's own database | Plain Markdown files in your repo |
| Staleness | No test fails when a paragraph drifts | Drift surfaces through Git review & history |
| MCP | Fronts the wiki (transport only) | The tree is served over MCP too |
| Best for | Solo / single repo / human browsing | Teams of humans + agents across many repos |
Read the table fairly: the wiki-plus-MCP column is a perfectly good delivery setup, and for human reading it's often better than a repo of Markdown. The First-Tree column is about a different property — whether the context an agent depends on is canonical, owned, and reviewed. They answer different questions, which is exactly why they compose.
When you do NOT need First-Tree
To be honest about the boundary: if you're solo, on a single repo,
and your agent does fine reading a CLAUDE.md or a few Notion
pages, you don't need First-Tree. A wiki — with or without MCP —
is the right amount of structure for that scale, and adding a reviewed,
owned context tree would be overhead you don't get paid back for. Use the
wiki.
First-Tree starts earning its keep at the point where flat context becomes a liability: a team of humans and agents, multiple repos, and parallel agents producing inconsistent output because they each read a different (or stale) page and nobody owns the canonical answer. That's the threshold. Below it, keep what you have. Above it, the wiki's flatness is the thing generating your reconciliation work.
How they fit together in practice
The intended setup isn't "rip out the wiki." It's layered:
- Keep the wiki for humansNotion / Confluence stays great for long-form browsing, onboarding docs, and prose nobody needs an agent to depend on verbatim.
- Put agent-critical context in the treeDecisions, ownership, conventions, and canonical answers go in the git-native context tree — Markdown in Git, owned and reviewed.
- Serve the tree over MCPExpose the tree through an MCP server so agents fetch trustworthy context through the standard protocol they already use.
The result: MCP keeps doing what it's good at — being the standard connection — and your agents stop drinking from a flat, ownerless source. This is the same shift behind running real AI agent teams, where consistent output depends on every agent reading one owned, reviewed memory rather than reconciling three pages after the fact.
If you've already done the work of standardizing on MCP, that's not wasted — it's the delivery half of the answer. First-Tree supplies the other half: the orchestration and shared context layer that makes what you serve over MCP something a team of agents can actually trust. See also how the same problem shows up when a framework builds one agent but leaves the team's shared memory unsolved.