Arkon: A Self-Hosted MCP Knowledge Server With a Plan-Review Ingestion Pipeline
Arkon: Enterprise AI Knowledge Hub & MCP Server. Self-hosted knowledge base for teams to manage RAG contexts, access policies, and AI skills. Connect Claude and other LLMs via Model Context Protocol (MCP) for automated, secure organizational knowledge integration.
At a glance
- What is it?
- Arkon compiles internal documents into a scoped wiki and serves it to Claude over Model Context Protocol. The interesting part is the ingestion pipeline and the licence, not the feature list.
- Who is it for?
- Adopt Arkon if you have a platform team willing to run seven containers and a legal team willing to read the PolyForm Internal Use licence before signing off. Do not adopt it if you need per-seat commercial pricing, a managed service, or a knowledge base that stays useful without an LLM in the loop.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 104 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Arkon is aimed at: pasted context and no permission boundary
The README opens with a specific complaint. Employees copy documents into chatbots, which produces inconsistent context, security exposure, and duplicated effort. That is a real pattern in organisations where the wiki lives in one place and the AI client lives in another, with a human acting as the transport layer.
Arkon's answer is to make the AI client a consumer of the wiki rather than a recipient of pasted text. The project describes itself as a self-hosted knowledge management layer that runs as a centralized MCP server. The intended user is not an individual developer. It is an organisation with departments that should not see each other's documents, and an administrator who wants one endpoint instead of a per-employee configuration exercise.
The scoping model is the part that separates it from a personal knowledge base. Departments get their own wiki, document set, and rosters. A global scope holds company-wide material. The README states that scope is enforced at the API, MCP, and search layers, which is the claim worth checking in code if you are evaluating it for a regulated environment.
The MRP pipeline: plan, review, then write
Most retrieval systems chunk documents and index the chunks. Arkon takes a different route. The README describes an MRP pipeline whose expansion is Map, Reduce, Plan-review, Refine, Verify, Commit, and it produces a wiki of interlinked pages rather than a pile of embeddings.
The mechanism that matters is the review gate. Ingestion generates a plan listing which wiki pages will be created or updated, and an editor can regenerate that plan with feedback before any page is written. That is a deliberate slowdown. A pipeline that writes directly is cheaper to operate and harder to audit; Arkon chooses the audit trail. When a new source touches an existing page, the content is merged by an LLM rather than overwritten, and each page records the source documents it was compiled from. Vision captions are inserted into source text before compilation so images land in the right places.
The README also claims drafts persist mid-pipeline so a crashed run resumes without repeating the expensive LLM work. That is a design decision with a cost: it implies draft state in the database that has to be managed and eventually cleaned up. The documentation supplied here does not describe a retention policy for abandoned drafts, and that is a gap worth raising before a long-running ingestion job is left unattended.
The pipeline is also the reason for the hardware guidance. A note in the README says RAM is the primary bottleneck because MRP pipeline workers load large LLM context windows into memory. A knowledge base that compiles pages will need more headroom than one that only embeds chunks.
What the MCP server actually exposes to Claude
Arkon connects to Claude Desktop or Claude.ai over OAuth 2.1 with PKCE. The README's description is that a user adds the server URL and signs in through the browser, with no manual token copying. The MCP layer is built on FastMCP.
The tool surface is grouped into four areas. Wiki tools include search_wiki, read_wiki_page, list_wiki_pages, and read_wiki_index. Source drill-down includes get_source, get_source_outline, get_source_pages, and list_sources, which lets a model move from a compiled page back to the document it came from. The edit workflow includes propose_wiki_edit, edit_wiki_page, list_pending_drafts, review_draft, approve_draft, and reject_draft. Discovery includes list_knowledge_types and get_knowledge_type_docs.
Two things stand out. First, the edit tools are exposed over MCP, which means a model can propose changes to the wiki, not just read it. The approval step is what keeps that from being reckless, and the README says every privileged action lands in an audit log alongside settings changes and role updates. Second, the README states that all tools enforce per-token scope across department, knowledge type, and source list. That is the correct place to enforce it. A filter applied only in the search UI would be bypassable by any client holding a token.
Getting it running: seven containers and a licence check
The README does not include a docker compose command or an installation walkthrough in the material available here, so the exact bootstrap sequence cannot be given. What it does specify is the shape of the deployment: seven Docker containers covering PostgreSQL with pgvector, Redis, MinIO, the FastAPI API, two ARQ workers, and a Next.js frontend. Deployment is described as on-premises or private cloud via Docker, with a reverse proxy such as Nginx or Caddy and SSL recommended for production.
Hardware guidance is given as a table. Starter covers 1 to 20 people with 2 vCPU, 4 GB RAM, and 40 GB SSD. Team covers 20 to 100 with 4 vCPU, 8 GB RAM, and 100 GB SSD. Enterprise covers 100 or more with 8 or more vCPU, 16 or more GB RAM, and 250 or more GB NVMe SSD. Ubuntu 22.04 or Debian 12 or later is listed across all three tiers. The README states that no GPU is required because inference happens against external Anthropic, Google, or OpenAI APIs.
Configuration details visible in the material include API keys stored with Fernet encryption in PostgreSQL, and a pluggable provider catalog covering Anthropic Claude, Google Gemini, and OpenAI models for LLM, embedding, and vision roles. The README describes embedding model switches as an online re-embed migration where the active model is atomically flipped on completion, so there is no window in which search returns nothing. That detail is specific enough to be worth verifying in a staging environment before relying on it.
One configuration point deserves attention before any deployment: the licence. The README badge and the repository metadata disagree. The badge points to PolyForm Internal Use 1.0.0, while the repository licence field reads NOASSERTION. That usually means the licence file is not in a format the hosting platform recognises. Read the actual LICENSE file rather than the badge.
Where Arkon is the wrong tool
Arkon is heavy. Seven containers, two worker processes, PostgreSQL with pgvector, Redis, and MinIO is a platform, not a script. A five-person team that wants a searchable notes folder will spend more time on operations than on knowledge. The Starter tier exists, but the container count does not shrink with team size.
The ingestion pipeline is the second constraint. Plan review before write is the feature, and it is also a throughput ceiling. Every new document produces a plan that a human editor is expected to consider. If your corpus changes daily, or if you are ingesting machine-generated logs, the review step becomes a queue rather than a safeguard. The README does not describe an automatic approval path for trusted sources, and the material here gives no indication of how the pipeline behaves when a plan is regenerated repeatedly with conflicting feedback.
The third constraint is the dependency on external inference. The README is explicit that all AI inference happens against Anthropic, Google, or OpenAI APIs. There is no local model path described. An organisation that cannot send document content to a third-party API, for contractual or residency reasons, cannot use the compilation pipeline as documented. The self-hosted framing covers the storage and the access layer, not the model.
Finally, the README claims no telemetry and states that outbound traffic goes only to the chosen AI provider. That is a claim about the software, and it is verifiable by reading the code or watching egress. It is not a claim about the provider's handling of the content you send.
How it differs from a plain vector store and from a hosted wiki
The closest comparison for the retrieval layer is a vector database such as pgvector on its own, which Arkon already uses internally. A vector store returns chunks that match a query. Arkon compiles those chunks into pages first, with backlinks, outlinks, wikilink cross-references, version history, and rollback. The difference shows up when a model needs to answer a question that spans three documents: a chunk store returns three fragments, while a compiled wiki returns a page that already reconciles them. The trade is that compilation costs LLM calls and human review time, and the store cannot answer anything the pipeline has not yet compiled.
The closer comparison for the access layer is a hosted wiki product with an AI add-on. Those typically put the permission model inside the vendor's application and expose an API that the vendor controls. Arkon puts the permission model in your PostgreSQL and exposes it over MCP, which means the access rules travel with the deployment rather than with a subscription. The cost is that you own the uptime, the upgrades, and the database backups.
Against a general-purpose MCP server that wraps a search index, the difference is the write path. Most MCP servers are read-only facades. Arkon's tool list includes propose_wiki_edit and approve_draft, so the same endpoint that answers questions can also accept structured changes to the knowledge base, subject to review. That is a narrower and more opinionated design, and it is the reason the audit log exists.
Licence terms and the upgrade treadmill
The licence badge says PolyForm Internal Use 1.0.0, while the repository metadata reports NOASSERTION. Those two signals do not agree, and this article cannot resolve which is accurate. PolyForm Internal Use is a source-available licence rather than an OSI-approved open source licence, and its name suggests it permits internal business use while restricting redistribution or offering the software to third parties as a service. That reading is an inference from the licence name, not from text available here. Anyone planning to embed Arkon in a product, host it for customers, or resell access should read the LICENSE file and get their own legal advice.
The release cadence visible in the material is fast. v0.7.4 landed on 2026-05-20, v0.9.0 on 2026-06-01, and v0.9.1 the same day as a bug fix for v0.9.0. A same-day patch release after a major version bump is normal for active projects, and it also means the upgrade surface is real. The README describes a seven-container deployment, so an upgrade touches the API, both ARQ workers, and the frontend at minimum, with PostgreSQL migrations and pgvector indexes behind them. The online re-embed migration described for embedding model changes is the part most likely to run long on a large corpus, since it re-embeds everything before flipping the active model.
There is no version-support policy in the material supplied. If you deploy this, pin the image tags rather than tracking main, and confirm that the database migration path from your installed version to the target version is documented before you pull.
Editorial conclusion
Adopt Arkon if you have a platform team willing to run seven containers and a legal team willing to read the PolyForm Internal Use licence before signing off. Do not adopt it if you need per-seat commercial pricing, a managed service, or a knowledge base that stays useful without an LLM in the loop. Verify three things first: whether the licence text permits your intended deployment, whether 8 GB of RAM is enough for your document sizes given the note that MRP workers load large context windows, and whether the MCP OAuth 2.1 plus PKCE flow works against your Claude client build.
Community notes