The Future of MCP in 2026

Moderated by Jason Torres, with insights from Angie Jones, Amanda Martin, and Kent C. Dodds

The Modern Computing Protocol, or MCP, is becoming relevant fast. Teams rely on more tools than ever. AI assistants are starting to interact with real systems. Most of those systems still cannot communicate without custom work. Developers keep rebuilding the same integrations. MCP exists to reduce that friction.

At a Torc hosted panel, Jason Torres spoke with Angie from Block, Amanda from Apollo, and Kent C. Dodds, a software engineering educator and builder. Together, they brought perspectives from enterprise engineering, developer tooling, and hands-on education. The discussion focused less on theory and more on what MCP is already solving, where it still falls short, and what needs to change by 2026.

Why MCP exists

The problem MCP addresses is that tools do not communicate well today. Systems grow independently. Integrations are rebuilt repeatedly. Over time, small inconsistencies turn into real maintenance costs.

Kent summed up the current state by saying that the existing model leads to scattered systems that force developers to “go off and do their own thing.” That fragmentation shows up as custom glue code, brittle integrations, and duplicated effort across teams.

At larger companies, this problem compounds. Internal tools are built over many years, often with different assumptions and conventions. Without shared structure, keeping systems connected becomes increasingly difficult. For developers adopting new tools, inconsistent interfaces slow progress or stop integration entirely.

MCP exists to give teams a shared way to connect systems so this pattern does not repeat.

Standardization is the core benefit

Much of the conversation came back to standardization. Without shared patterns, every tool becomes a special case. MCP attempts to change that by offering a consistent way to expose and consume capabilities.

Standardization helps teams because it:

• Reduces custom integration work

• Lowers the learning curve for new tools

• Keeps documentation useful longer

• Makes systems easier to reason about
  
  

At enterprise scale, consistency allows teams to move faster without losing control. For individual developers, shared patterns reduce mental overhead. For communities, they make learning and teaching easier.

The panel also acknowledged that standards must evolve. MCP is still early, and its patterns will change as more teams use it in real environments. Flexibility matters, but shared ground matters more.

Shared capabilities instead of repeated work

Another major theme was shared capabilities. Today, useful features often live inside isolated systems. When another team needs access, they rebuild the same thing instead of reusing it.

MCP offers a way to expose capabilities once and use them across tools.

This enables:

• Less duplicated effort

• Easier extension of existing systems

• Clearer boundaries between tools

• More useful AI-driven workflows
  
  

For large organizations, this means building internal components that can be reused safely. For tooling teams, it means exposing features others can depend on. For developers, it means solving problems without learning the internals of every system.

Long running tasks remain a gap

One area that came up repeatedly was long running tasks. Many real workflows are not instant.

Common examples include:

• Builds and deployments

• Data processing

• Security scans

• Background automation
  
  

Today, teams rely on workarounds like polling, custom queues, or homegrown messaging systems. These approaches work, but they are fragile and inconsistent.

Angie pointed out that long running processes are unavoidable at enterprise scale. MCP needs a clear way to track progress and report status. Without that, teams continue to build around the problem instead of solving it.

This remains one of MCP’s most important areas for growth.

Security and access controls must be explicit

As MCP enables tools and assistants to call real capabilities, security becomes unavoidable. Exposing functionality without clear limits creates risk.

Several requirements came up during the discussion:

• Permissions must be enforced consistently

• Capabilities need defined boundaries

• Authentication patterns must be predictable

• Enterprises need confidence before adoption
  
  

Security is often the deciding factor for whether a protocol is adopted at scale. Clear rules and guardrails are essential.

Better onboarding through consistency

A side effect of shared patterns is better onboarding. When tools behave consistently, new developers spend less time learning quirks and more time building features.

Shared structure leads to:

• Faster ramp-up for new hires

• Less time learning glue code

• Documentation that stays relevant

• Easier movement between teams
  
  

This benefit matters most in environments with many internal tools, but it applies across teams of all sizes.

Where MCP is showing up now

Adoption is still early, but it is happening in a few clear places:

• Enterprise teams testing MCP inside internal systems

• Tooling teams exposing capabilities through shared patterns

• Educators and independent developers experimenting and teaching
  
  

Most current use cases are exploratory. Teams are testing what works and identifying where MCP needs to improve, especially around long running tasks and security.

Looking toward 2026

The discussion closed with a look ahead. Over the next two years, MCP’s future depends on whether it can mature in the areas that matter most.

If standards stabilize, enterprise adoption is likely to grow. If tooling improves, shared workflows become easier. If education continues, pressure to adopt MCP will increase inside organizations.

MCP reflects a broader shift toward more open and consistent systems. The industry is already moving in that direction.

Why this matters

MCP is not finished, but it addresses real problems. Tool fragmentation. Repeated work. Fragile integrations.

If it develops well, it can offer:

• Shared ground for developers

• Lower integration effort

• Stronger support for AI-driven workflows

• Clearer patterns for large systems
  
  

The next two years will determine how far it goes. Based on this panel, the interest is real and the problems are clearly defined.

About the speakers

• Angie Jones, Vice President of Engineering, AI Tools and Enablement at Block

• Amanda Martin, Developer Advocate at Apollo

• Kent C. Dodds, software engineering educator and creator of EpicWeb.dev and EpicAI.pro

• Moderator: Jason Torres, Community Manager at Torc