What Is an MCP Server? A Beginner’s Guide to the Model Context Protocol

Direct answer: what is an MCP server?

The Model Context Protocol, or MCP, is an open protocol for connecting AI applications to external capabilities and context. An MCP server is a program or network service that implements the server side of that protocol. It may expose tools an application can call, resources an application can read, prompts a user can select, or negotiated extensions such as interactive MCP Apps and long-running Tasks. The server may obtain its data or perform its work through a REST or GraphQL API, a database, a filesystem, a command-line program, an SDK, local code, or another service. MCP standardizes the boundary between the AI application and that server; it does not replace those underlying systems. [S054] [S123] [S124]

Three roles must remain separate. The host is the user-facing application that coordinates the model, permissions, context, and multiple server connections. The host creates an MCP client for each server. That client sends protocol messages to one server and returns the server’s results to the host. The server supplies focused capabilities; it is not the host, not the language model, and not automatically an AI agent. [S121]

MCP was developed at Anthropic and publicly announced on November 25, 2024. The official repository credits David Soria Parra and Justin Spahr-Summers as its creators. Its first named specification revision is dated 2024-11-05, twenty days before the announcement. MCP did not invent APIs, function calling, plugins, retrieval, or AI tool use. Its central idea was to make an integration independently implementable and reusable across compatible hosts instead of rebuilding a separate adapter for every AI product. [S021] [S023] [S024]

MCP is also not the same as function calling. Function calling is generally the model-facing mechanism for selecting a structured action and producing its arguments. MCP is the application-to-server interoperability layer through which capabilities can be discovered and invoked. A host frequently translates an MCP tool into the model provider’s function- or tool-calling format, so the two mechanisms normally complement rather than replace one another. [S010]

Finally, MCP is no longer an Anthropic-only product interface. OpenAI, Microsoft, Google, AWS, Cloudflare, and other organizations have shipped official client, host, server, or platform support. That is meaningful multi-vendor adoption, although support remains product-specific and does not mean every host implements every capability identically. [S140] [S141] [S144]

The simplest accurate mental model

A current MCP deployment usually has this shape:

User
  ↓
MCP host
  ├─ model execution and conversation
  ├─ permissions and confirmation UI
  ├─ context selection
  └─ one MCP client for each connected server
        ↓
      MCP server
        ↓
REST API, GraphQL API, database, filesystem, SaaS service,
command-line program, SDK, local code, or another system

The host may be a chat product, an IDE, a coding agent, a desktop application, or a purpose-built internal AI application. A host can manage many client instances. Under the current architecture, each client communicates with exactly one server, and each request carries the protocol version and relevant client capabilities. A server may run as a local subprocess or as a remote HTTP service. [S121] [S122]

This architecture tells us what MCP standardizes and what it leaves to products:

• MCP standardizes message shapes, protocol methods, capability metadata, transport bindings, version declarations, and certain authorization behavior.
• The host decides which model to use, which server capabilities to reveal to that model, how to obtain user consent, how much context to supply, and how to render results.
• The server decides how to implement its capabilities and how to reach the underlying system.
• The underlying system still enforces whatever permissions, limits, data models, and business rules it owns.

Two hosts can therefore connect to the same server yet provide different user experiences. One may auto-select tools; another may require confirmation for every call. One may support prompts and resources; another may expose only tools. Protocol compatibility is real, but it does not guarantee identical model behavior, permissions, interfaces, or outcomes.

MCP host vs client vs server

The words host, client, and server are often collapsed in casual explanations. That creates architectural and security confusion.

MCP host vs client vs server comparison table

Role	Current meaning	Typical responsibilities	What it is not
Host	The container and coordinator for an MCP-enabled application	Runs or invokes the model, creates clients, manages permissions, aggregates context, presents confirmations and results	Not an MCP server
Client	The protocol component created by a host to communicate with one server	Sends requests, attaches version and capabilities, receives results and notifications	Not necessarily a standalone app
Server	A local program or remote service implementing the server side of MCP	Exposes tools, resources, prompts and extensions; calls underlying systems	Not automatically an agent or model
Underlying system	The API, database, filesystem, SaaS product or code behind the server	Performs domain-specific work and applies its native controls	Not MCP merely because a server calls it

The host is the main trust and orchestration boundary. The current specification assigns it responsibility for connection permissions, security policy, consent, user authorization decisions, AI integration, and context aggregation. It also aims to isolate servers from one another and to prevent a server from seeing an entire conversation unless the host deliberately supplies relevant information. [S121]

A client is narrower. A host creates one client per server connection. A product may contain both host and client code, but the concepts remain different. This matters because saying “the client decided” may actually mean the user-facing host chose a permission policy, selected a model, or transformed a server’s tool schema.

An MCP server is similarly narrower than many marketing definitions suggest. It is not simply “an API for AI.” It is an implementation of protocol-defined server behavior. The same server can wrap an API, but the API and server remain separate layers.

What can an MCP server expose?

The durable core of MCP is not one universal “tool” abstraction. Servers can expose several different primitives, each intended for a different interaction model.

Tools: executable operations

An MCP tool is an operation a server makes discoverable and callable. A tool definition includes a unique name, descriptive metadata, an input schema, and—when provided—an output schema and annotations. Clients discover tools through tools/list and invoke them through tools/call. Results may contain text, images, audio, links to resources, embedded resources, and structured content. [S123]

A tool is model-controlled in the protocol’s interaction model: the host can expose it to a model and the model can propose using it. That phrase does not mean the model directly owns the connection or bypasses the host. The host remains able to hide tools, validate arguments, request confirmation, apply policy, reject a call, or invoke the tool programmatically without model reasoning.

Tool annotations can describe likely properties such as read-only or destructive behavior. They are hints, not enforceable guarantees. The current specification explicitly says clients must treat annotations from untrusted servers as untrusted unless the server itself is trusted. A malicious server can lie in metadata. [S054] [S123]

An MCP tool is not the same thing as:

• a programming-language function;
• an arbitrary API endpoint;
• an OpenAI function definition;
• an Anthropic tool definition;
• a button in a product interface.

Mappings can exist between these forms. The distinction is which layer defines and transports the capability.

Resources: URI-identified context and data

An MCP resource is server-exposed data identified by a URI. The client may list resources, read a particular resource, or use a resource template to construct a URI. Resources can represent files, documents, database records, logs, API responses, images, generated reports, or other content. [S124]

Resources are described as application-driven. The host or user interface generally decides when to browse, attach, read, or refresh them. A resource is not merely whatever a tool returns. A tool result may contain a link to a resource or embed resource content, but that does not erase the distinction between the operation and the addressable data object.

In current MCP, resource and list-change notifications use the broader subscriptions/listen mechanism. Older specifications exposed resources/subscribe and resources/unsubscribe; those methods were replaced in 2026-07-28. [S055]

Prompts: server-provided templates

An MCP prompt is a protocol-exposed prompt or prompt template that a server can list and retrieve. It may accept arguments and return structured messages or instructions. The host can present it as a slash command, menu item, workflow starter, or another user-selectable control. [S125]

A protocol prompt is not synonymous with:

• the model’s system prompt;
• every instruction in a conversation;
• prompt engineering in general;
• hidden server instructions;
• arbitrary text returned by a tool.

Prompts are described as user-controlled because the user normally chooses when to invoke them. The protocol does not mandate a particular interface.

Elicitation: requesting additional user input

Elicitation lets a server request more information from the user through the client and host. Current MCP supports form-style elicitation for structured, non-sensitive information and URL-mode elicitation for interactions that should occur on an external site. Form mode must not be used to request passwords, API keys, access tokens, payment credentials, or similarly sensitive secrets. [S126]

In 2026-07-28, elicitation during another request is represented through Multi Round-Trip Requests rather than a free-standing server-initiated JSON-RPC request. The server returns an input_required result, the host gathers the needed input, and the client retries the original request with the responses. [S129]

Extensions: optional features outside the core

MCP’s extension framework allows capabilities to evolve independently from the core protocol. Extensions require explicit support rather than being assumed merely because both parties speak MCP.

Two important examples are:

• MCP Apps, which let a tool point to an interactive HTML interface that a compatible host can render in a sandboxed frame. The app and host communicate through an extension-specific JSON-RPC dialect over browser messaging. An MCP App is not a generic web app and support varies by host. [S136] [S059]
• Tasks, which represent durable asynchronous work. A server can return a task handle, and a supporting client can poll for status, submit mid-flight input, cancel cooperatively, and retrieve the final result after reconnecting. Ordinary tool calls do not become Tasks merely because they take a few seconds. [S137] [S060]

How an MCP server works today

For the complete role boundary, read MCP host vs client vs server; for a shorter lifecycle-focused treatment, see how MCP works.

The following sequence is a simplified current tool flow. It shows the main responsibilities without pretending every host uses the same model loop or permission interface.

Step 1: the host is configured to reach a server

For a local server, configuration often includes a command, arguments, working directory, and selected environment variables. For a remote server, configuration usually includes an HTTPS endpoint and an authorization flow or token policy.

Configuration is a host concern, not a core protocol installation format. Different products may use JSON files, graphical marketplaces, organization catalogs, command-line commands, desktop extensions, or managed connectors.

Step 2: the client learns what the server supports

Every current request identifies the protocol revision and client capabilities in request metadata. Servers must implement server/discover, which can report supported protocol versions, capabilities, identity, and cache hints. A client may call it before another operation, but it is not required to do so; a client can send an ordinary request and handle an unsupported-version response. [S127] [S055]

This distinction matters because “MCP performs a discovery handshake” is no longer a correct general description of current MCP. Discovery exists, but the initialization handshake does not.

Step 3: the client lists relevant capabilities

For tools, the client sends tools/list. For resources it may use resources/list or resources/templates/list. For prompts it uses prompts/list. Current list results are deterministically ordered and carry cache hints, allowing clients to avoid repeatedly downloading unchanged catalogs and to stabilize upstream prompt caches. [S123] [S128]

A host is not required to expose the entire catalog to the model. It may filter by user permission, server trust, workspace, policy, relevance, or model limits.

Step 4: the host maps tools into the model interface

Most language models do not natively emit MCP wire messages. The host typically converts selected MCP tool definitions into the model provider’s tool- or function-calling representation. The model may then return a structured proposal such as:

tool: create_issue
arguments:
  repository: example/project
  title: Fix login timeout
  body: ...

The host validates and mediates this proposal. This is the point where MCP and function calling often meet: function calling produces the model’s structured intent; MCP supplies the independently hosted capability and the protocol used to invoke it.

Step 5: the host applies permission and policy

A mature host may check:

• whether the server is approved;
• whether the user granted the necessary upstream account access;
• whether the tool is read-only or potentially destructive;
• whether the arguments fall within allowed paths, repositories, accounts, or environments;
• whether the call needs explicit confirmation;
• whether prompt injection or untrusted content influenced the proposal.

The protocol can carry metadata and authorization information, but it cannot force every host to implement a safe confirmation interface. The core specification says MCP cannot enforce all of its own security principles at the protocol level. [S054]

Step 6: the client invokes the server

The client sends tools/call with the tool name and arguments. Under current MCP, the request is self-contained. It does not depend on a previous initialization exchange, hidden protocol session, or Mcp-Session-Id. If the operation needs application state from an earlier call, the server must use an explicit identifier or handle that the client supplies with the request. [S130] [S055]

Step 7: the server performs the underlying operation

The server may call an API, query a database, read a file, run a browser, invoke an SDK, or execute local code. The underlying system may still reject the action because of its own authorization rules, validation, rate limits, concurrency controls, or business logic.

This is why MCP does not replace APIs. It frequently sits immediately above them.

Step 8: the result returns through the host

A tool result can include human-readable content, structured content, media, or references to resources. The host decides what enters model context, what the user sees, whether another model turn is needed, and whether follow-up calls are permitted. [S123]

If the server needs more information before finishing, it can return an input_required result through MRTR. If it needs durable asynchronous execution and both sides support the Tasks extension, it can return a task handle instead of holding a connection open. [S129] [S137]

Current MCP is stateless—but an MCP application can maintain state

The word stateless causes frequent confusion.

In current MCP, statelessness means that every protocol request contains the information needed to process that request. A server must not infer protocol version, client identity, client capabilities, or conversational context from previous requests on the same connection. An open stdio process is not a protocol session, and a remote connection is not automatically a conversation. [S130]

It does not mean:

• a database cannot retain records;
• a server cannot maintain job state;
• a host cannot maintain a conversation;
• OAuth tokens have no state or lifetime;
• Tasks cannot remain active;
• an application cannot issue an explicit handle and require it on later calls.

For example, a server that begins a data migration can return migration_7f31 and require that value in later status or cancel calls. That is explicit application state. What current MCP rejects is hidden protocol state that exists only because a particular request happens to reach the same process or transport session.

This change was made for ordinary distributed-systems reasons. Self-contained requests can be sent to any server instance behind a round-robin load balancer. They reduce sticky-session requirements, shared session stores, connection affinity, and failure recovery complexity. Header-visible method and capability metadata also makes routing and policy easier for gateways. [S058] [S053]

Local MCP servers

Our transport guide goes deeper on stdio, Streamable HTTP, and their operational tradeoffs.

A local MCP server is an MCP implementation launched or accessed on the user’s machine or local environment. The canonical historical and current pattern uses stdio:

1. The client launches the server as a subprocess.
2. The client writes newline-delimited JSON-RPC messages to the process’s stdin.
3. The server writes protocol messages to stdout.
4. The server may write logs to stderr.
5. The server must not mix ordinary logging text into stdout. [S132]

Local servers are attractive because they can:

• work with local files, repositories, developer tools, and desktop applications;
• avoid exposing a network service;
• start and stop with the host;
• use existing command-line programs and local credentials;
• be small wrappers around code already present on the machine.

The important security trade-off is code execution. Installing or launching a local server means trusting a package, binary, script, its dependencies, and its update path. A filesystem server can read only what its implementation and operating-system permissions allow—but those permissions may be broad. A server launched with environment variables may receive every explicitly passed secret. A malicious package can perform work outside the MCP methods it advertises because it is ordinary executable code.

Local does not automatically mean safe, private, or offline. A local process may still send data to remote APIs. Conversely, a carefully sandboxed local server can be more tightly constrained than a remote service. The decisive questions are provenance, permissions, network access, sandboxing, credentials, and host behavior—not the word local.

Remote MCP servers

A remote MCP server is reachable over a network, normally through Streamable HTTP. Current Streamable HTTP uses a single MCP endpoint that accepts POST requests. Each JSON-RPC request or notification is sent in its own HTTP POST. A request may receive a single JSON object or a request-scoped Server-Sent Events stream when streaming is needed. Long-lived change notifications use the response stream of subscriptions/listen. [S131]

Remote operation introduces concerns that a local subprocess can often avoid:

• user and service identity;
• authentication and delegated authorization;
• token audience and issuer validation;
• multi-tenancy and tenant isolation;
• network routing and TLS;
• rate limits and abuse controls;
• latency, retries and timeouts;
• horizontal scaling;
• monitoring and audit;
• data residency;
• server availability and support.

MCP’s HTTP authorization framework treats a protected MCP server as an OAuth resource server. The server publishes protected-resource metadata, the client discovers or identifies the authorization server, and access tokens must be intended for the MCP resource. Current guidance favors Client ID Metadata Documents and deprecates Dynamic Client Registration. [S133] [S135]

OAuth is not a synonym for authentication and is not a complete security guarantee. It can authorize a client to act with certain access, but security still depends on token validation, scopes, consent, upstream permissions, server code, tenant isolation, host policy, and protection against prompt-mediated misuse.

Local vs remote MCP

Local vs remote MCP comparison table

Question	Local server	Remote server
Typical process model	Host launches or reaches a local process	Shared or dedicated network service
Common transport	stdio	Streamable HTTP
Installation	Package, binary, extension, source checkout or managed bundle	URL, connector entry or catalog installation
Authentication	Often environment credentials or local OS context	Usually OAuth or another network authorization scheme
Main trust concern	Executing code and dependencies on the machine	Trusting a service, network path, tenancy and token handling
Secrets	Often passed through selected environment variables or local stores	Usually access tokens, service credentials or delegated identity
Scaling	Usually one user or one environment	Can be multi-user, multi-tenant, serverless or horizontally scaled
Latency	Usually low, though startup can be noticeable	Includes network and service latency
Offline use	Possible if the server and underlying systems are local	Usually not
Primary failure domain	Local process, package and host machine	Network, service, identity provider and upstream APIs
Security controls	OS permissions, sandbox, allowlists, process isolation	TLS, OAuth, audience checks, policy gateway, tenant isolation, audit
Best fit	Files, source trees, local tools, desktop automation	SaaS, shared enterprise data, public APIs, managed services

Local and remote MCP coexist. The 2026 architecture did not replace local stdio with cloud services.

Does MCP use SSE?

The accurate answer is version-specific:

• 2024-11-05: MCP had a transport now called HTTP+SSE. The server opened a long-lived SSE channel to the client and supplied a separate POST endpoint for client-to-server messages. [S024]
• 2025-03-26: Streamable HTTP replaced HTTP+SSE. It used a single endpoint and could return either JSON or SSE. The early form still had initialization and optional protocol sessions. [S036] [S038] [S156]
• 2026-07-28: Streamable HTTP removed the GET stream and protocol-level sessions. A current request can still receive a request-scoped SSE response, and subscriptions/listen can keep a response stream open for selected notifications. [S131]

Therefore, both of these statements are misleading:

“MCP uses SSE.”

“MCP no longer uses SSE.”

Current remote MCP can use SSE as a response streaming format. What is deprecated is the original HTTP+SSE transport architecture.

MCP and JSON-RPC 2.0

MCP messages use JSON-RPC 2.0. JSON-RPC defines a compact structure for:

• a request, which has an identifier, method, and optional parameters;
• a response, which has the matching identifier and either a result or error;
• a notification, which has no identifier and expects no response;
• an error, which has a code, message, and optional data. [S001]

JSON-RPC does not specify whether messages travel through stdin, HTTP, sockets, or another channel. MCP adds its own methods, schemas, role model, capabilities, versioning, transports, authorization rules, and extensions. Saying “MCP is JSON-RPC” is therefore like saying a particular application protocol is merely its envelope format. JSON-RPC is foundational, but it is not the whole protocol.

Current MCP also does not use JSON-RPC batching. Batching was added in 2025-03-26 and removed in 2025-06-18, an example of the protocol reversing a recently shipped design rather than accumulating features indefinitely. [S036] [S043]

MCP vs function calling

This section is a concise handoff. Read the dedicated MCP vs function calling comparison for the 29-dimension matrix, provider schemas, worked example, decision tree, and 50-question FAQ.

The phrase function calling describes a model or model API producing a structured request to use an operation. The application supplies descriptions and schemas; the model returns a function or tool name plus arguments; application code decides whether and how to execute it. Function calling existed before MCP and remains widely used. [S010]

MCP addresses a different boundary. It defines how an application communicates with independently implemented servers that expose capabilities. A host can discover an MCP server’s tools and then present selected tools to its model through that provider’s function-calling interface.

MCP vs function calling comparison table

Property	Native function or tool calling	MCP
Primary boundary	Model ↔ application	Application/client ↔ capability server
Main purpose	Let a model propose structured actions	Let applications discover and invoke external capabilities through a common protocol
Where definitions usually live	In the application request or model integration	On the MCP server and discovered by the client
Server independence	Not required	A central design goal
Discovery	Usually supplied by application code	Protocol methods such as tools/list, resources/list and prompts/list
Transport	Part of the model provider’s API interaction	stdio, Streamable HTTP or a custom binding
Versioning	Provider/API specific	Date-based MCP protocol revisions
Authorization	Application-specific	HTTP authorization framework plus host/server controls
Resources and prompts	Not normally protocol primitives	Separate MCP primitives
Reuse across hosts	Requires application integration work	Possible across compatible hosts, subject to version and feature support
Model required	Usually yes	No; an MCP client can invoke methods programmatically
Replaces the other?	No	No

A useful implementation sentence is:

Function calling helps the model say what action it wants; MCP helps the application find and reach the independently implemented capability that can perform it.

This division is not absolute. A host can invoke an MCP tool without a model, and a model-facing tool implementation can itself call an MCP server. The point is architectural level, not exclusivity.

MCP vs APIs, REST, GraphQL and OpenAPI

The focused MCP vs API comparison expands this architectural distinction.

MCP does not replace general-purpose APIs.

A common server looks like this:

MCP host
  ↓
MCP client
  ↓  Model Context Protocol
MCP server
  ↓  REST / GraphQL / SDK / SQL / CLI
Underlying service

The underlying API remains useful to mobile apps, websites, backend services, scripts, partners, and ordinary software. The MCP server provides a curated, model- and application-facing capability layer above or alongside that API.

That extra layer can add value by:

• combining several API calls into one meaningful tool;
• selecting safer or more intelligible schemas;
• hiding irrelevant endpoint complexity;
• applying user-specific authorization;
• returning model-friendly summaries plus structured output;
• exposing resources and prompts as well as actions;
• making the same capability discoverable by several compatible hosts.

It can also introduce cost: another service to deploy, another schema to maintain, another trust boundary, and another place for authorization mistakes.

OpenAPI describes HTTP APIs. It can document paths, operations, request bodies, responses, and authentication schemes. MCP defines live client-server protocol behavior, primitives, version metadata, transport semantics, and extensions. Tools can be generated from OpenAPI descriptions, but automatic conversion rarely proves that the resulting tools are safe, semantically clear, appropriately scoped, or pleasant for models to use.

GraphQL is a data query and mutation language. MCP is not an alternative query language. An MCP server may call GraphQL and expose selected operations as tools or resources.

MCP vs plugins and connectors

A plugin is a broad product term. Browser extensions, IDE extensions, ChatGPT plugins, and application add-ons use different architectures. A plugin is not automatically an MCP server.

OpenAI’s 2023 ChatGPT plugin design, for example, used a product-specific manifest, an OpenAPI description, remote APIs, and plugin-specific hosting and approval rules. It addressed similar connectivity needs but belonged to one host ecosystem. [S009]

MCP instead defines a host-independent protocol boundary. A product may package an MCP server inside an extension, install it through a marketplace, or call the feature a connector. Those distribution and product labels do not change the protocol roles.

Connector is especially ambiguous. A company may use it for:

• an official remote MCP server;
• a host configuration that points to a server;
• a proprietary integration unrelated to MCP;
• an application bundle containing authorization, UI and server metadata;
• a managed proxy to an MCP server.

For example, Claude’s current “custom connector” feature connects to remote MCP servers, while its broader connector catalog also reflects Anthropic product concepts. The word connector should not be assumed to map one-to-one to MCP server. [S145] [S146]

Why MCP is compared with the Language Server Protocol

MCP’s own early material and current specification identify Microsoft’s Language Server Protocol, or LSP, as an architectural influence. [S054] [S013]

Before LSP, an editor vendor and a language-tool vendor often needed a specific integration for each pairing. Microsoft describes this as an M-by-N problem: many editors multiplied by many language implementations. LSP introduced a shared client/server protocol so editors could act as clients and language services could act as servers. [S139]

MCP applies a comparable pattern:

Without a shared protocol

AI application A ── custom integration ── service X
AI application A ── custom integration ── service Y
AI application B ── custom integration ── service X
AI application B ── custom integration ── service Y

With MCP

AI hosts ── MCP clients ↔ MCP servers ── underlying systems

The analogy explains:

• independent client and server implementations;
• JSON-RPC;
• capability descriptions;
• reuse across products;
• the reduction of pairwise integration work.

It breaks down when treated literally. LSP primarily concerns development-language services such as completion, diagnostics, navigation, and refactoring. MCP can trigger arbitrary external actions, access sensitive data, invoke browsers, write files, call SaaS services, and operate across internet trust boundaries. Its permission, authorization, prompt-injection, package-supply-chain, and multi-tenant risks are much broader.

MCP also does not mathematically eliminate N × M cost. Hosts still differ in supported protocol versions, optional capabilities, schema constraints, model behavior, confirmation interfaces, and authorization handling. Servers still need domain-specific implementation and often host-specific testing. MCP reduces a class of duplicated wiring; it does not abolish integration engineering.

Are MCP servers AI agents?

No—not inherently.

An agent is generally an application or system that selects and performs actions toward a goal, often across several steps and with feedback. An MCP server is a protocol endpoint that exposes capabilities.

Possible relationships include:

• an agent uses several MCP servers;
• a host uses MCP tools inside an agent loop;
• an MCP server wraps an external agent;
• a tool starts a long-running agentic job and returns a Task;
• a server uses an LLM provider internally;
• a completely deterministic server exposes database or filesystem operations.

Only some of those servers perform agentic work. Calling every server an agent obscures where planning, model execution, permissions, and state actually live.

MCP itself is not an LLM. It can be used by applications with no model at all. A test client, automation program, or administrative tool can list and invoke server capabilities directly.

Why MCP was created

AI applications were integrating external systems before MCP. Developers used API clients, retrieval pipelines, plugins, function calling, framework-specific tools, browser automation, and custom connectors.

The remaining problem was reuse across applications. A database integration written for one assistant was not automatically available in another. A SaaS provider could expose an API yet still need separate model-facing adapters, schemas, authentication flows, context handling, and UX work for multiple hosts.

Anthropic’s launch announcement described the resulting fragmentation as separate connectors for each data source and AI application. MCP proposed a common interface so a server could be implemented once and made available to multiple compatible hosts. [S021]

That claim should be interpreted carefully. MCP standardizes the protocol boundary, not the full product experience. The server still has to be built. Hosts still choose how to use it. OAuth clients and upstream accounts still have to be configured. Interoperability can fail because of versions, extensions, schema support, or policy. The realistic benefit is reduced duplication and clearer separation—not cost-free universal compatibility.

A brief origin and release chronology

See the primary-source MCP timeline for the full chronology.

• September 24, 2024: the public specification repository’s initial import already described host, client, server, session, tools, resources, prompts, sampling, stdio, SSE and LSP inspiration. This is the earliest public repository evidence located for the protocol. [S013]
• November 5, 2024: the first named specification revision was dated 2024-11-05. It used an initialization handshake, stateful sessions, stdio and HTTP+SSE. [S024]
• November 19, 2024: the earliest verified public reference-server repository commit contained an “everything” test server and early Google Drive, Git, Postgres and Puppeteer implementations. This does not establish the first internal MCP server. [S019]
• November 25, 2024: Anthropic publicly announced MCP, SDKs, Claude Desktop support and example integrations. [S021]
• March 26, 2025: MCP added OAuth-based authorization and Streamable HTTP, replacing HTTP+SSE. [S036]
• June 18, 2025: authorization hardened further, elicitation and structured tool output arrived, and JSON-RPC batching was removed. [S043]
• November 25, 2025: the one-year revision added richer elicitation and experimental Tasks. [S049]
• January 26, 2026: MCP Apps launched as the first official extension. [S059]
• May 21, 2026: the 2026-07-28 release candidate was frozen for implementation testing. [S053]
• July 28, 2026: the current specification became generally available with a stateless core, no initialization handshake or protocol sessions, MRTR, header-based routing, caching and formal extensions. [S055] [S058]

The answer to “when was MCP released?” is therefore November 25, 2024 for the public announcement, while 2024-11-05 is the original named protocol revision and September 24 is the earliest public repository evidence in the current record.

Why older MCP guides disagree with current MCP

The 2026-07-28 migration guide explains the compatibility boundary method by method.

Many articles and tutorials were correct when written but describe a different protocol era.

Why older MCP guides disagree with current MCP comparison table

Topic	MCP through 2025-11-25	MCP 2026-07-28
Initialization	initialize request and initialized notification	Removed
Protocol sessions	Connection/session state; Streamable HTTP could use Mcp-Session-Id	Removed
Version and capabilities	Exchanged during initialization	Included in each request’s _meta
Up-front discovery	Initialization response	Optional client call to mandatory server/discover implementation
Server-to-client requests	Server could issue requests such as elicitation or sampling	Represented through MRTR input_required results and retries
Remote HTTP GET stream	Available in earlier Streamable HTTP	Removed
Long-lived changes	Earlier GET stream and resource subscription methods	subscriptions/listen
Routing	Gateway often needed body awareness or connection affinity	Mcp-Method and Mcp-Name headers expose routing metadata
List caching	No general result cache-hint model	Complete list/read/discovery results carry cache information
Tasks	Experimental core feature in 2025-11-25	Official extension
Roots, sampling, logging	Active client/core features	Deprecated; still present during migration
DCR	Authorization registration option	Deprecated in favor of Client ID Metadata Documents

The current changelog calls these changes breaking. Compatibility therefore requires clients and servers to know which era they implement rather than assuming that “MCP support” is one timeless feature. [S055] [S135]

Is MCP secure?

For a dedicated threat-and-defense treatment, read MCP security.

There is no useful one-word answer.

MCP includes security-relevant protocol features, especially for remote HTTP authorization, request metadata, Origin validation, capability declarations and user consent. But protocol compliance alone cannot establish that a server, package, host, model interaction, or deployment is safe.

A practical security model has at least eight layers:

Is MCP secure? comparison table

Layer	Representative questions
Protocol revision	Does the implementation follow current transport, authorization and deprecation rules?
SDK and library	Is the version patched? Does it validate Origin, tokens and tenant boundaries correctly?
Server code	Does it validate arguments, restrict paths, avoid shell injection and enforce upstream permissions?
Package supply chain	Is the package authentic, maintained, pinned and free of malicious dependencies?
Deployment	Is the service bound safely, isolated, monitored, rate-limited and separated by tenant?
Authorization	Are tokens audience-restricted, scopes minimal and issuer/resource relationships validated?
Host behavior	Are tools filtered, confirmations meaningful and untrusted metadata treated skeptically?
Model and data	Can malicious content or tool output manipulate subsequent model behavior?

Prompt injection and tool poisoning

MCP can carry data that contains instructions a model may follow. A malicious document returned as a resource, an attacker-controlled webpage used by a browser tool, or a poisoned tool description can attempt to influence the model.

Invariant Labs’ April 2025 research demonstrated attacks using instructions hidden in tool descriptions, later changes to descriptions, and one server attempting to influence how the model used another server. The researchers called these patterns tool poisoning, rug pulls and tool shadowing. [S108]

These attacks involve several layers:

• The server supplies untrusted metadata or output.
• The host chooses whether to place that material in model context.
• The model may treat data as instructions.
• Permission design may allow the resulting tool proposal.
• Another system may contain valuable data or write authority.

MCP transports the material; it does not automatically solve prompt injection. Nor does every prompt-injection incident prove a flaw in the wire protocol. Mitigation requires source trust, metadata inspection, content labeling, model defenses, least privilege, confirmation design, and separation of sensitive capabilities.

Local process and package risk

A local stdio server is executable software. It can do anything allowed by its operating-system identity, not merely what its advertised tool list suggests. Hosts such as VS Code now warn that local servers can run arbitrary code and offer sandboxing controls, but these are host features rather than universal protocol guarantees. [S141]

Supply-chain risks include typosquatting, compromised maintainers, malicious install scripts, dependency compromise, abandoned packages and unsafe automatic updates. The official MCP Registry verifies namespaces and hosts metadata, but delegates code scanning to package registries and downstream aggregators. Registry inclusion is therefore not a security certification. [S067]

Remote authorization risk

Remote servers add token and identity risks. Official guidance warns against token passthrough, in which a server accepts a token not intended for it and forwards that token to another service. It also discusses confused-deputy attacks, server-side request forgery, OAuth mix-up, redirect manipulation, and state-handle hijacking. [S134]

A token must be validated for the server and authorization context that receives it. Broad scopes can turn a model mistake or prompt injection into a damaging action. Service accounts can break user-level permission inheritance. Delegated OAuth can preserve upstream permissions only when the server uses it correctly.

Implementation vulnerabilities are not all protocol flaws

The MCP ecosystem has also experienced conventional software vulnerabilities. Public advisories have covered missing authentication and cross-site scripting in the MCP Inspector, DNS-rebinding weaknesses in SDK HTTP defaults, and a TypeScript SDK multi-client isolation defect. [S109] [S110] [S111] [S147]

These incidents are important, but they must be classified precisely. A vulnerability in an Inspector proxy, SDK default, or server implementation does not automatically invalidate the abstract protocol. Conversely, calling something “only an implementation bug” does not make its operational impact unimportant.

A practical MCP server trust checklist

Before enabling a server, answer:

1. Who maintains it, and can that identity be verified?
2. Is it official, vendor-supported, independently maintained, or an unreviewed wrapper?
3. Which exact package, image, binary or remote endpoint will run?
4. Is the version pinned, maintained and free of known advisories?
5. What files, repositories, accounts, APIs and network destinations can it access?
6. Which credentials are supplied, and can their scopes be reduced?
7. Is the server read-only, write-capable, destructive, or capable of arbitrary code execution?
8. Are tool descriptions and annotations treated as untrusted?
9. Does the host show arguments and target systems before dangerous actions?
10. Can the server be sandboxed or isolated?
11. Does a remote deployment validate Origin, issuer, token audience and tenant identity?
12. Are logs, audit records, revocation and incident-response procedures available?
13. Can output from untrusted data sources influence access to more sensitive tools?
14. How are updates reviewed and rolled back?
15. Is there a simpler integration with a smaller security surface?

A “trusted” toggle should be treated as a consequential security choice, not an installation convenience.

Current MCP ecosystem: hosts, SDKs and discovery

Current product support changes faster than the core historical facts below. The following snapshot was verified on August 25, 2026.

Official SDKs

The project currently lists ten official SDKs. TypeScript, Python, C# and Go are Tier 1; Java, Rust and Ruby are Tier 2; Swift, PHP and Kotlin are Tier 3. Tiers describe feature completeness, protocol support and maintenance commitment rather than language quality. [S138] [S073]

An SDK is not the protocol. It is an implementation aid for building clients and servers. A server built without an official SDK can still be compliant, and software using an official SDK can still be insecure or configured incorrectly.

Registry and distribution

The official MCP Registry remains in preview. It stores standardized server metadata, provides namespace verification and an API, and points to packages or remote endpoints. It does not replace npm, PyPI, container registries or vendor hosting. It also does not support private servers in the public registry and is intended substantially as an upstream source for downstream catalogs and marketplaces. [S067] [S066]

This distinction separates:

Protocol compatibility
        ≠
Software packaging
        ≠
Registry metadata
        ≠
Security review
        ≠
Host installation UX

Representative host support

See the maintained MCP host compatibility matrix for plan, surface, transport, and verification caveats in a downloadable format.

• Claude: Anthropic supports custom remote MCP connectors across documented Claude surfaces, subject to plan, connector-count, owner, and network requirements. Those connections originate in Anthropic’s cloud. Local MCP is a separate Claude Desktop path, not the cloud custom-connector path. [S145] [S146]
• ChatGPT: ChatGPT supports remote MCP through plan- and surface-dependent apps and developer mode. Full MCP actions are documented as a web beta for Business, Enterprise, and Edu, while Pro supports read/fetch in developer mode. It does not connect directly to a local server; private or developer-machine servers require Secure MCP Tunnel. Agent mode, Deep Research, and mobile have additional limits. [S140]
• VS Code: Microsoft’s host supports local and remote servers, tools, resources, prompts and MCP Apps, with installation, trust, and organization-policy controls. Its documented sandbox applies only to local stdio servers on macOS and Linux—not Windows—and sandboxed server tool calls are auto-approved. [S141] [S143]
• Gemini CLI: Google’s CLI documents stdio and Streamable HTTP, plus SSE endpoint configuration for compatibility. It also documents tools, resources, prompts, OAuth, filtering, confirmation, and trusted-server behavior. Trust can bypass confirmations, and browser-based OAuth needs care in headless, SSH, or container environments. [S144]

These examples establish genuine multi-vendor adoption. They do not imply equal capability coverage or wire-version compatibility in every release.

What an MCP server is not

An MCP server is not inherently:

• an AI model;
• an autonomous agent;
• a database;
• an API endpoint;
• a function definition;
• an OpenAPI document;
• a plugin;
• a marketplace listing;
• a package on npm;
• a remote cloud service;
• a local subprocess;
• a security boundary that can be trusted without review.

It may be implemented with or packaged as some of those things. The point of terminology control is to keep protocol, implementation, deployment, distribution and product experience separate.

Limitations of MCP

A credible explanation should not end with the interoperability promise alone.

“Works with MCP” is underspecified

A compatibility claim should identify:

• protocol revision;
• transport;
• authorization method;
• tools, resources, prompts and client features;
• extension support;
• schema restrictions;
• host-specific limitations.

A server can be correct for 2025-11-25 and incompatible with a client expecting only the modern 2026-07-28 era unless one side implements fallback.

Interoperability is not identical behavior

Hosts differ in model choice, tool selection, permissions, context construction, retries, result rendering and error handling. A server can interoperate at the protocol level yet perform much better in one host than another.

Tool catalogs consume attention and context

Large tool sets can increase discovery work, schema processing and model context cost. Hosts may search, filter, cache, group or lazily load tools. Those optimizations are not equivalent to a universal MCP semantic-discovery solution.

Security responsibility is distributed

MCP deliberately leaves substantial responsibility to hosts and server implementations. This flexibility supports many products, but it also means “MCP-compatible” is not a meaningful security rating.

Remote authorization is complex

OAuth discovery, client identity, issuer binding, resource indicators, scopes, consent and upstream account permissions are difficult to implement correctly. MCP supplies a framework; it does not make distributed identity simple.

Server quality varies

A short wrapper around an API can be easy to prototype. A production server needs input validation, retries, idempotency, rate limits, tenant isolation, audit, secrets management, versioning, observability, deprecation and support. Easy creation can increase the number of low-quality or abandoned servers.

Semantic portability remains incomplete

The protocol standardizes shapes and methods, not the meaning of every domain operation. Two issue-tracker servers may choose different tool names, schemas and safety boundaries. Models and users still need to understand those differences.

Frequently asked questions

What does MCP stand for?

MCP stands for Model Context Protocol.

What is an MCP server?

It is a program or network service implementing the server side of MCP and exposing protocol-defined capabilities to compatible clients.

What is an MCP client?

A client is the component a host creates to communicate with one MCP server. Under current MCP it attaches the protocol version and client capabilities to each request.

What is an MCP host?

The host is the user-facing container and coordinator. It runs or invokes the model, manages clients, permissions, context and result presentation.

Who created MCP?

The official repository credits David Soria Parra and Justin Spahr-Summers as the creators. [S023]

When was MCP released?

Anthropic publicly announced MCP on November 25, 2024. The first named specification revision is 2024-11-05, and the earliest public repository evidence located here is September 24, 2024.

Why is the first specification dated November 5, 2024?

The date is the protocol revision identifier, not the announcement date. Public repository work predated both dates. The public record does not fully document Anthropic’s internal version-freeze process.

What was the first MCP server?

No definitive first internal server can currently be established. The earliest verified public reference-server repository commit, dated November 19, 2024, contained several implementations rather than one uniquely documented first server. [S019]

Is MCP an API?

MCP is a protocol and interface standard. A server exposes an MCP interface and may call one or more underlying APIs.

Does MCP replace REST APIs?

No. MCP servers commonly call REST APIs and provide a curated capability layer above them.

Does MCP replace function calling?

No. A host commonly uses function calling to let the model select a tool and MCP to reach the server that supplies it.

Is an MCP server an AI agent?

Not automatically. An agent can use a server, and a server can wrap agentic work, but the server role itself does not imply planning or autonomy.

Can MCP work without an LLM?

Yes. A programmatic client can list and invoke capabilities directly.

What are MCP tools?

Tools are discoverable executable operations described by metadata and schemas and invoked through tools/call.

What are MCP resources?

Resources are URI-identified data that clients can list and read. They are separate from tool operations.

What are MCP prompts?

Prompts are server-provided templates or structured messages that a host can present for user invocation.

What is elicitation?

Elicitation is a server request for additional user input mediated by the client and host.

What are MCP Apps?

MCP Apps are an optional extension for interactive HTML interfaces rendered inside supporting hosts through a sandboxed UI model.

What are MCP Tasks?

Tasks are an optional extension for durable asynchronous operations that can be polled, updated, cancelled cooperatively and resumed after disconnection.

Is MCP stateful or stateless?

Current MCP revision 2026-07-28 has a stateless core. Earlier revisions used initialization and protocol sessions. Applications can still maintain explicit state.

Does MCP use HTTP?

Remote MCP commonly uses Streamable HTTP. Local MCP commonly uses stdio. Custom transports are possible.

Does MCP use SSE?

Current Streamable HTTP may return request-scoped SSE streams. The original two-part HTTP+SSE transport is deprecated.

What happened to the MCP handshake?

The initialize/initialized exchange was removed in 2026-07-28. Version and capability metadata now travels with each request.

What happened to Mcp-Session-Id?

Protocol-level sessions and that header were removed in 2026-07-28.

What is server/discover?

It is the current RPC through which a server reports supported protocol versions, identity and capabilities. Servers must implement it, but clients do not have to call it before every other operation.

What is Streamable HTTP?

It is MCP’s remote HTTP transport, introduced in March 2025 and redesigned in July 2026. Current servers expose one POST endpoint and can answer with JSON or a request-scoped SSE stream.

What is a local MCP server?

A local server runs in or near the user’s environment, commonly as a subprocess communicating over stdio.

What is a remote MCP server?

A remote server is network-accessible, usually through Streamable HTTP, and must address identity, authorization, tenancy, deployment and network security.

Does every MCP server use OAuth?

No. The MCP OAuth framework applies to HTTP-based protected deployments. Stdio implementations normally obtain credentials from the environment or other local mechanisms.

Is OAuth authentication?

OAuth is primarily an authorization framework. Deployments may combine it with identity mechanisms such as OpenID Connect, but the terms should not be collapsed.

Are tool annotations security guarantees?

No. They are hints and must be treated as untrusted when the server is untrusted.

Can an MCP server access everything on my computer?

Only what its code and operating-system permissions allow—but those permissions can be broad. A malicious local server is ordinary executable software and is not limited to its advertised tools.

Is the official MCP Registry a security certification?

No. It verifies namespace ownership and hosts metadata, while package and downstream scanners carry much of the code-security burden.

Is MCP open source?

The specification repository, official SDKs and many examples are open source. A proprietary host or remote server can still implement MCP without publishing its code.

Is MCP a formal internet standard?

MCP is an open protocol with public governance and a specification process. It is not an IETF, W3C or ISO standard.

Is MCP controlled only by Anthropic?

MCP originated at Anthropic, which remains influential. The project now has public maintainer governance, a SEP process and an institutional home under the Agentic AI Foundation. Current maintainer membership is attached to individuals rather than formally to their employers. [S069] [S071] [S070]

Can one MCP server work with several AI applications?

Potentially yes, provided the hosts support the same protocol era, transport, authorization method and required capabilities. The user experience may still differ.

What is the latest MCP specification?

As of August 25, 2026, the current official revision is 2026-07-28. This answer requires a live check at publication and every material update. [S054]

Conclusion

MCP’s useful innovation was not inventing actions for models. It was defining a reusable protocol boundary between AI applications and independently implemented capabilities.

An MCP server is best understood as a focused protocol implementation. It can expose tools, resources, prompts and extensions. A host creates clients to reach those servers, decides what the model can see, and mediates permission. The server then calls an underlying API, database, filesystem, service or local program.

That separation creates real reuse, but it does not erase product differences, underlying APIs, security engineering or deployment work. Current MCP is also materially different from launch-era MCP: it is stateless at the protocol core, carries version and capability data per request, uses MRTR for additional input, supports cacheable discovery and routing-friendly HTTP metadata, and treats Apps and Tasks as extensions.

The most accurate summary is therefore neither “USB-C for AI” nor “function calling over HTTP.” MCP is a versioned interoperability protocol whose value comes from separating hosts, clients and servers—and whose safety and usefulness depend on how every layer around that protocol is implemented.

Update log

• August 25, 2026: Initial publication, checked against MCP 2026-07-28; vendor host-support language rechecked against first-party documentation and labeled as documentation review rather than interoperability testing.

Sources and methodology

This article was researched primarily from versioned MCP specifications, changelogs, SEPs, official project documentation, repository history, vendor documentation and original security advisories. Current product, SDK, registry and governance claims were verified on August 25, 2026 and should be checked again before publication or substantive revision.

The accompanying research package contains:

• a 71-source package evidence manifest;
• a machine-readable claim register;
• a full source bibliography;
• a SERP and information-gap analysis;
• visual specifications;
• an SEO and internal-linking package;
• an update policy separating durable history from volatile current state.

No server-count, package-download, GitHub-star or “number of users” statistic is used as proof of adoption. Protocol support is classified by what a product actually implements rather than by the existence of a community wrapper.