A16z: Deep understanding of the future of MCP and AI tool ecosystem

Since OpenAI released the function calling feature in 2023, I have been thinking about how to truly unlock an agent- and tool-centric ecosystem. As the underlying models become increasingly intelligent, AI agents' ability to interact with external tools, data, and APIs becomes increasingly decentralized: developers have to customize specific business logic for each system in order for agents to complete operations and integration between different systems.

It is obvious that we need a standardized interface for executing instructions, obtaining data, and calling tools. In the early days of the Internet, API was the unified language for communication between software; but in the field of AI, we still lack a corresponding standard.

Since its release in November 2024, the Model Context Protocol (MCP) has quickly gained widespread attention among developers and the AI ​​community as a potential solution to the above problems. This article will explore what MCP is, why it will change the way AI interacts with tools, how developers use it today, and the challenges that still need to be addressed.

Let’s get started.

MCP is an open protocol that allows various systems to provide context to AI models in a generalizable way. It defines how AI models call external tools, obtain data, and interact with services. For example, the following shows how the Resend MCP server works with multiple MCP clients:

This idea is not new; MCP is inspired by LSP (Language Server Protocol). In LSP, when the user types in the editor, the client requests auto-completion or diagnostic information from the language server.

MCP extends beyond LSP in that it adopts an "agent-centric" execution model. While LSP is primarily passive (responding to user input and IDE requests), MCP supports autonomous AI workflows. Based on a given context, AI agents are free to decide which tools to use, in what order to call them, and how to string these calls together to complete a task. MCP also introduces a "human intervention" link, allowing people to provide additional data and approve the execution process when necessary.

1. Workflow for developers

An example of how the Cursor proxy can use Browsertools to access console logs and other real-time data and debug more efficiently.

2. New application experience

An example of a Notion MCP (plugin) implementation by Highlight.

Example of using Claude Desktop with  Blender MCP Server .

Market map

1. Hosting and multi-tenancy

MCP supports the scenario of "one AI agent for multiple tools", but multi-tenant architecture (such as SaaS products) requires high concurrency support of "multiple users for the same MCP server". Using remote servers by default may be a way to make MCP servers reach a wider range of users in the short term, but many companies still want to deploy MCP servers in their own environments and separate the data plane and control plane.

To deploy and maintain MCP servers at scale, a mature tool chain is needed, which is the next key link to widespread adoption.

2. Authentication

MCP currently does not define a standard authentication mechanism , nor does it specify how to securely manage and delegate authorization when interacting with third-party APIs. At this stage, authentication is usually solved by each implementation and deployment scenario. In fact, MCP is currently used more in local integration scenarios - and such scenarios often do not have a strong demand for authentication.

If remote MCP is to be truly popularized, a more complete authentication paradigm is needed. For developers, a unified authentication method should include:

• Client authentication: Use standard methods such as OAuth or API Token for client-server interaction

• Tool authentication: Provides auxiliary functions or wrappers for third-party API authentication

• Multi-user authentication: tenant-level authentication for enterprise deployments

3. Authorization

Even if the tool is authenticated, who has the right to use it? How fine-grained is the permission? MCP does not yet have a built-in permission model, and current access control is almost entirely at the session level—a tool is either accessible or completely prohibited. Although there may be more fine-grained permission control mechanisms in the future, the current common practice is to use an authorization process based on OAuth 2.1. Once authenticated, the entire session has access to the tool.

As the number of agents and tools continues to grow, this session-level access management becomes increasingly complex. Currently, each agent typically requires a separate session and authorization credentials, forming an ever-expanding web of access management.

4. Gateway

As your MCP application scales, you may need a gateway layer to centrally handle authentication, authorization, traffic management, and tool selection. Similar to a traditional API gateway, this gateway can perform access control, route requests to the correct MCP server, and perform load balancing and caching. This is especially important for multi-tenant environments, where different users and agents often require different permissions. A standardized gateway can simplify client-server interactions, enhance security, and provide better observability, making MCP deployments easier to scale and manage.

5. Discoverability and availability of MCP servers

Currently, it is still cumbersome to find and set up an MCP server: developers need to locate the relevant endpoints or scripts, configure authentication, and ensure that the server is compatible with the client. Integrating new servers is time-consuming and laborious, and AI agents cannot dynamically discover or adapt to available servers.

But from Anthropic's speech at the AI ​​Engineer Conference last month, they are preparing the MCP server registry and discovery protocol. If it can be successfully launched, this is likely to become the next key node for the large-scale popularization of MCP.

6. Execution Environment

Most AI workflows require calling multiple tools in sequence, but MCP does not have a built-in "workflow" concept to manage these calling steps. If each client is required to implement its own resumability and retryability mechanisms, it will inevitably increase complexity. Although some developers are currently trying to use third-party solutions such as Inngest, if stateful execution can be upgraded to the core concept of the MCP protocol, it will greatly simplify the execution model of most developers.

7. Standardized client experience

A common question from the developer community is: How do we think about "tool selection" when building an MCP client? Does everyone need to implement their own tool selection logic based on search enhancement generation (RAG)? Or is there a chance that this logic can be standardized?

Not only that, the industry also lacks a unified UI/UX model to call tools (some are slash commands, some are purely natural language triggers). If unified tool discovery, sorting, and execution capabilities can be achieved at the client level, developers and users can get a more consistent experience.

8. Debugging

Many MCP server developers have found that it is not easy to make the same MCP server work properly on different clients. Most MCP clients have their own implementation details, and client-side debugging information is often missing or difficult to obtain, making the debugging process extremely difficult. As more MCP servers begin to "remote", we need a whole set of new tools to simplify the development experience in local and remote environments.

1. The competitive advantage of developer-oriented companies will evolve from "best API design" to "best tool set" . If MCP allows agents to automatically discover tools, then API or SDK providers need to ensure that their tools can be easily retrieved and perform well in similar tasks, enough for agents to choose. And this will be more sophisticated and immediate than human developers.
2. If every application becomes an MCP client and every API becomes an MCP server, we may see entirely new pricing models where agencies dynamically select tools based on speed, cost, and relevance. This more market-based adoption approach will allow the most “useful” tools to quickly stand out, breaking the dominance of tools based on user base or historical inertia.
3. Documentation will become a critical component of the MCP infrastructure . Companies need to provide machine-readable (e.g., llms.txt) tool and API specifications and default MCP server outputs based on existing documentation so that AI can quickly understand and use these features.
4. API is no longer the end point, but just the starting point . Developers will gradually realize that the mapping between API and tools is not one-to-one. Tools are a higher-level abstraction that makes the best call combination based on the task scenario - for example, proxy callsdraft_email_and_send()It may involve multiple underlying API calls, but it can significantly reduce latency. The design of the MCP server will focus more on specific scenarios and use cases rather than simple API encapsulation.
5. If every software is an MCP client by default, then hosting will also evolve . The characteristics of the workload are very different from traditional websites. Each client may require multi-step execution and support for recoverable, retryable, and long-duration task management. Hosts will also need to perform real-time load balancing across different MCP servers to balance cost, latency, and performance, so that AI agents can dynamically select the best tool.