What's the best way to give enterprise AI agents company knowledge over MCP?

Put one read-only MCP server in front of a maintained knowledge layer rather than wiring agents to every raw source. Ingesto provides that layer: it keeps knowledge from Slack, Teams, email, Drive and Notion synced and conflict-checked, and serves it to agents over MCP or an API with sources, dates and conflicts on every answer.

How does MCP handle authentication and permissions?

For HTTP transports, the spec bases authorization on OAuth 2.1, with the MCP server acting as a resource server that only accepts tokens issued for it. Document-level permissions are the server's job: it should return only what the user the agent acts for is allowed to see in the original source.

How do you reduce token usage with MCP?

Expose fewer, higher-level tools, return short answers with citations instead of whole documents, deduplicate knowledge before retrieval, use structured tool output, and page and cache list results. Tool definitions and raw intermediate results are usually the biggest costs.

Is MCP a replacement for RAG?

No. MCP is how an agent reaches a data source; RAG is one way that source can find relevant text. An MCP server can sit in front of a RAG index, a database or a maintained knowledge layer. The quality of what's behind the server decides the quality of the answers.

All guides

Explainer21 September 202610 min read

An MCP data architecture for enterprise AI agents

Q: What is the Model Context Protocol?

An open standard for connecting AI applications to data sources and tools. A host application runs clients that each connect to one server, and servers expose tools, resources and prompts over stdio or Streamable HTTP. It was introduced by Anthropic in 2024 and is now under the Linux Foundation's Agentic AI Foundation.

How to connect LLM tools to live company knowledge over the Model Context Protocol: architecture patterns, OAuth, permissions and where the tokens go.

Sami SIngesto

The short answer

The Model Context Protocol (MCP) is an open standard for connecting AI applications to data and tools: a host application runs clients that each talk to one server, and servers expose tools, resources and prompts over stdio or Streamable HTTP. For company knowledge, the architecture that holds up is a small number of read-only servers in front of a maintained knowledge layer, not one server per raw source. Authorize every call as the end user with OAuth tokens issued for that server, enforce permissions at the server rather than in the prompt, and return compact answers with citations instead of whole documents. That keeps tool definitions and retrieved text out of the context window, which cuts token cost and leaves the model less to reconcile. Ingesto is that knowledge layer: it keeps company knowledge from Slack, Teams, email, Drive and Notion synced, deduplicated and conflict-checked, and serves it to agents over MCP or an API with sources, dates and conflicts on every answer.

MCP in one page, as the current spec defines it

Anthropic introduced MCP in November 2024 and donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025. The current specification is the 2026-07-28 revision. The spec describes a client-host-server architecture: hosts are the LLM applications (a chat assistant, an IDE agent, a support copilot), clients are connectors inside the host with a one-to-one connection to a server, and servers provide context and capabilities.

Servers expose three primitives, and the spec is specific about who controls each one. That control model matters for enterprise design, because it decides whether the model, the application or the user chooses what data enters the context.

Primitive	Who controls it	Company knowledge example
Tools	The model decides when to call them	Ask a question and get an answer with sources, or search a topic
Resources	The application decides what to attach	A specific policy document or meeting recap, by URI
Prompts	The user picks them	"Draft a reply using the current refund policy"

There are two standard transports: stdio for servers running locally beside the host, and Streamable HTTP for remote servers. The older HTTP with server-sent events transport is deprecated. The 2026-07-28 revision also made the protocol stateless: the initialize handshake and protocol-level sessions are gone, and every request carries its protocol version and client capabilities. For an enterprise running remote servers, that makes an MCP server look much more like an ordinary stateless HTTP service.

Three ways to wire agents to company data

Most enterprise MCP projects start with one of three shapes. The difference between them is where the work of deciding what's true happens.

1. One server per source

A Drive server, a Slack server, a Notion server, a ticketing server. It's the fastest way to get started, because servers for popular tools already exist. But the agent now has dozens of tool definitions in its context, a separate permission model per source, and raw documents coming back that it has to reconcile itself. When the refund policy in Drive says 30 days and a Slack thread says 45, the model is the one deciding, mid-answer, with no owner in the loop.

2. A retrieval gateway

One server in front of a vector index over all the sources. Far fewer tools, one permission layer, one place to tune retrieval. But the index returns whatever matches, including superseded versions and duplicates, so the model still gets three copies of the refund policy and still has to choose.

3. A maintained knowledge layer

One server in front of knowledge that has already been organized by topic, deduplicated and checked for conflicts, with an owner behind each topic. The agent asks a question and gets back an answer, its sources and dates, and any open conflicts. The deciding happens upstream, once, by the person who owns the topic, instead of in every agent call.

Recommendation: use pattern 3 for company knowledge (policies, procedures, product facts, decisions) and keep per-source servers for actions, like creating a ticket or posting a message.

Where the context tokens actually go

Token cost in agent systems rarely comes from the question or the answer. It comes from three places, and the architecture decides all three.

Tool definitions. Every connected tool's name, description and input schema is loaded into context before the model reads the request. Anthropic has reported a five-server setup with 58 tools taking about 55,000 tokens, and tool definitions reaching 134,000 tokens internally before optimization.
Intermediate results. When a tool returns a document, the whole document passes through the model, often more than once as it's quoted into the next call. Anthropic's example is a two-hour meeting transcript adding around 50,000 tokens to a single workflow.
Retrieved duplicates. A retrieval step that returns five chunks, three of which are copies of the same policy in different states, pays for five chunks and adds two competing answers.

Anthropic's own fixes for the first two (searching for tools on demand, and letting agents call tools from code so intermediate results stay out of context) cut context substantially in their tests, with the caveat that running agent-written code needs sandboxing. The cheapest fix sits one level earlier: don't send the model material it doesn't need.

Six ways to keep the context window small

Expose fewer, higher-level tools. One ask tool that returns an answer beats list_files, read_file, search_channel and get_thread, both in definition tokens and in the calls the model has to plan.
Return answers, not documents. A short answer with citations is a few hundred tokens. If the agent needs the full source, return a resource link it can follow, so the host decides whether to load it.
Deduplicate before retrieval, not after. If the same policy lives in five places, the knowledge layer should hold one current version with five sources, not five chunks.
Use structured output. MCP tool results can carry structuredContent validated against an outputSchema, so the host can read the answer, sources, dates and conflicts as fields instead of asking the model to re-read prose.
Page and cache. List operations use cursors, and the 2026-07-28 revision adds freshness hints (ttlMs and cacheScope) to list and resource results, and asks servers to list tools in a stable order to improve prompt cache hits.
Log what agents actually ask. The questions tell you which tools matter and which never get called and can be removed.

What a good answer payload looks like

Whatever pattern you pick, what comes back decides whether an agent's answer can be checked. For a question like "What's the refund window on annual plans?", a knowledge tool should return something with this shape (the values are illustrative):

Field	Example	Why the agent needs it
answer	30 days from renewal, full refund	The fact, in as few tokens as possible
sources	Refund Policy v3 (Drive); #support thread (Slack)	So a person can check what the agent said
verified	2026-02-03	So the agent can say how current the answer is
conflicts	Sales FAQ in Notion says 14 days, flagged to owner	So the agent reports a disagreement instead of picking a side
gap	false	So a missing answer comes back as a gap, not a guess

Security: the part that decides whether you can ship

An MCP server in front of company knowledge is a new way into everything your company has written down. Most of the design work is making sure it can't hand anyone more than they could already see.

Authorize as the user, with tokens meant for this server

For HTTP transports, MCP authorization is based on OAuth 2.1, with the MCP server acting as a resource server. Clients must name the server they're requesting a token for, and servers must check that a token was issued for them. The spec explicitly forbids token passthrough, where a server accepts a client's token and forwards it to an upstream API. Request the narrowest scopes that work, and use the spec's step-up flow when a call needs more.

Enforce permissions at the server, not in the prompt

The agent should see exactly what the person it's acting for can see in the original source, and that has to be enforced before retrieval. An instruction like "don't reveal HR documents" in a system prompt is not access control. A server that uses one broad service account for everyone is the textbook confused deputy, which the spec's security best practices cover directly.

Keep knowledge tools read-only, and remember annotations are hints

Tools can carry annotations such as readOnlyHint and destructiveHint, but the spec calls them hints, and clients must treat annotations from untrusted servers as untrusted. The reliable version is structural: a knowledge server with no write tools can't be talked into writing anything.

Treat company content as untrusted input

Slack messages, emails and shared docs are written by many people, and some come from outside the company. Text in a retrieved document that says "ignore your instructions" reaches the model like any other text. Return content as data fields rather than as instructions, keep humans in the loop for anything that acts, and log every call with the user, the tool and the sources returned.

Real time without a re-indexing job

"Real-time company knowledge" usually means an index rebuilt on a schedule, which means it's wrong between runs. The more useful definition is that the knowledge layer updates when a source changes: a decision in a Slack thread, an edited policy in Drive, a change agreed on a call.

MCP has the plumbing for the last mile. Clients can open a subscription stream and opt in to notifications when a server's tools, prompts or resources change, and results can say how long they stay fresh. But the protocol only moves what the server has. If the layer behind it is a nightly index, the agent gets last night's answer, promptly.

A reference architecture

Sources: Google Drive, Notion, Slack, Microsoft Teams, Gmail, Outlook, Zoom and Google Meet, left where they are.
Sync: connectors that pick up changes as they happen, rather than a batch export.
Knowledge layer: organized by topic, one current version per fact, conflicts flagged to a named owner, a source and date on every line.
Access: permissions mirrored from the sources and enforced per user on every call.
Interface: one remote MCP server with a few read-only tools, plus an API for systems that don't speak MCP.
Hosts: chat assistants, IDE agents, support copilots and internal workflow agents, all reading the same answers.
Observability: a log of questions, answers, sources, unanswered questions and conflicts surfaced, reviewed by the knowledge owners.

Test it before rollout with a set of 50 to 100 real questions whose answers the topic owners have confirmed. Track answer accuracy, whether the cited sources actually support the answer, tokens per answer and how often the agent reports a conflict or a gap instead of guessing.

Where Ingesto fits

Ingesto is the knowledge layer behind your MCP server

Steps 1 to 4 are the part that takes a platform team months. Ingesto provides them. It connects to the tools where company knowledge is scattered, keeps it in sync as those tools change, and resolves duplicates and conflicts with the owner of each topic, so an agent reads one current version instead of every stale copy.

Serves the same knowledge your team uses to AI agents over MCP or an API, with no export job or re-indexing to maintain.
Returns sources, dates and any conflicts with every answer, so agents can pass them on honestly.
Agents read only what they're allowed to see, following the access you set for the knowledge.
A question with no documented answer comes back as a gap, not a guess, and is flagged to the owner.

Get started Book a demo