An internal MCP server is a private, authenticated endpoint that gives your team's AI assistants access to the company's own knowledge — the SOPs, the policies, the product facts, the onboarding material. On SuperCognit you build one without writing code: import the pages, upload the documents, publish, and everyone who signs in gets cited answers from your material inside whatever AI tool they already use.
The wiki was supposed to fix this
Most companies already wrote everything down. The handbook exists. The SOPs exist, in a folder, versioned optimistically. The problem was never writing — it was retrieval at the moment of need. A new hire with a question does not search the wiki; they ask the person next to them, who answers from memory, and the folklore version of the process gets one more generation of transmission.
Meanwhile the team started using AI assistants every day, and those assistants know nothing about your company. Ask one about your expense policy and it will answer anyway — fluently, confidently, and from the general internet. That gap, between the assistant your people actually consult and the knowledge you actually wrote, is what an internal MCP closes.
What goes in
- Onboarding: who does what, how the first weeks run, where things live, which acronyms mean what.
- SOPs: the operational how-to — how a refund is processed, how an incident is escalated, how the month-end close actually works.
- Policies: expenses, leave, security, remote work — the documents people need exactly once a quarter and can never find.
- Product facts: specs, pricing rules, the answers support gives — so internal answers match external ones.
Building it
Import what already exists
Point SuperCognit at your site or handbook pages and they are crawled into a knowledge base in about two minutes, every answer carrying a citation to its source page. Upload the rest — PDFs, policy documents, spec sheets — alongside.
Keep it private
Set the server to private. Access runs on OAuth 2.1 per the current MCP specification, and the workspace is isolated: only seats you have granted can connect, and each person authenticates as themselves.
Publish once, get two products
The same build produces a chat agent and an MCP server. People who live in Claude or another MCP client connect the server; people who just want to ask a question use the chat. One knowledge base, two doors.
Let it stay current
Imported sources re-sync on a schedule — as often as hourly. When the policy page changes, the brain follows without anyone re-uploading anything.
Citations are the trust mechanism
An internal answer without a source is folklore with better formatting. Every answer from the knowledge base cites the page or document it came from, so the person asking can check, and the person who owns the document discovers it is actually being read. That changes writing incentives too: when the SOP is what the assistant answers from, keeping it accurate stops being a documentation chore and starts being operational.
Offboarding is a one-seat operation
Because access is per seat, revoking one person's access revokes one person — not a shared password everyone has to rotate. That is a small sentence with large compliance implications. The company brain is one of the more sensitive things you will ever put behind an endpoint, and 'we removed their access on their last day' should be a statement you can make truthfully, on the day.
What it will not do
It will not fix an SOP that is wrong, and it retrieves outdated policy exactly as confidently as current policy — the re-sync schedule helps, but only if someone updates the source. The process that exists only in a senior employee's head cannot be imported either; writing it down is still your job. The brain is a retrieval layer, not a documentation programme.
A reasonable way to start: collect the twenty questions new hires actually asked in their first month, load the documents that answer them, and see whether the answers hold up. Loading takes an afternoon, and the seven-day trial is long enough to find out.