What is an MCP server for enterprise knowledge?

What MCP is — in one paragraph

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external tools and data. An MCP server publishes a list of tools (with names, descriptions and input schemas); an MCP client — the agent runtime — discovers them and lets the model call them during a task. The point is decoupling: the organisation builds one server, and every MCP-compatible agent can use it without custom integration code. For enterprise knowledge this replaces the pattern of “each team wires its own bot to SharePoint” with “one governed endpoint that every agent reads from”.

Why agents should not read raw SharePoint

Connecting an agent directly to a file share does not fix data quality — it scales the problem. The agent now retrieves five versions of the same procedure, the 2019 copy and the 2024 one, and acts on whichever ranks first — autonomously, at machine speed, and billed per token for all five. A knowledge MCP server is the place to fix this: it should serve curated knowledge (deduplicated, contradiction-checked, canonical version marked) with citations, so the agent gets one clean context instead of a document dump. In TensorLot pilot deployments (2026) that meant up to 70 % fewer tokens per answer.

What a knowledge MCP server must do

1. Scope.. Every agent sees a defined knowledge space — sites, libraries or topics — and nothing else. Least privilege applies to agents exactly as it does to people.
2. Default-deny tools.. Tools are off until an accountable owner switches them on per agent. An agent that only needs to answer questions never gets an action tool.
3. Keys that expire.. One endpoint, one key per agent; keys expire and can be revoked at any time. No shared service accounts.
4. Cited answers.. Search and ask tools return grounded answers with the source documents — the same retrieval people use — so a human can verify what the agent acted on.
5. Governed actions.. If agents may change state (archive, resolve, set a document action), the rules for what that means must be defined once — per URL prefix, library, site or tenant — and the action must run with the user’s rights, never the platform’s. The server itself should not write to the source system.
6. Audit log per call.. Agent, tenant, tool, time, scope — for every call. Without it an agent is not governed; it is merely connected.
7. A safe place to test.. Dry-run over the real endpoint with a full tool-call trace before going live.

Worked example: TensorLot as an MCP server

TensorLot exposes its curated knowledge layer as an MCP server with 11 governed tools on one endpoint with one key. Among them: ask and search_documents (semantic search and grounded, cited answers — the same retrieval as Tensor Bot, scoped to a knowledge space), list_findings and get_finding (quality findings such as duplicates, contradictions and outdated content, so agents can report them where teams work — Teams, Slack, ticketing), and set_document_action (governed actions such as archive or resolve; the agent acts with the user’s rights and every step is audit-logged — TensorLot never writes to SharePoint itself).

Agents are created in the console with a defined knowledge space, a default-deny tool list and an accountable owner; they connect via MCP or REST and work with Copilot Studio, Claude and any MCP-compatible framework. A playground dry-runs a task over the real endpoint — one run in the console sees 59,059 documents with 2 of 5 actions allowed — and shows every tool call in the trace before the agent goes live. Action rules (URL prefix › library › site › tenant, most specific wins) define what “archive” means so agents follow your rules instead of improvising.

Evaluation checklist

• Can I scope an agent to specific sites/libraries/topics, and see that scope in the console?
• Are tools default-deny and switched on per agent by a named owner?
• Do keys expire, and can I revoke one without touching the others?
• Do answers carry citations to the source document?
• Is the content the agent reads curated (duplicates/contradictions/outdated handled) — or a raw index?
• If agents can act: are actions rule-governed, executed with the user’s rights, and never written by the platform itself?
• Is every call logged with agent, tenant and tool — and can I export it?
• Can I dry-run over the real endpoint with a tool-call trace before going live?
• Is the server usable from more than one agent platform (Copilot Studio, Claude, LangGraph, custom) without custom code?