The technical term "MCP" (Model Component Provider) is confusing. It's simpler and more accurate to think of them as connectors that give AI tools access to knowledge within your other apps and the ability to perform actions in them.
Related Insights
Agent Skills and the Model Context Protocol (MCP) are complementary, not redundant. Skills package internal, repeatable workflows for 'doing the thing,' while MCP provides the open standard for connecting to external systems like databases and APIs for 'reaching the thing.'
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.
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.
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.
By connecting to services like G Suite, users can query their personal data (e.g., 'summarize my most important emails') directly within the LLM. This transforms the user interaction model from navigating individual apps to conversing with a centralized AI assistant that has access to siloed information.
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.
While tech-savvy users might use tools like Zapier to connect services, the average consumer will not. A key design principle for a mass-market product like Alexa is to handle all the "middleware" complexity of integrations behind the scenes, making it invisible to the user.
