MCP Offline: Can MCP Servers Run in an Air Gap?

Yes, MCP servers run fully offline, because the Model Context Protocol is local by design: an MCP client and server talk over stdio on the same machine or over HTTP inside your own network, and nothing in the specification requires internet access. What breaks in an air-gapped network is the implementation around the protocol. Three habits cause almost every failure: servers that download dependencies at launch, components that phone home for updates or telemetry, and servers that are thin wrappers around a hosted API. This page covers how to diagnose all three, vet a server for zero egress, package servers for air-gap transfer, pick a model that drives tool schemas reliably, and lay out a closed-network reference architecture.

What is MCP (Model Context Protocol)?

MCP (Model Context Protocol) is an open specification that standardizes how an AI application connects a model to external tools and data through a client-server interface. The host application runs an MCP client, and each capability is exposed by an MCP server publishing a typed catalog of tools (functions the model may call), resources (data it may read), and prompts (reusable templates). The specification defines two transports: stdio when the server runs as a local subprocess, and streamable HTTP when it runs as a network service.

The value of MCP is that one interface replaces bespoke integration code: a document store, a ticketing system, or an internal database is exposed once and reused by any compliant client. That property is what makes MCP workable in isolated environments, because the protocol is a contract between two processes you already control and already host.

What three things break MCP in an air-gapped network?

Three implementation habits break MCP in an air-gapped network, and none of them is the protocol itself. Diagnose which one you are facing before engineering around it, because the fixes are unrelated.

1. Runtime dependency downloads. The common distribution convention for MCP servers is a launch command that resolves and fetches packages from a public registry at startup. In an isolated network that command fails on first run and again after every restart. The fix is packaging, not networking.
2. Telemetry and update callbacks. Many servers and host applications check for a new version, report crashes, or send usage analytics. Each call is a policy violation and a failed connection inside the gap, and some clients degrade badly when the request hangs rather than failing fast.
3. Servers that wrap a hosted API. Many published MCP servers exist only to reach a SaaS product. These cannot work across an air gap by construction, and no packaging trick changes that. They must be replaced by servers that talk to the internal system of record.

Blockers one and two are solvable engineering problems. Blocker three is an architecture decision: in a closed network the tool catalog is internal services only, the same constraint described in what changes when AI agents run on-premise and air-gapped.

How do you vet an MCP server for zero egress?

You vet an MCP server for zero egress by reading its startup path and its outbound calls, then proving the result empirically under a default-deny firewall rule. Documentation is not evidence. The checklist below is what Teclops AI applies before an MCP server is allowed inside a client perimeter.

What to check	What passes	What fails
Launch command	Runs an installed binary or an image pinned by digest	Resolves packages from a public registry at every start
Dependency tree	Lockfile present, versions pinned, deps vendored into the artifact	Floating version ranges, post-install scripts that fetch
Outbound calls	Zero: no update check, no analytics, no license ping	Telemetry on by default, or with no off switch
Backing system	Internal database, filesystem, or service on your network	Requires an API key for a hosted service
Bind address	127.0.0.1, or an internal interface with authentication	Binds 0.0.0.0 with no authentication
Tool surface	Narrow typed tools, one verb each, e.g. get_invoice_totals	One generic tool running arbitrary shell commands or SQL
Provenance	Signed release, readable source, named maintainer	Unpinned tag, no signature, opaque binary

Then verify. Run the server in the staging enclave with egress denied, capture traffic, and restart it several times on a clean host, because dependency fetches often appear only on a cold cache. A server that starts once from a warm cache and fails on a fresh machine has not passed.

How do you package MCP servers for air-gap transfer?

You package MCP servers for air-gap transfer by turning each one into a self-contained signed artifact on a connected staging enclave, then importing it through the same controlled path you use for model weights. The transfer discipline matches how to patch an air-gapped AI system offline: stage, verify, carry in, version, roll back.

1. Build in a staging enclave. Resolve dependencies once, on connected infrastructure, with versions fixed by a lockfile.
2. Prefer a container image. A pinned image with the runtime and all dependencies baked in removes package resolution from the isolated network entirely. Pin by digest, not by tag.
3. Vendor dependencies when containers are not an option. For a Node server, ship the full node_modules tree from an offline install. For Python, ship a wheelhouse and install with the package index disabled.
4. Sign and manifest. Every artifact carries a checksum, a signature, and a manifest listing version, license, dependencies, and the tools it exposes.
5. Serve from an internal registry. Inside the gap, servers are pulled from your own registry or mirror, never a public one.
6. Version under change control. New server versions land in parallel, are tested against the live tool catalog, and can be rolled back.

The end state is that starting an MCP server inside the perimeter involves no resolution step at all: it runs the bytes you carried in, and nothing else.

Which open-weight models handle MCP tool schemas reliably?

Open-weight models that ship a documented tool-call chat template handle MCP tool schemas most reliably, and the major instruct families publish variants trained for function calling. Model family matters less than four practical factors, which is the part most evaluations skip.

• The runtime’s tool-call parser. Serving frameworks parse tool-call syntax with a model-specific parser selected at launch, and coverage varies by family and version. A model that supports tools on paper will emit unparsed text if your inference server has no matching parser. Verify that pairing first, using the comparison of vLLM, Ollama, and llama.cpp for on-premise serving.
• Constrained decoding. Grammar or schema-guided generation forces output to match the tool’s JSON schema. It converts most malformed-argument failures into a non-issue and is the highest-leverage reliability lever for smaller models.
• Model size relative to catalog size. Small models call one or two obvious tools well, but selection accuracy degrades as the catalog grows. If a model must choose among dozens of tools, narrow the exposed set per task before reaching for a larger model.
• Knowing when not to call. Recognizing that no tool applies, and saying so, is where models differ most. Test it deliberately with questions your tools cannot answer.

Public function-calling leaderboards are useful for shortlisting. The only evaluation that counts is your own catalog, with your argument types and your real questions.

What are the security risks in MCP implementations?

The security risks in MCP implementations concentrate in server code and tool descriptions, not in the transport. Air-gapping removes exfiltration to the open internet, but it removes none of the risks below, because a confused agent inside the perimeter still acts on real systems.

• Command injection. Servers that shell out with interpolated arguments are among the most commonly reported serious flaws in public MCP server code: a model-supplied string reaches a shell and a crafted argument runs code. Use parameterized calls, strict schema validation, and argument allowlists.
• Tool poisoning. Tool names, descriptions, and parameter docs are read by the model as instructions, so a compromised server can hide directives there. Review descriptions at import, hash them, and alert on any change after approval.
• Untrusted tool output. A tool result is data, never instruction. Treat returned content as hostile text.
• Over-broad tools. A run_sql(query) or execute(command) tool hands the model the whole system. Least privilege means narrow verbs with typed parameters: get_invoice_totals(month, entity), not a general query executor.
• Credential sprawl. Each server holds its own scoped service account, so a flaw in one tool cannot reach unrelated systems.
• Exposed local servers. An HTTP MCP server bound to all interfaces without authentication is reachable by anything on the network segment.

What is a reference architecture for MCP in a closed network?

A reference architecture for MCP in a closed network has four layers, all inside the perimeter, with outbound network denied by default so any accidental callback fails loudly instead of silently succeeding.

Layer	What it is	Control it enforces
Model runtime	Open-weight LLM on internal GPUs behind an OpenAI-compatible endpoint	No prompt or tool argument leaves the perimeter
Agent host (MCP client)	Orchestrator holding the reason-act-observe loop	Task scope, retry limits, conversation state kept local
MCP gateway	One broker between every client and every server	Tool allowlist, role-based tool visibility, argument validation, approval gating, rate limits, one audit log, kill switch
MCP servers	Internal services only: document store, database reader, ticketing, scoped filesystem	Per-server scoped credentials, sandboxed execution, no lateral network

The gateway is the layer teams most often omit and most often regret. Without it, every application wires its own servers, tool policy scatters across config files, and nothing can answer which tools a role may call or what the agent actually did. With it, you get one allowlist, one audit trail, and one switch to disable a tool across the estate. Pair it with human approval on every write and a tamper-evident log whose unit of record is the tool call: arguments, approver, result.

Where does Teclops AI fit?

Teclops AI builds tool-calling agents inside closed networks as part of its custom AI agent and workflow automation services, deployed entirely within the client’s own infrastructure. The work is the unglamorous part of this page: replacing cloud-wrapper MCP servers with internal ones, vendoring and signing artifacts for offline transfer, pairing a model with a runtime whose tool-call parsing holds, and putting a gateway with least-privilege tools and a tamper-evident audit trail between the agent and the systems it can touch.

The sequence we recommend is to start read-only, prove the retrieval layer, then add one write tool at a time behind approval. If you are evaluating MCP or agentic tooling for an air-gapped or on-premise environment, reach the Teclops AI team at teclops.ai@gmail.com.