When the Chat Becomes the Application

The Model Context Protocol has become one of the defining developments in applied AI. Officially, MCP is not new. Anthropic introduced it on 25 November 2024 as an open standard for connecting AI assistants to external tools and data. OpenAI announced support during 2025, subsequently added remote MCP servers to its Responses API, and joined the protocol's steering committee.

That is the documented chronology. It is not quite the chronology experienced by users.

Announcing support for a protocol is different from making it broadly usable. Support can arrive in a developer SDK before appearing in a consumer product. It may initially cover retrieval but not actions, remote servers but not local ones, or approved connectors but not arbitrary integrations. Authentication, administration, permissions, and interface support may follow on separate schedules.

From the operator's seat, MCP's convergence has therefore felt much more recent than its publication dates suggest. In that practical sense, 2026 has been the year of MCP.

From an Anthropic initiative to shared infrastructure

MCP began at Anthropic to address a straightforward problem: every AI product needed its own custom way to connect models with external systems.

Without a common interface, connecting an assistant to a document repository, business application, development environment, or internal database required a separate integration. MCP proposed a reusable protocol through which an AI host could discover available capabilities, retrieve resources, and call tools.

OpenAI's documented adoption began in 2025. In May, OpenAI added remote MCP support to the Responses API, building on earlier support in its Agents SDK, and joined the MCP steering committee. Other products and infrastructure providers adopted the protocol at different speeds and with different limitations.

The decisive development was not any single product announcement. It was the emergence of multi-vendor stewardship and infrastructure. In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation, co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, Amazon Web Services, Cloudflare, and others.

MCP may have originated with Anthropic, but it can no longer be understood solely as an Anthropic feature.

Connectivity becomes an application layer

The first phase of MCP was principally about connection. An AI system could retrieve information from an external source or call a tool without requiring a bespoke integration for every model and client.

The next phase is more consequential.

MCP Apps allow tools to return interactive interfaces that render within a conversation. Instead of receiving only text or structured data, a user can work with a form, dashboard, visualization, document viewer, or multi-step workflow without leaving the AI environment.

The interface and the conversation remain connected. A person can manipulate the interface directly while the model retains the surrounding context and responds to the person's choices.

MCP Apps was proposed in November 2025 and became an official extension in January 2026. The major MCP specification released on 28 July 2026 formalized an extensions framework around capabilities including MCP Apps and long-running Tasks. That release also redesigned the core protocol to be stateless, cacheable, and easier to operate across conventional web infrastructure.

Client support remains uneven. Anthropic has made standardized MCP Apps visible across Claude experiences. OpenAI helped shape the extension and offers an Apps SDK for interactive, MCP-backed experiences, but individual products do not necessarily implement every MCP extension at the same time or in the same form.

This looks less like a decisive protocol war than a period of converging experimentation.

Plugins are not an alternative to MCP

The emerging Agent Plugins specification can initially appear to be a competing direction. It is better understood as another layer of the same architecture.

MCP defines how an AI host connects to tools and resources. Agent Skills package instructions, scripts, and references that teach an agent how to perform a recurring kind of work. Agent Plugins place those components into a portable, installable package.

A plugin can contain:

• reusable Skills
• one or more MCP server configurations
• identifying and version information
• extensions for particular AI clients

MCP provides connectivity. Skills provide procedure. Plugins provide packaging and distribution.

That combination matters because useful agent systems need more than access. Giving an agent a tool does not teach it when the tool should be used, what evidence should be retained, when human approval is necessary, or how exceptions should be handled.

Agent Plugins could make both the capability and its operating method portable across compatible clients. The current client list includes VS Code, Cursor, GitHub Copilot, ChatGPT and Codex, and Kiro, although each client can support a different subset of components.

The version 1.0 specification remains a working draft. It deliberately leaves installation, permissions, sandboxing, authentication, provenance, and enterprise policy to individual clients. Agent Plugins should be treated as promising interoperability infrastructure, not a guarantee of safety.

When the application stops being the destination

Conventional software combines many layers:

• business logic
• data and records
• authentication and permissions
• workflows
• navigation
• presentation
• a graphical interface

MCP, plugins, and conversational interfaces begin to pull these layers apart.

The underlying application may continue to hold the authoritative data and enforce business rules. But the person may no longer need to navigate to that application, learn its information architecture, and operate every step manually.

Instead, the person describes an intended outcome. The AI environment identifies relevant capabilities, retrieves information from several systems, performs permitted actions, and presents an interface where direct manipulation or judgment is useful.

The chat becomes an orchestration surface.

This does not mean that applications disappear. Their role changes. Many become services and systems of record behind a conversational layer rather than destinations users must visit for every task.

Commerce may be an early test

E-commerce illustrates the possible shift.

A conventional purchase requires a person to search, open several pages, interpret product categories, compare specifications, configure an item, enter information, and complete checkout.

A connected AI system could perform much of that work conversationally:

1. understand the intended outcome and constraints
2. search several product sources
3. compare relevant attributes
4. explain material trade-offs
5. present a configuration or approval interface
6. call an authorized checkout tool
7. retain confirmation and delivery information in context

The merchant still requires product, inventory, payment, fulfilment, return, identity, and customer-service systems. What may decline is the requirement that the customer personally navigate the merchant's complete graphical interface.

Websites will remain important for public discovery, trust, brand, legal disclosure, unauthenticated access, and experiences that benefit from sustained visual exploration. But they may no longer be the default entry point for every transaction.

A higher security floor, not a guarantee

Greater connectivity normally produces greater exposure.

An AI system connected to business applications may retrieve sensitive information, alter records, communicate externally, initiate purchases, or trigger downstream workflows. Adding more connections increases both capability and the number of paths through which mistakes, compromised credentials, malicious instructions, or excessive permissions can cause harm.

MCP does not eliminate that risk. It does, however, offer a potentially important improvement over the fragmented integrations it replaces.

Protected remote MCP servers use a standardized authorization model based on established OAuth conventions. Clients can discover authorization requirements, direct users through an authorization flow, request access for a defined resource, and present tokens intended specifically for that MCP server.

The MCP authorization specification includes requirements covering OAuth 2.1 security practices, PKCE protection, HTTPS authorization endpoints, exact redirect validation, and access tokens bound to their intended resource. The July 2026 release added issuer validation and issuer-bound credentials while moving client identification toward metadata documents.

These controls are not novel inventions. Their value is that MCP makes established security practices part of a common integration model rather than leaving every AI connector to design authentication from the beginning.

That can raise the security floor.

A conventional application integration may depend on a permanently copied API key, an overprivileged service account, or custom authentication code that receives limited review. An MCP client and server built against a common specification can reuse tested SDKs, standard discovery mechanisms, centralized consent interfaces, and familiar enterprise identity infrastructure.

AI coding models may reinforce this advantage. When a standard is machine-readable, widely documented, and supported by maintained SDKs, coding agents can generate integrations around recognizable patterns instead of improvising proprietary authentication and message handling for every service. Automated analysis, conformance testing, and security tooling can also target a common protocol.

That does not make AI-generated integrations automatically secure. Generated code can misconfigure scopes, mishandle tokens, expose sensitive tool descriptions, or implement the surrounding business logic incorrectly. Standardization makes secure implementation easier to express, inspect, test, and improve; it does not remove the need for review.

MCP Apps add another useful boundary. Their interfaces run in host-controlled, sandboxed frames. Communication with the host travels through inspectable messages, while the host controls capabilities and can require consent before an interface initiates a tool call. This can be safer than allowing every third-party integration unrestricted access to the surrounding application.

Important exceptions remain. Authorization is optional for MCP servers that expose no protected resources. Local MCP servers using stdio may receive credentials through their environment or their own libraries rather than OAuth. A properly authenticated user can still receive excessive authority, and a correctly authorized tool can still be invoked for the wrong reason.

MCP therefore separates several questions that are too often collapsed:

• Authentication: Who is connecting?
• Authorization: What may that identity access?
• Consent: Does the person approve this particular action?
• Intent: Is the action actually what the person meant?
• Governance: Is the action appropriate, observable, reversible, and accountable?

MCP materially improves the architecture available for the first two when its authorization model is implemented correctly. Clients and organizations remain responsible for the others.

The result is best understood as a net improvement, not a safety guarantee. MCP increases connectivity and therefore potential exposure. At the same time, it replaces many bespoke integrations with a common, OAuth-aligned, inspectable security model.

The AIAC position

MCP is emerging as a foundational interoperability layer for AI-enabled work. MCP Apps and Agent Plugins extend that direction from connectivity toward portable workflows and applications operating inside conversational environments.

This may shift software from destinations people navigate to capabilities AI systems assemble. It will not eliminate the systems behind those applications, nor will interoperability make them trustworthy by default.

Organizations should welcome portability while retaining control over permissions, provenance, consequential actions, monitoring, intervention, and accountability.

For SMEs, this is the practical dividing line. Interoperability can reduce integration cost and vendor dependence, but it can also make uncontrolled capability easier to install. Adoption should advance through bounded experiments, narrow permissions, visible consequential actions, observable evidence, effective intervention, and named ownership.

The most important change may not be that AI can use more tools. It may be that applications, information, interfaces, and workflows are moving into one continuous conversational context.

The chat is no longer just where the user asks a question.

It is becoming where the work happens.