MCP Server Architecture: How to Pick the Right Server for the Job (2026)

The state of MCP in late 2026

MCP is no longer an Anthropic protocol. Anthropic donated the Model Context Protocol to the new Agentic AI Foundation under the Linux Foundation in December 2025, with founding support from Block (goose) and OpenAI (AGENTS.md). The first MCP Dev Summit ran in New York in April 2026. The current protocol revision is the 2026-07-28 revision, which replaced 2025-11-25, and it's the one your server should target.

The scale shift matters as much as the governance shift. The directional numbers:

Two things fall out of these numbers. First, "pick an MCP server" in 2026 is a real design decision with real consequences — there isn't one shape; there are many, and the wrong shape fails in production. Second, the governance problem is already shipped. Personal access tokens with organization-wide read/write scope sometimes end up in MCP server configuration files, and the industry is now building the gates that should have been there from day one.

This guide is for anyone picking a server — whether you're a solo developer wiring Claude Desktop to your file system, an engineering lead evaluating a Postgres MCP for your team, or an infosec reviewer deciding whether to approve a vendor's hosted server for production use.

The three decision axes

Every MCP server choice pivots on three questions. Answer them in order; each one narrows the field.

The axes aren't fully independent — local servers can't really use OAuth, remote servers almost always should — but treating them as independent decisions clarifies the trade-offs. Let's walk each one.

Axis 1 — Read-only vs read-write

The single most consequential decision. Everything else is secondary.

A read-only server exposes data: query a database, list files, fetch issues, read calendar events. The AI can see; it cannot change. The worst case of an LLM mistake is a confused answer, not a dropped table.

A read-write server exposes actions: insert rows, send Slack messages, merge pull requests, create calendar invites, delete files. The worst case is whatever the AI was authorized to do, done at the speed the AI wanted to do it.

For most individual-use cases, start read-only. Add write capability only when the specific write action pays off a specific pain point, and even then scope the write tools narrowly. A Postgres MCP server should offer run_query before it offers run_query and execute; a GitHub MCP server should offer list_issues before it offers list_issues and merge_pr.

The write-tool test: can you name the specific user story that justifies this write capability? "Agents might want to update records" doesn't qualify. "Our ops team spends 20 minutes a day manually updating ticket status, and this tool collapses that to 30 seconds" qualifies. Write capability without a specific job to do is a liability waiting to be exploited.

For connected categories like Database Servers, we recommend starting with the read-only variant even when a read-write version exists. Flip to read-write only when a specific workflow needs it and the credentials powering the server are scoped tighter than org-wide admin.

Axis 2 — Local vs remote

Local and remote are two completely different operational profiles sharing one protocol. The spec is the same; the deployment, auth, trust model, and failure modes are not.

Local (stdio) — the trusted-process model

A local MCP server runs as a subprocess on the user's machine, started by the client (Claude Desktop, Cursor, Cline, Continue). Communication happens over stdin/stdout as line-delimited JSON-RPC — the Streamable HTTP transport was introduced in protocol version 2025-03-26 as the replacement for the older HTTP+SSE transport, but stdio remains the default for anything running locally.

Local is right when: the data lives on the user's machine (filesystem, local SQLite, personal notes), the credentials belong to a single user, and the server is doing something that needs OS-level access the user has but the AI doesn't directly. Local servers skip the entire authentication layer because they inherit the user's process context.

Remote (Streamable HTTP) — the network-service model

A remote MCP server runs on a network host, exposed at a URL (e.g. https://mcp.example.com/mcp), and clients connect over HTTP. Multiple users and multiple clients can connect concurrently. The server is a service, not a subprocess.

Remote is right when: the data lives centrally (a company database, a shared CRM, a hosted doc system), multiple users need to use the same server with different credentials, or the client environment can't run a local process (web-based AI clients, no-code builders).

Axis 3 — OAuth vs token

Authentication is where local and remote diverge most sharply. The protocol accommodates both approaches, but which approach a server supports is a hard property, not a choice at use time.

Local: environment-based, inherited credentials

Local servers don't authenticate at the protocol layer at all. Credentials usually come from environment variables, and the specification says stdio servers should retrieve credentials from the environment. The user starts the server; the server inherits whatever creds the user put in the environment or config file; the AI client can only use the server because the user gave it permission to.

This is simple and works. It's also where personal access tokens with organization-wide read/write scope sometimes end up in MCP server configuration files — because "just paste your token here" is easy, and "scope your token to the minimum" takes thought.

Remote: OAuth 2.1, with PKCE

Remote servers use OAuth 2.1 with PKCE as the standard mechanism. The MCP spec casts the MCP server as an OAuth 2.1 resource server and the MCP client as an OAuth 2.1 client. The flow: the client discovers the server's auth endpoints via /.well-known/oauth-authorization-server, runs the standard OAuth flow, gets a token, and uses it on every subsequent request.

Bearer tokens and API keys also work on remote servers, and some hosted services (like Context7's HTTP endpoint) offer both: /mcp for API-key auth and /mcp/oauth for OAuth. Choose per client capability — OAuth authentication requires your MCP client to support the MCP OAuth specification, and not every client does yet.

// Local stdio server — no auth, env-based credentials
{
  "mcpServers": {
    "postgres": {
      "command": "mcp-server-postgres",
      "env": {
        "DATABASE_URL": "postgres://readonly:...@localhost/db"
      }
    }
  }
}

// Remote HTTP server — URL + OAuth discovery
{
  "mcpServers": {
    "notion": {
      "url": "https://mcp.notion.com/mcp/oauth"
      // Client fetches /.well-known/oauth-authorization-server,
      // runs OAuth flow, stores token, handles refresh.
    }
  }
}

Enterprise-Managed Authorization

For organizations, there's a third option as of mid-2026. The EMA extension reached stable status on June 18, 2026, and is being adopted by Anthropic, Microsoft, and Okta. EMA lets an identity provider grant a user access to all approved MCP servers at sign-in, with no shared credential to leak and no per-server authentication dance. If you're evaluating a server for team or enterprise use, EMA support is now part of the procurement bar.

Transport implications

The transport is downstream of the local-vs-remote choice, but it's worth naming explicitly because some servers support both and some don't.

The old HTTP+SSE two-endpoint transport is gone. If a server you're evaluating still only speaks HTTP+SSE, that's a signal it hasn't been updated for the 2026-07-28 spec — worth asking what else hasn't been updated.

The decision matrix

The axes above combine into a matrix. Here's the shape of server that fits common jobs:

The last row is deliberate. There are jobs where MCP is the wrong interface entirely, and "write to production database with LLM-authored commands" is one of them. The MCP server abstraction is powerful; the surface area it opens is also powerful. Not every job needs an MCP.

Governance for teams and enterprises

If you're making this decision for just yourself, skip to the next section. If you're making it for a team or an organization, the following five concerns move from "nice to have" to "required":

1. Approval. A list of MCP servers your organization has reviewed and approved. New additions go through security review, not through "someone pasted a config." An MCP Enterprise Interest Group catalogue published this year identified limited administrator visibility into MCP server connections as a deployment problem.
2. Scoping. Which tools on each server are allowed. A GitHub MCP server exposes dozens of tools; approving the server shouldn't mean approving every tool. Governance platforms (Diagrid, Lyzr, CData) now let you approve list_issues and comment while blocking merge_pr and update_repo_settings.
3. Enforcement. A gateway or policy engine that applies the scoping at request time, so a misbehaving agent can't silently invoke a disallowed tool.
4. Identity passthrough. The server acts with the identity of the calling user, not with a shared service credential. EMA is the standard mechanism here.
5. Audit. Every tool invocation logged, searchable, reviewable. The MCP spec allows for structured logging; your server should use it.

The 2025 pattern — a single team paste-installing an MCP server with a personal access token — is now the thing enterprise procurement is explicitly flagging as a risk. If you're procuring, the governance checklist is table stakes. If you're building, supporting EMA and tool-level scoping is how your server gets approved.

Common anti-patterns

Five patterns that look reasonable at first and cause problems in production:

1. The "just use admin credentials" local server. A local MCP server with an organization-wide admin token in env. Works. Also means the AI running on your laptop can do anything the admin can do, including delete production data. The right pattern: scope credentials to the minimum the server actually needs, and prefer dedicated service accounts over human admin tokens.

2. The "we'll add auth later" remote server. Shipped as an authless HTTP server to be "easier to try." Then the URL gets shared. Then it gets scraped. Model Context Protocol servers are opening significant gaps in enterprise security governance, and "we'll add auth later" is where most of those gaps start.

3. The "one tool for everything" server. A single MCP server that bundles read, write, admin, and billing tools together because they're all the same underlying API. The problem: tool scoping becomes impossible — you're stuck approving the whole bundle. The right pattern: split by permission class.

4. The "prompt-injection-resistant" claim. No MCP server is prompt-injection resistant on its own. Resistance comes from the architecture around it — least-privilege credentials, per-call user confirmation for destructive actions, scoping enforcement at the gateway. Any vendor claiming otherwise is overselling.

5. The "shadow server." Someone on your team self-hosts an MCP server pointing at an internal system. No approval, no catalog entry, no audit. Deployment best practices in 2026 treat shadow servers stood up outside governance are among the fastest-growing audit findings this year. The fix is cultural more than technical: make it faster and easier to add a server through the official path than to work around it.

What changed in the 2026-07-28 spec

If you're building or evaluating a server, know what's current. The 2026-07-28 revision made three notable changes:

• The 2026-07-28 revision deprecates three older client features: roots, sampling, and logging. If a server you're evaluating depends on these on the client side, flag it.
• Streamable HTTP is now the only supported HTTP transport. HTTP+SSE is gone.
• OAuth 2.1 with PKCE is formally the standard for remote server auth. API keys are permitted but no longer recommended as the primary mechanism for new servers.

The practical implication: a server built in late 2024 or early 2025 against the original spec needs updating to be compliant with 2026-07-28. The reference implementations have mostly been updated; many third-party servers haven't. The question to ask a vendor: "does your server implement the 2026-07-28 revision?" If they don't know what you mean, you've learned something useful.

Where this is headed

Three directions worth watching through 2027:

Enterprise-first server design. The hobby-grade MCP server with one API key and no logging is being outcompeted by servers built for procurement — per-caller rate limits, tool-level scoping, EMA support, structured audit logs. If you're building a new server, build for this bar from day one.

Managed MCP platforms. Hosted services (Diagrid Catalyst, Zapier MCP, Klaviyo's native server, Databricks via Unity Catalog, Snowflake, Salesforce Agentforce) are increasingly offering MCP as a managed capability rather than a thing you self-host. For teams without the ops capacity to host their own, this is the right default.

Agent-aware governance. Gartner is projecting task-specific AI agents in 40% of enterprise applications by the end of 2026, and the governance tooling is racing to catch up. Expect the EMA extension to spread, expect gateway-level policy engines to become standard, and expect "MCP server governance" to show up as a line item on security team roadmaps.

For the practitioner picking a server today, the summary is simple. Start on the local, read-only, env-authenticated end of each axis. Promote to remote, read-write, or OAuth-authenticated only when the specific workflow requires it. And never ship a server to production without the governance checklist in section 8 — the alternative is being one of the 24,000 secrets GitGuardian will find next year.

FAQ

Should I always start with a local MCP server?

For individual use, yes — local stdio has the fewest moving parts and lets you learn the server's behavior before promoting it to a shared context. For team use where multiple people need the same server, start remote; running N local copies of the same server across N laptops is operationally worse than running one hosted copy.

Can a local server use OAuth?

Not really. The stdio transport doesn't carry HTTP headers in the way OAuth needs; the spec is explicit that stdio servers should get credentials from the environment. If you need OAuth, you need remote. Some clients can wrap a local server behind a local HTTP proxy to simulate the remote model, but that's adding complexity to avoid a redesign that would probably be cleaner.

What's the difference between an MCP server and a REST API?

The MCP server is a standardized way for an LLM client to discover and call tools, resources, and prompts, with a protocol designed around AI invocation patterns (structured tool descriptions, type-safe arguments, streaming responses). A REST API is a general-purpose HTTP interface. You can wrap a REST API in an MCP server — many MCP servers do exactly that. The MCP server is the AI-facing side.

Is MCP going to be replaced by something else soon?

Unlikely in the short term. The donation to the Linux Foundation's Agentic AI Foundation locks in multi-vendor governance, OpenAI and Google have both adopted it, and SDK download numbers suggest serious ecosystem commitment. The spec will evolve, but the protocol itself is now shared infrastructure. Betting on MCP for 2027 feels safe; betting on any specific revision of the spec (2026-07-28 today, something else next year) requires watching the roadmap.

What's the fastest way to try an MCP server right now?

Install Claude Desktop, add one line to claude_desktop_config.json pointing at a reference server (the fetch MCP is a good starting point — small, read-only, no auth), restart, ask Claude to fetch a URL. Fifteen minutes end-to-end. For a step-by-step walkthrough, our Claude Desktop install guide covers it. For a production tutorial once you're past the first server, see the safe read-only databases tutorial.