One brain.
Every AI tool.
Context101 is a self-hosted MCP knowledge base for teams that want Cursor, Claude, Devin, and internal agents to retrieve from the same approved context. It is alpha software, designed to be deployed into your own AWS account.
So now
Deployable app, not this homepage
The website and app are separate.
This site explains the project. The deployable product lives in web/ and starts directly in the authenticated app. That keeps self-hosted deployments focused on the knowledge base instead of shipping a marketing homepage to every internal team.
One shared context layer
Teams write and approve knowledge once, then expose it through MCP to Cursor, Claude Desktop, Claude Code, Devin, and custom agents.
Multiple isolated brains
Create separate brains for teams, projects, or customers. Each brain has its own docs, sources, suggestions queue, and MCP bearer token.
Self-hosted in AWS
The deployable app is CDK, S3, Bedrock Knowledge Bases, S3 Vectors, DynamoDB, Lambda, Amplify, and a FastMCP service.
Alpha by design
Built from a real internal PoC. Useful today for trusted teams, but not hardened for hostile tenants or managed multi-tenant hosting.
Write once. Retrieve from everywhere.
The motion is the system: sources flow into one brain, and every MCP client reads from that same approved context.
- Google Sheets
- Google Docs
- Google Slides
- Notion
- GitHub
- Markdown
- ConfluenceSoon
- PDFsSoon
- Cursor
- Claude Code
- Claude Desktop
- Devin
- Your agent
A generated wiki, not just raw search.
Context101 can synthesize the raw files in a brain into a readable wiki: topic pages, source citations, and architecture notes that agents can retrieve before falling back to raw docs. The goal is to give teammates a shared, reconciled view instead of a pile of disconnected chunks.
Reconciled pages
The wiki generator groups related files into human-readable pages with citations back to the source material.
Manual refresh
Regeneration is intentionally operator-controlled today so teams can manage Bedrock cost and review behavior as data grows.
Current caveat
Tested with roughly 100 documents, not thousands.
The current wiki flow was built for PoC-scale corpora. Once a brain has a lot more data, the generator needs better batching, incremental updates, source selection, and page-level caching. Search can still work at larger sizes, but the generated wiki is the part that needs more hardening.
Agents can suggest. Humans still decide.
Context101 is not just a place for humans to upload docs. MCP clients can propose new knowledge or improvements while they work, but those suggestions land in a review queue instead of writing directly into the brain.
Propose from any MCP client
Cursor, Claude, or another agent can call suggest_knowledge when it discovers a missing fact, clearer explanation, or update worth preserving.
Review before it lands
Suggestions appear in the web app with rationale, proposed content, and diffs for updates. Nothing becomes source material until a person accepts it.
Accepted changes re-index
Approved suggestions write back to S3, trigger ingestion, and become part of future search and wiki generation for that brain.
Small enough to try, real enough to use.
Useful now, honest about limits.
Context101 started as a PoC for an internal company problem. The goal of open sourcing it is to let other teams deploy and evolve it internally, not to claim it is a finished production SaaS.
Auth model
Trusted internal team model: signed-in users are admins, and per-brain bearer tokens can be revealed in the app.
Connectors
Connectors are useful but early. Google Workspace, Notion, and GitHub sync into markdown, with GitHub currently using a pasted PAT.
AWS caveats
AWS setup still has real prerequisites: us-east-1, Bedrock model access, Docker, CDK bootstrap, and provider OAuth setup for connectors.
Good to know.
A few choices are pragmatic rather than perfect. Context101 started as a PoC, so the first version optimizes for easy self-hosted deployment over architectural purity.
Why Titan embeddings instead of OpenAI embeddings?
Titan was the easiest fit for an AWS-first PoC: Bedrock Knowledge Bases can use it natively, which keeps deployment simple and avoids extra provider keys. There are likely better retrieval-quality options, and swapping embedding models is a reasonable future improvement.
Why Cognito?
Same reason: it was the path of least resistance for a CDK-deployed AWS stack. Cognito is not the dream auth product, but keeping auth inside AWS made the PoC easier to ship and easier for self-hosters to reproduce. We are open to changing it later.
Why so many AWS services?
Most infrastructure choices were made to make the stack easy to deploy from CDK, not because they are the only possible architecture. The bias was: one cloud account, managed services, minimal external setup, and no bespoke operations layer for the first version. Multi-brain support follows that model: one deployment can host multiple isolated brains.
What inspired this?
The workflow takes inspiration from Devin's agent knowledge experience and from DeepWiki-style generated documentation. Context101 applies those ideas to shared team knowledge exposed through MCP, not just repository documentation.
Credit to Devin and DeepWiki Open.