What Is an MCP Server?
How the Model Context Protocol connects AI agents to your data and your actions: what the parts are, where the security model breaks, and how to run one inside your own boundary or fully air-gapped.
An MCP server is a program that exposes one system’s data and actions to an AI application through the Model Context Protocol, an open standard published by Anthropic in November 2024. It advertises tools, resources and prompts over a defined interface, so any MCP client can call them without custom integration code.
Before MCP existed, every connection between an AI application and a system of record was bespoke. A team that wanted an assistant to read Jira, search a wiki and file a ticket wrote three integrations, and the next assistant wrote them again. The Model Context Protocol replaces that with one interface: a server publishes what it can do, a client discovers it, and the model decides when to call it. Anthropic released the specification and reference implementations as an open standard (Source: Model Context Protocol documentation), and Google Cloud, Microsoft and OpenAI have since shipped support in their own agent platforms.
Gartner expects 33% of enterprise software applications to include agentic AI by 2028, up from less than 1% in 2024 (Source: Gartner, October 2024). Those agents are only as useful as the systems they can reach, and only as safe as the credentials and tool definitions behind them. This guide covers both halves: the mechanics of servers, clients and tools, and the operational questions that decide whether an MCP deployment survives a security review. For the protocol’s own reference material, modelcontextprotocol.io and Google Cloud’s protocol overview are both good companions to this page.
- MCP server, defined
- How MCP servers, clients and hosts fit together
- What an MCP server exposes: tools, resources and prompts
- Why AI agents need the Model Context Protocol
- The MCP security model
- Authorization: OAuth 2.1 and scoped credentials
- Running an MCP server on-premise or air-gapped
- MCP across the Iternal stack
- FAQ
How MCP Servers, Clients and Hosts Fit Together
The protocol separates four roles, and confusing them causes most architectural mistakes. A host is the AI application a person interacts with. Inside it sit one or more clients, each holding a single session with a single server — the only component that touches a system of record. Messages travel over a transport as JSON-RPC 2.0 requests, responses and notifications.
That one-client-per-server rule is a security property, not a formality: because sessions are isolated, a compromised server cannot address the other servers a host has open. It can only return content to its own client.
| Part | What it does | Typical example |
|---|---|---|
| Host | The AI application the person uses. It runs the model, holds the conversation, and decides which servers the model may see. | A desktop assistant, an IDE coding agent, an internal chat application |
| Client | A connector inside the host. Each client holds one stateful session with one server, keeping servers isolated. | One client per connected server, spawned and supervised by the host |
| Server | The program that publishes capabilities: it answers discovery requests, executes tool calls and returns structured results. | A wrapper around a ticketing system, a document store, a database, a build system |
| Transport | How JSON-RPC 2.0 messages travel: a local process pipe, or an HTTP connection. | stdio for local servers, Streamable HTTP for remote ones |
The connection lifecycle
A session opens with an initialize exchange in which both sides declare the protocol version and the capabilities they support. The client then asks the server to list what it offers; the server replies with tool, resource and prompt definitions, each with a name, a description and a JSON Schema for its arguments. Those descriptions are fed to the model as context, which is why they are a security surface rather than documentation.
From there the loop is simple: the model proposes a call, the host approves it, the server executes it, and the result returns as structured content. Servers may also push notifications — a changed tool list, a resource update — which is where the “rug pull” problem in the security section comes from.
Two transports, two very different risk profiles
stdio
The host launches the server as a local child process and talks to it over standard input and output. No network listener, no port to scan, and the trust boundary is the machine — the default for developer tooling and disconnected workstations.
Streamable HTTP
The server is a web service reachable by many clients, streaming results back over HTTP. This is what makes shared, centrally governed servers possible — and it is the transport the specification places under an OAuth 2.1 requirement, because anyone who can reach the endpoint can attempt a tool call.
The specification is versioned by date, and revisions have changed the security rules materially: 2025-03-26 introduced the OAuth 2.1 authorization framework, and 2025-06-18 classified MCP servers as OAuth 2.1 Resource Servers and prohibited token passthrough outright (Source: Model Context Protocol specification). Pin the revision your servers implement; the published specification is the authority on every detail summarized here.
What an MCP Server Exposes: Tools, Resources and Prompts
A server publishes three kinds of capability, and the difference between them is who is in control. Tools are model-initiated: the model decides a call is needed and the host gates it. Resources are application-selected: the host attaches them and the model reads what it is given. Prompts are user-invoked. Getting this mapping right is the biggest design decision in building a server, because it determines what an attacker gains by influencing the model’s reasoning.
| Server primitive | Who initiates | What it is | Example |
|---|---|---|---|
| Tools | Model-initiated, user-approved | Executable functions with a JSON Schema for their arguments. The model chooses when to call them; the host decides whether the call is allowed to run. | create_ticket, run_query, send_message, deploy_build |
| Resources | Application-selected | Read-only context addressed by URI. The host application decides what to attach; the model does not fetch resources on its own initiative. | file://spec.pdf, db://orders/2026-Q1, wiki://runbooks/failover |
| Prompts | User-invoked | Parameterized templates the server publishes for a person to trigger deliberately, usually surfaced as a slash command or menu item. | /summarize-incident, /draft-change-request |
The client side of the protocol
MCP is bidirectional, which keeps server implementations thin. Through sampling, a server asks the host to run a model completion rather than embedding its own model key. Through elicitation, it pauses to ask the user for a missing input instead of guessing. Through roots, the client declares the filesystem or URI boundaries the server may operate within.
A practical rule when you build: if a capability changes state, it is a tool and it needs an approval path and an audit record. If it only supplies context, make it a resource so the model cannot decide on its own to pull it. Servers that expose read operations as tools hand the model a discovery mechanism it did not need, and every extra tool definition is another block of untrusted text sitting in the context window (Source: Model Context Protocol specification).
Why AI Agents Need the Model Context Protocol
A language model on its own can reason about your business but cannot touch it. Five AI applications and eight systems of record mean forty bespoke integrations, each with its own authentication, error handling and credential to rotate. MCP collapses that into thirteen: eight servers and five clients. Every new application inherits every existing server, and every new server reaches every application already deployed.
The organizational consequence matters more than the arithmetic. When integrations are bespoke, the security review happens once per project and the credentials end up wherever the project put them. When integrations are servers, the review happens once per server and the access path is a named, inventoried thing you can revoke. Forrester has predicted that three-quarters of firms attempting to build agentic architectures in-house will struggle to make them work (Source: Forrester, Predictions 2025), and integration sprawl is one of the reasons.
| Approach | How capabilities are discovered | Reuse | Authorization model | Best for |
|---|---|---|---|---|
| MCP server | Runtime: the client lists tools, resources and prompts on connect | Any MCP-compatible host reuses the same server unchanged | OAuth 2.1 resource server on HTTP; process-level trust on stdio | Shared systems of record several AI applications need to reach |
| Direct function calling | Build time: functions are declared in application code | Locked to one application and usually to one model provider’s schema | Whatever the application already holds, often a long-lived key | A handful of stable functions inside a single product |
| Custom API integration | None: hand-written against a specific endpoint | Rewritten for every new assistant and system pairing | Per-integration; credential sprawl grows with the matrix | One-off pulls where the interface will never be reused |
| Agent-to-agent protocols (A2A) | Agent Cards advertising another agent’s capabilities | Delegation between autonomous agents rather than access to a system | Signed agent identity plus audience-scoped tokens | Handing a whole task to another agent rather than calling a function |
When an MCP server is the wrong answer
The protocol is not free. A server is a component someone has to own, patch, monitor and re-certify, and it adds a place where untrusted text enters the model’s context. If one application will ever need one function, direct function calling is simpler and has a smaller attack surface. If the work is a whole task handed to another autonomous system, an agent-to-agent protocol fits better than a tool definition.
MCP earns its keep when more than one AI application needs the same capability, when you want a single inventory of what agents can reach, or when the access path must be governed by someone other than the team that wrote the assistant.
The MCP Security Model: Tool Poisoning, Over-Scoped Credentials and Prompt Injection
Most explanations of MCP stop at the architecture diagram. The part that decides whether a deployment ships is the threat model, and it is unusual in one way: the attack surface is the tool description as much as the tool itself. Everything a server advertises is injected into the model’s context as natural language, so an untrusted server can influence the model’s reasoning without ever being called.
OWASP added ASI04 Agentic Supply Chain Vulnerabilities as a new entry for 2026 precisely because Model Context Protocol and agent-to-agent ecosystems are dynamic: components can be poisoned at runtime, after review (Source: Iternal AI Agent Security Checklist). Four failure classes cover the bulk of what goes wrong in practice.
Tool poisoning
A tool description is not documentation — it is text loaded into the model’s context. Instructions hidden there can redirect the model before a user types anything.
Control Statically analyse tool metadata before approval; validate on the client; flag behaviour that does not match the declared purpose.
Rug pull
A server changes a tool definition after approval, so the capability a reviewer signed off on is not the one that runs.
Control Pin and version tool definitions; re-approve on change; verify integrity on connect.
Over-scoped and standing credentials
A server holds a broad, unexpiring key so every possible call works. A confused-deputy pattern then runs requests with the server’s privileges rather than the user’s.
Control Per-user identity passthrough; short-lived audience-scoped tokens; one credential per capability.
Prompt injection through tool output
What a tool returns — a ticket body, a wiki page, a search result — re-enters the context as text the model reads and may follow.
Control Treat tool results as untrusted input; separate planning from execution; gate state-changing calls behind approval.
Why validation is usually missing
Client-side validation of tool metadata is not yet the norm. The Iternal AI Agent Security Checklist records five of seven surveyed MCP clients with no static validation of tool definitions at all, alongside a broader visibility problem: most organizations cannot enumerate the agents and MCP-connected systems already running inside them (Source: Iternal AI Agent Security Checklist). Palo Alto Networks Unit 42 found that fragmented identity systems added an average of 12 hours to identity-related incident resolution (Source: Unit 42, as cited in the Iternal AI Agent Security Checklist) — the cost of learning mid-incident that nobody knows which server held which key.
Treat that as an inventory problem before it is a tooling problem: every MCP server belongs in the same register as any other production system, with a named owner, a pinned version, a declared credential and a review date.
The full threat catalogue lives in the checklist
The named attacks, protocol-level controls and spec citations are maintained in AI Agent Security Checklist, section 7.1 — agent impersonation and protocol security. Read this page to understand an MCP server; read that one to review it.
Read section 7.1 of the checklistRead this alongside the protocol’s own guidance: the MCP specification documents the authorization requirements directly, and Microsoft and Google Cloud both publish hardening guidance for the servers they host.
Authorization: OAuth 2.1, Scoped Tokens and Credentials That Expire
The specification is unusually prescriptive here, for a good reason: once a server is reachable over HTTP, the question is no longer whether the model can call a tool but whose authority the call runs under (Source: Model Context Protocol specification). Five requirements do most of the work.
| Requirement | What it means in practice | Where it comes from |
|---|---|---|
| OAuth 2.1 on the HTTP transport | A server reachable over HTTP authorizes with OAuth 2.1, including PKCE. Local stdio servers instead inherit the trust of the process that launched them. | MCP spec 2025-03-26 / RFC 7636 |
| Servers are OAuth 2.1 Resource Servers | The server validates tokens rather than issuing them, and publishes metadata so clients find the right authorization server. | MCP spec 2025-06-18 |
| Validate the token audience | A token minted for one server must be rejected by another; resource indicators bind it to what it was issued for. | RFC 8707 |
| No token passthrough | A server must not forward a received token to a downstream API; that pattern is prohibited outright. | MCP spec 2025-06-18 |
| Carry agent and user identity separately | Token exchange keeps the acting agent and the person it acts for as distinct claims, so the audit record shows both. | RFC 8693 |
The standing key underneath the protocol
Specifications describe how tokens should behave. They do not change how most enterprises issue credentials today: a service account is created, a key is generated, the key is pasted into a configuration file, and it works until someone rotates it. An agent holding that key inherits every permission the account has, for as long as the key exists, and a copy works for anyone who obtains it.
That gap is where MCP deployments fail their security review. Per-call scoping, lifetimes measured in minutes, holder binding so a stolen copy is inert, and a record written before the credential is released are all things the spec assumes an authorization server does well. Most organizations do not have one that does.
That is the problem AgentAuth exists to solve: a credential control plane for AI agents, issuing short-lived, holder-bound, shrink-only credentials from a broker inside your own infrastructure, in place of the standing keys agents authenticate with today. Applied to MCP, a tool call carries a pass minted for that call, scoped to that capability, that expires on its own and leaves a tamper-evident record.
Give every tool call a credential that expires.
MCP tells you what a token should look like. AgentAuth is the credential office that issues it — expiring, holder-bound, shrink-only passes for agent tool calls, brokered inside your own walls with a permanent record of every issuance.
Running an MCP Server On-Premise or Air-Gapped
Nothing in the protocol requires the internet. An MCP server is a process that speaks JSON-RPC over a pipe or an HTTP connection, so it runs inside a data center, a classified enclave or a laptop with the network turned off. What changes is everything the protocol quietly assumes: that packages can be fetched, that an authorization server is reachable, that a tool definition can be updated on demand.
The zero-trust posture NIST describes in SP 800-207 maps onto MCP almost directly (Source: NIST SP 800-207, Zero Trust Architecture): authenticate every request, authorize per resource rather than per network location, and assume the boundary is already compromised. In an air-gapped enclave that makes the internal controls more important rather than less.
Local process, one workstation
The host launches the server over stdio on the same machine as the AI application.
Trade-off No network exposure, no shared state, and every workstation patched individually.
Internal service, one network
The server runs as a Streamable HTTP service on internal infrastructure, reachable only from inside the boundary.
Trade-off One place to govern, log and revoke. Requires the full OAuth 2.1 posture from the previous section.
Relay to a system of record
A brokered service sits between the AI application and the system it needs, so the assistant never holds that system’s credential.
Trade-off Scope the relay, the credential and the object types; a relay with broad rights is a standing key by another name.
Fully disconnected enclave
Model, host and servers all run inside an environment with no route to the public internet.
Trade-off Nothing can be fetched at runtime: images, models, tool definitions and dependencies are all staged in advance.
Pre-production checklist
- Inventory the server: named owner, purpose, the systems it can reach, and a review date.
- Pin the protocol revision and the tool definitions; require re-approval when either changes.
- Build from a mirrored internal dependency source so a supply-chain change cannot arrive silently.
- Give the server its own identity, scoped to exactly the tools it declares and nothing beyond them.
- Route every state-changing call through an approval path, logged with both the agent and the person behind it.
- Treat all tool output as untrusted input before it re-enters the model context.
- Rehearse revocation: how a credential is killed, how a server is de-registered, how long either takes.
- Stage everything the enclave needs offline and verify integrity on import.
If the question is how to stand up the model itself rather than how to connect it, two companion guides cover that ground: the deployment mechanics in how to deploy an LLM on premise and the isolation concepts in what air-gapped AI means. The protocol documentation covers the server implementation details.
MCP Across the Iternal Stack
Iternal builds for environments where the network is the control, so the protocol shows up in three specific places.
AirgapAI Code connects to on-premise Jira, internal wikis, secure messaging and custom systems through an MCP-compatible connector framework, with the connector runtime in the same control layer as policy, audit logging and single sign-on. The intent is on-premise-first connectors: code and context stay inside the customer enclave. See AirgapAI Code.
Blockify answers the same question from the data side. MCP can be connected to Blockify, the Iternal relay can connect out to an MCP server, and Blockify is being built as the data-management access point an agent or an MCP server can call. One caveat is worth repeating: MCP plugs in, but it does not solve the ingestion pipeline. The product-support detail lives on API and enterprise integration.
AgentAuth covers the credential half the specification leaves to your authorization server: expiring, holder-bound, shrink-only passes for the calls an agent makes, issued and recorded inside your own walls. Alongside it, Ultramemory gives agents durable governed memory in your environment and the Agent Skills Library keeps the playbooks they follow versioned and approved — the three questions a security review always reaches: what can this agent touch, what does it remember, whose procedure is it following.
Continue reading
Building agents that reach real systems?
Iternal designs and builds agent architectures for regulated and disconnected environments — the servers, the credential model, the approval paths and the audit record, scoped to what your security review will actually accept.
MCP Server FAQ
An MCP server is an adapter that lets an AI application use one of your systems. It publishes a list of things it can do — read this, search that, file a ticket — and any AI application that speaks the Model Context Protocol can discover and call them. Write the adapter once and every compatible assistant inherits it.
The server publishes capabilities; the client consumes them. A client lives inside the host application — the assistant or IDE the person is actually using — and holds exactly one session with one server. Servers touch systems of record. Clients hold the model, the conversation and the approval gate that decides whether a tool call runs.
The protocol defines controls; a deployment earns the security. The recurring failures are tool poisoning (instructions hidden in tool metadata the model reads), rug pulls (a tool definition changing after approval), over-scoped standing credentials, and prompt injection arriving inside tool output. OWASP tracks this class as ASI04, new for 2026. Section 7.1 of the AI Agent Security Checklist covers each control.
Yes. A server is a process speaking JSON-RPC over a local pipe or an internal HTTP connection, so it runs inside a data center, a classified enclave or a disconnected laptop. What changes is what you must stage in advance: models, container images, dependencies and tool definitions all have to be imported and integrity-checked, because nothing can be fetched at runtime.
Only when more than one application needs the same capability. Function calling declares functions inside a single application at build time, which is simpler for a handful of stable calls. MCP moves the capability outside the application so it is discovered at runtime, reused by every compatible host, and governed once instead of once per project.
For the HTTP transport, OAuth 2.1 with PKCE. The 2025-06-18 revision classifies servers as OAuth 2.1 Resource Servers, requires them to validate the token audience so a token minted for one server is rejected by another, and prohibits token passthrough to downstream APIs. Local stdio servers instead inherit the trust of the process that launched them.
Yes, in defined ways. AirgapAI Code connects to on-premise Jira, internal wikis, secure messaging and custom systems through an MCP-compatible connector framework. Blockify can be connected over MCP, the Iternal relay can connect out to an MCP server, and Blockify is being built as the data-management access point an agent or MCP server can call. MCP plugs in; it does not solve the ingestion pipeline.