MCP shouldn't be thought of as just another developer API like REST. Its true purpose is to enable seamless, consumer-focused pluggability. In a successful future, a user's mom wouldn't know what MCP is; her AI application would just connect to the right services automatically to get tasks done.
Don't view AI as just a feature set. Instead, treat "intelligence" as a fundamental new building block for software, on par with established primitives like databases or APIs. When conceptualizing any new product, assume this intelligence layer is a non-negotiable part of the technology stack to solve user problems effectively.
To avoid overwhelming an LLM's context with hundreds of tools, a dynamic MCP approach offers just three: one to list available API endpoints, one to get details on a specific endpoint, and one to execute it. This scales well but increases latency and complexity due to the multiple turns required for a single action.
The MCP protocol's primitives are not directly influenced by current model limitations. Instead, it was designed with the expectation that models would improve exponentially. For example, "progressive discovery" was built-in, anticipating that models could be trained to fetch context on-demand, solving future context bloat problems.
MCP was born from the need for a central dev team to scale its impact. By creating a protocol, they empowered individual teams at Anthropic to build and deploy their own MCP servers without being a bottleneck. This decentralized model is so successful the core team doesn't know about 90% of internal servers.
MCP acts as a universal translator, allowing different AI models and platforms to share context and data. This prevents "AI amnesia" where customer interactions start from scratch, creating a continuous, intelligent experience by giving AI a persistent, shared memory.
Skills and MCP are not competitors but complementary layers in an agent's architecture. Skills provide vertical, domain-specific knowledge (e.g., how to behave as an accountant), while MCP provides the horizontal communication layer to connect the agent to external tools and data sources.
Exposing your platform via a Model Consumable Platform (MCP) does more than enable integrations. It acts as a research tool. By observing where developers and LLMs succeed or fail when calling your API, you can discover emergent use cases and find inspiration for new, polished AI-native product features.
The most effective application of AI isn't a visible chatbot feature. It's an invisible layer that intelligently removes friction from existing user workflows. Instead of creating new work for users (like prompt engineering), AI should simplify experiences, like automatically surfacing a 'pay bill' link without the user ever consciously 'using AI.'
OpenAI uses two connector types. First-party (1P) "sync connectors" store data to enable higher-quality, optimized experiences (e.g., re-ranking). Third-party (3P) MCP connectors provide broad, long-tail coverage but offer less control. This dual approach strategically trades off deep integration quality against ecosystem scale.
Exposing a full API via the Model Context Protocol (MCP) overwhelms an LLM's context window and reasoning. This forces developers to abandon exposing their entire service and instead manually craft a few highly specific tools, limiting the AI's capabilities and defeating the "do anything" vision of agents.