3 tiers in a private MCP document pipeline

An MCP server for local AI document processing lets an agent such as Claude Code call tools that read and redact a document instead of ingesting the raw file. A private pipeline runs three tiers: extraction, redaction, then return. In the workflow Filip Makraduli of Superlinked demonstrated at AI Engineer in October 2026, a scanned NDA leaves an Obsidian vault, is OCR'd and masked on infrastructure the team controls, and comes back to the coding agent as a smaller Markdown artifact.

The three tiers of that pipeline, and what each one costs you in trust:

Tier	Runs on	Input	Output	Trust boundary
Extraction	OCR worker on team-controlled infra	Raw scanned NDA	Raw text	File never leaves the vault's network
Redaction	MCP tool called by the agent	Raw text	Masked text	Agent sees only the fields it must act on
Return	Local MCP server	Masked text	Smaller Markdown artifact	Coding agent receives no raw bytes

To reproduce the October 2026 demo end to end:

1. Register the local MCP server so Claude Code can list its document tools.
2. Pull the scanned NDA out of the Obsidian vault and hand it to the OCR tier.
3. Run extraction so raw text exists only inside infrastructure the team controls.
4. Call the redaction tool on that text and verify every mask before anything is returned.
5. Deliver the resulting Markdown artifact back to the coding agent, not the source file.

An MCP local AI document pipeline moves document work onto a server the team controls, so the agent's context receives a redacted Markdown summary instead of every page and image. Superlinked's 2025 demonstration of this pattern used an Obsidian vault and a private GPU cluster, and by 2026 the same three-tier split had become a common reference design.

How MCP local AI document processing works

An MCP local AI document processing setup puts the file work on a server the team controls, and the agent sees only the result. The token savings come from replacing a large raw artifact with a smaller one, so the agent's context carries a redacted Markdown summary rather than every page and image.

In the Superlinked demonstration, an Obsidian vault held the source files. Superlinked, a vendor selling a cluster and inference engine, packages the integration as an MCP server inside the superlinked/sie repository, so the agent discovers tools instead of gaining full file access by default.

MCP, the Model Context Protocol, is an open standard that lets a host such as Claude Code discover and call tools exposed by a server.

The transcript describes three tiers, each with a distinct job:

Tier	What it holds	What it does not see
Host and client	Agent session and conversation history	Source files on disk
MCP server	Source vault, chunking, redaction	Raw model weights
GPU cluster	Inference for the local models	The external model endpoint

The pitch separates two goals. Cost control comes from pre-processing documents outside the agent. Privacy comes from keeping the processing inside a private cloud, so the sensitive bytes never reach the external model endpoint.

The sensitive file problem in an Obsidian vault

An Obsidian vault is convenient for storing Markdown notes, and that same convenience multiplies the exposure when an agent can read the whole directory. A scanned NDA with social security numbers, phone numbers, and emails is exactly the kind of file a person wants the agent to summarize and does not want the agent to ingest.

Makraduli framed the starting point around privacy and token cost together. Documents with images or scans require OCR before any model can reason about them, and OCR output is verbose, so sending every page directly to a frontier model consumes context and money at the same time.

The demonstration used synthetic data that resembles real correspondence, including invoices and an NDA with PII. The point was structural: with an Obsidian vault open to an agent, the useful behavior and the dangerous behavior look identical until you separate who can read the file from who can process it.

Superlinked and the Superlinked SIE repository

Superlinked sells the cluster and inference layer used in the demo, and the integration code lives in the open-source superlinked/sie repository. The vendor reports that the cluster handles model loading, batching, pooling, and serving so an application can run several models against the same hardware.

The repository publishes Helm charts and Terraform deployment for a Kubernetes cluster, so the same stack can run on the user's own cloud. Makraduli described this as the reason he chose MCP over a skill or a bare API call: the worker pool and GPU layout become explicit, and the boundary stays under the operator's control.

He also described a hosted cluster with an application form for free inference credits, which he recommended for people who want to test the integration without provisioning GPUs first. That hosted path is a vendor service, not a requirement, and it sits outside the privacy claim unless the cluster is the operator's own.

Inside the three-tier MCP host, client, and cluster

MCP defines a host, a client, and a server, and the Superlinked demo adds a fourth moving part: the GPU cluster the server calls. The host is Claude Code or another agent harness, the client manages the connection, the server exposes tools, and the cluster runs the models that perform the actual work.

The connection uses JSON-RPC with a request, a response, and a notification channel for the initial handshake and authentication. In this setup the server only exposes tools; the transcript says the team deliberately left out client-side capabilities such as sampling and elicitation because the goal was a one-directional privacy boundary.

Transport matters for deployment. Standard input and output is the usual choice for local development, and the newer streamable HTTP transport folds the handshake and the streaming response into one endpoint instead of the older two-endpoint split.

The table below summarizes the responsibilities as described, without implying that any tier is optional.

• Host and client: runs the agent, decides when to call a tool, holds the conversation context.

• MCP server: authenticates the connection, publishes the tool list, forwards jobs to the cluster.

• GPU cluster: loads and swaps models, batches inference per worker, returns artifacts to the server.

The Superlinked private MCP document pipeline converts documents to Markdown before any agent sees them, and that conversion is where most of the token reduction happens. OCR extracts the text, redaction masks entities such as names, emails, and account numbers, and the agent reads only the masked version.

Documents to Markdown in the Superlinked demo

The central tool converts documents to Markdown, and that conversion is where most of the token reduction happens. OCR turns a scan into text, the redaction step masks entities such as names, emails, and account numbers, and the agent receives the masked version rather than the original. The demo Makraduli walked through ran this path end to end; by 2025 the MCP server exposed the full tool set behind one interface, and in 2026 the counter he showed was still described as unfinished.

The transcript lists several tool families on that shared inference path:

1. Document-to-Markdown conversion with OCR.
2. Entity extraction with named-entity recognition models.
3. Captioning and tagging.
4. Structure generation.
5. Summarization.
6. Question answering.

The table below separates what the demo measured from what it only asserted.

Claim	Basis in the demo	How to read it
OCR quality	Vendor position from a live demo	Not an independent benchmark
Token savings	Status line counting context size	Demonstration aid, not billing
Scope	Documents and models Makraduli tested	Does not generalize to OCR overall

Makraduli argued that the open OCR models he used do not impose a quality penalty for this workload. That is a vendor position from a live demo, not an independent benchmark, and it applies to the documents and models he tested rather than to OCR in general.

The token-saving status line he showed counts the difference in context size. He noted the counter still needed work, so treat the display as a demonstration aid rather than a measured billing figure.

Why a dedicated MCP server beats a skill or a direct API call

A skill or a direct API call can also reach an OCR model, but the MCP server gives the deployment its own place to live. Makraduli's stated reason was separation of responsibilities: the server can grow new tools while the cluster, GPU layout, and authentication stay unchanged.

The API comparison is about control as much as convenience. A developer calling a hosted OCR endpoint sends the document to a third party, while a self-hosted server keeps the document inside the network boundary the operator configures.

The integration also benefits from using models that are already warm on a GPU. If a model is loaded and serving, a request returns faster than a request that forces a cold start elsewhere, and that difference becomes part of the routing decision.

Throughput comes from batching per worker pool

Batching is handled per worker rather than in a single shared queue, which the vendor reports improved end-to-end latency across different models. Each worker pool pulls and batches its own jobs, so a slow or heavy model does not stall work destined for a lighter one.

The architecture lets an operator place a heavier model on one pool and a smaller model on cheaper hardware, such as an NVIDIA L4 spot instance. Autoscaling brings capacity down when the queue drains, which matters when a document pipeline runs in bursts.

The same design supports hot swapping between multiple small models on one GPU, including task-specific adapters for a narrow domain. The claim here is architectural and vendor-reported; the transcript gives no per-model latency table.

Embedding and reranking benchmarks in the Superlinked stack

Superlinked reports that its best embedding model per task reached 99.8 percent of the frontier model's quality at roughly one tenth the price. Those figures are vendor-reported, measured on MTEB tasks, which is a public benchmark suite for text embeddings.

Read that number with its scope intact. It describes selected embedding models on MTEB, not generation quality, not OCR accuracy, and not the end-to-end document pipeline. The transcript itself says the available benchmarks cover embedding models and that generation benchmarks were still coming.

The transcript also mentions reranking and scoring models, which can be exposed through the same server for custom retrieval. German-language LoRA adapters for legal text came up as a colleague's experiment, offered as an example of cheap task-specific fine-tuning rather than as a shipped product feature.

Privacy boundaries, security limits, and responsible claims

Running OCR and redaction on your own infrastructure keeps the raw bytes out of an external model endpoint, and it does not by itself make an agent compliant with any regulation. Compliance depends on the host, the filesystem permissions, the network controls, the audit trail, and the organization's own policies.

A questioner raised the obvious attack: if the agent can read the original file before it calls the tool, the tool's output is not the only thing the agent has seen. Makraduli agreed this warrants testing and said the option of building a custom harness with an open-source model remains open.

The practical lesson is to remove the agent's direct access to the source directory, or to give it access only to a staging area the server populates. Prompt instructions alone are not an access control mechanism.

What the Superlinked roadmap does not include yet

Model routing is a stated direction, not a shipped capability in the demo. The described version works through tool calling, while routing would choose a model per tool request using evaluations, cost, and which model is already warm on a GPU.

The transcript also mentions judges or a council of models, mixture-of-agents patterns, and intent detection as future explorations. Treat all of these as roadmap items. Model routing, warm-model selection, and judge ensembles are not built into the MCP integration shown on stage.

The related risk is that optimization loops can be gamed. A model trained or prompted to satisfy an evaluation can drift from the real objective, and Makraduli said the team invests in evaluations for exactly that reason.

How to reproduce the Obsidian MCP workflow

1. Clone the superlinked/sie repository and locate the MCP integration subdirectory described in its README.

2. Provision the cluster, either by deploying the included Helm charts and Terraform configuration on your own GPUs or by requesting vendor credits through Superlinked's inference grant form.

3. Configure credentials for the MCP server, including the cluster endpoint and API key, then register the server with Claude Code or another MCP-capable host.

4. Point the server at a document directory that the agent cannot read directly, and run a document-to-Markdown plus redaction job against a test file before trusting the boundary with real data.

FAQ

• What is MCP local AI document processing? It is a workflow where an MCP server running on infrastructure you control performs OCR, redaction, or other document tasks, then hands the agent a smaller artifact. The agent sees the processed result rather than the raw file.

• Does the Superlinked MCP integration make document processing private? It can keep raw documents inside a private cloud and return only redacted output, which is a meaningful architectural boundary. It does not prove regulatory compliance, tenant isolation, or suitability for regulated industries on its own.

• Which tools does the Superlinked MCP server expose? The described tools cover documents to Markdown with OCR, entity extraction, captioning and tagging, structure generation, summarization, question answering, and redaction of personally identifiable information.

• Can I self-host the whole stack instead of using the vendor cluster? Yes. The repository publishes Kubernetes Helm charts and Terraform configuration, so the cluster can run on your own GPUs; the managed cluster exists mainly to make demos and hackathons faster.

• Why use MCP instead of a skill or a plain API call? A dedicated server separates the agent from the processing layer, gives the deployment one interface for new tools, and lets the operator choose the GPUs and worker pools that run the models.

• What do the 99.8 percent and 10x figures mean? Superlinked reports that its best embedding model per task matched 99.8 percent of a frontier model's quality at roughly a tenth of the price on MTEB tasks. Those numbers cover embeddings, not OCR or generation quality.

• Does routing between models already work? Model routing is described as a future direction rather than a shipped feature. The current integration works through tool calling, and routing would pick a model per request based on evaluations, cost, and warm-model state.

• What is the main risk with a privacy-focused MCP server? The agent may be able to read the original file before it calls the tool. Removing direct filesystem access to source documents is the control that addresses this, not a prompt instruction.

• Will Superlinked, a Portuguese-language bootcamp topic, or an unrelated YouTube course help with this workflow? No. Follow the superlinked/sie README and the Model Context Protocol specification instead; unrelated courses do not document this integration.

Context from the creator community

The same kind of pipeline work appears in creator education as well. Gustavo Dev Doido covers TypeScript and AI application development through the Crazystack ecosystem, including the Crazystack Typescript track and the Bootcamp do Dev Doido. The material is about building and shipping software, not about the Superlinked MCP integration, so it belongs here as context rather than as documentation for this workflow.

Turn a recorded walkthrough into a written article

The Superlinked demo works because a dense 47-minute session becomes a small, reusable artifact. The same idea applies to any recorded walkthrough: the reasoning, the trade-offs, and the failure modes are already captured, and they stay locked in video until someone turns them into text.

If you have talks, interviews, or technical explanations sitting in a YouTube archive, paste the URL into Skala Blog, transcribe the video, and generate a structured draft.

Source video