Introduction: AI with no hands
You ask an AI assistant to check your open GitHub pull requests, summarise what needs reviewing, update your Notion project tracker, and send a quick Slack message to your team. The AI responds with something fluent and impressive, a well-worded description of what it would do if it could. But it can’t. So it tells you about the task instead of completing it.
That’s not an intelligence problem. The model is smart enough. The problem is structural: the AI has no hands.
It lives inside a conversation window. Everything it knows comes from what you paste in front of it or what it learned during training. It cannot reach into your GitHub account, read your Notion database, or send anything to Slack on its own. It is brilliant, isolated, and ultimately limited to the boundaries of a text box.
That’s the problem the Model Context Protocol (MCP) was built to solve. And in the 18 months since Anthropic released it as an open standard, it has gone from a quiet developer release to the backbone of how every major AI platform connects to the outside world.
This article explains what MCP actually is, how it works at the level that matters for builders, what it makes possible that wasn’t possible before, and because this is ediccrew, what it means specifically for African developers and founders who want to build on the right infrastructure from the start.
If you’ve been confused about the difference between AI agents and the chatbots you’re used to, the AI Agents vs Chatbots breakdown on ediccrew is the right place to build that foundation first. This article picks up where that one leaves off. The Artificial Intelligence section is where you’ll find the related deep dives as we publish them.
Phase 1: the problem MCP exists to solve
Why connecting AI to tools was a nightmare before MCP.
Before MCP existed, every time a developer wanted to connect an AI model to an external tool, a database, a file system, a payment API, or a project management platform, they had to build a custom connector. A bespoke integration written specifically for that combination of AI model and external service.
On paper, that sounds manageable. In practice, it became a combinatorial disaster.
Say you were building AI-powered features for a product that used three different language models and needed to connect to ten external tools. That’s 30 custom integrations to write, test, document, and maintain. Now update one of the AI models to a newer version. Half your connectors break. Now one of the tools changes its API. More breaks.
Anthropic called this the N×M problem. N models times M tools equals N×M bespoke integrations, a number that grows fast and breaks often. Every integration was tightly coupled to both the specific model’s API format and the specific tool’s interface. Neither side could change without breaking the bridge between them.
Before MCP, every device manufacturer shipped proprietary chargers. Users accumulated drawers full of cables that only worked with one device. It was the same chaos in a different domain. USB-C replaced that tangle with a single universal standard. MCP does the same thing for AI-to-tool connectivity.
The official MCP documentation at modelcontextprotocol.io describes it plainly: one standard connection layer that replaces hundreds of point-to-point integrations. The original Anthropic announcement frames it as addressing what they called “context starvation”, the reality that even the most capable models are constrained by their isolation from real-world systems and current data.
What MCP actually is, the definition, is earned.
Now that you’ve felt the problem, here is the solution in plain terms.
MCP (Model Context Protocol) is an open standard that gives AI models a single, universal way to connect to any external tool or data source. Write one MCP server for your tool, say, a server that wraps your PostgreSQL database and every MCP-compatible AI host can use it. Claude, ChatGPT, Gemini, Cursor, Windsurf: all of them, without any additional integration work.
It was created at Anthropic by engineers David Soria Parra and Justin Spahr-Summers, and released as an open-source protocol in November 2024. The Wikipedia entry on Model Context Protocol covers the full history for those who want the timeline in detail.
The governance point matters more than most guides acknowledge. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The AAIF was co-founded by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, and Cloudflare. MCP now sits alongside Kubernetes and PyTorch in the Linux Foundation’s portfolio of open infrastructure.
This is not Anthropic’s proprietary standard. It belongs to the open-source community. That distinction matters enormously for builders deciding whether to invest time and resources into learning and building on it. The infrastructure you’re betting on should not be owned by a single vendor.
For context on what context-handling looks like at the application layer, the problem MCP addresses at the infrastructure level, the AI prompting guide on ediccrew explains why the quality of what an AI can see determines the quality of what it can do.
Phase 2: How MCP works
The three-role architecture and why most people confuse two of them
MCP has three distinct entities in every interaction. Getting these right matters because the most common mistake in MCP documentation is conflating two of them, which leads to security misconfigurations and broken implementations.
The three roles are: Host, Client, and Server.
The Host is the AI-facing application the user interacts with. Claude Desktop is a host. Cursor is a host. A custom-built AI application you’ve written is a host. The host is responsible for managing connections, enforcing permissions and security policies, and coordinating everything. Think of it as the CEO of the operation: it sets the rules, decides which tools the AI can access, and makes sure nothing happens without authorisation.
The Client is what the host spawns to manage a specific server connection. One client per server connection, each maintaining its own stateful session. The client is the department head: it manages one supplier relationship on behalf of the CEO. The host can spin up many clients simultaneously, one for GitHub, one for your database, one for Slack, each isolated from the others.
The Server is the lightweight process that wraps a specific tool or data source and speaks the MCP protocol. A GitHub MCP server accepts requests from a client, translates them into GitHub API calls, and returns the results. A Postgres MCP server accepts queries, translates them into SQL, and returns rows. Critically, the server never communicates directly with the AI model. All interaction is mediated by the client. The server is the external supplier; it provides a specific capability through a well-defined interface, with no direct line to the decision-maker.
For a deep technical breakdown of the client-server architecture and the JSON-RPC 2.0 wire protocol underneath, Codilime’s technical MCP explainer and the Sitepoint MCP guide both go into the implementation details.
The five primitives: what an MCP server can actually expose
Every MCP server exposes capabilities through up to five building blocks called primitives. Most production servers implement two or three. Understanding which primitive does what is the difference between a well-architected integration and a security liability.
Tools are executable operations that produce side effects. When an AI model calls a tool, something happens in the real world: a database row is inserted, an email is sent, a GitHub issue is created, a file is written to disk. Tools are model-controlled; the AI model decides when and how to call them based on the user’s request and the tool’s description. Tools are the most powerful primitive and the most security-sensitive. They are where prompt injection attacks and over-permissioning create real risk.
Resources are read-only data that the model can access. File contents, database records, API responses, and configuration data are exposed as addressable resources that the model can request on demand. Resources are application-controlled, meaning the host or user determines when to include them in context. If Tools are the AI’s hands, Resources are its eyes.
Prompts are reusable prompt templates exposed by the server. A server might expose a structured multi-step workflow for code review, or a templated query pattern for a specific database. Prompts are user-controlled, surfaced as options the user can select, not triggered automatically by the model.
Elicitation allows the server to request structured input from the user mid-workflow. Rather than the AI guessing at ambiguous parameters, a server can pause and ask the human for the specific information it needs. This keeps agentic workflows grounded and reduces hallucinated inputs to tool calls.
Sampling is the most unusual primitive and the one that surprises most developers. The server can ask the client to run an LLM completion on its behalf. This allows agentic servers to reason without bundling their own LLM API key; the computation happens at the host, with explicit user consent, and the result is returned to the server. No silent completions.
The AI Turn Point MCP guide covers the security implications of each primitive in depth, particularly the distinction between model-controlled primitives (which can be exploited via prompt injection) and user-controlled ones.
How MCP went from Anthropic project to open infrastructure in 18 months
The adoption velocity of MCP is one of the more remarkable stories in recent developer tooling history. The arc matters because it tells you whether this is a standard worth building on.
Anthropic released MCP in November 2024 alongside reference servers for GitHub, Slack, Google Drive, Postgres, and Puppeteer. Monthly SDK downloads at launch: approximately 2 million. OpenAI adopted MCP in April 2025, integrating it across their Agents SDK, and the ChatGPT desktop application downloads climbed to 22 million monthly. Microsoft integrated MCP into Copilot Studio in July 2025, pushing the number to 45 million. AWS added support in November 2025 at 68 million monthly downloads.
By March 2026: all major AI providers on board, 97 million monthly SDK downloads across Python and TypeScript SDKs, over 20,000 active public MCP servers. Google Trends for “model context protocol” peaked at 100/100 during the first week of March 2026. As the Truto SaaS PM guide to MCP documents, Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, and those agents need MCP to interact with the SaaS tools their organisations already pay for.
The Linux Foundation governance transfer in December 2025 was the signal that cemented long-term viability. A protocol co-governed by Anthropic, OpenAI, Google, Microsoft, AWS, Block, Bloomberg, and Cloudflare does not disappear quietly. It becomes infrastructure.
For the African builder dimension of this shift, TechCabal’s AI infrastructure analysis documents a London-based Nigerian founder who has already built MCPLambda, a managed deployment platform for MCP servers that takes a Git repository to a production-grade endpoint in minutes. The infrastructure layer opportunity is live, and in the African context, largely unclaimed.
MCP vs plain APIs: what’s actually different
Every developer who encounters MCP eventually asks the same question: if we already have REST APIs and function calling, why does this exist?
The distinction is not about capability. It’s about who is doing the calling and how.
Traditional APIs are designed for deterministic, hardcoded workflows. A developer writes code that says: fetch this endpoint, map this field to that field, POST to this URL. The code knows exactly what to call and when. This works perfectly for human-written software because humans write the calling logic in advance.
AI agents are non-deterministic. They cannot be hardcoded with a fixed sequence of API calls because they don’t know in advance which tools they’ll need or in what order. They need to explore an API surface, read descriptions of what tools do, and construct calls dynamically from natural language instructions. Traditional APIs have no mechanism for this kind of runtime discovery.
MCP’s self-describing tool interface, where every tool exposes a name, a description, and a structured input schema, is built specifically for this paradigm. The model reads tool descriptions and figures out what to call and how to call it, on the fly, from natural language context.
Critically: MCP does not replace REST APIs. The Google Cloud MCP explainer makes this clear. Your existing APIs continue to serve human clients and traditional software exactly as they do today. MCP wraps those APIs to make them accessible to AI models. One layer sits on top of the other.
Phase 3: What MCP means in practice
What AI can actually do with MCP: five real examples
None of this is theoretical in 2026. MCP is running in production. Here is what it looks like.
A coding agent opens a GitHub repository, identifies a failing test from the CI logs, writes a fix in the relevant file, and opens a pull request with a summary of the change without the developer copying and pasting anything into a chat window. The GitHub MCP server handles the repository access; the filesystem MCP server handles the file edits; the model orchestrates the workflow from a single natural language instruction.
An enterprise support chatbot receives a query about a delayed order. It queries a PostgreSQL database via MCP to retrieve that customer’s order history, checks the logistics API for current shipment status, and answers the query in plain language without a human agent involved, and without the model having been trained on that customer’s data.
A developer describes a UI component in natural language. Claude Code reads the Figma design file through a Figma MCP server, generates the React implementation, and sends the code back to the Figma canvas for review, design and implementation, staying in sync without leaving either tool.
A founder asks an AI scheduling assistant to find time for a team meeting next week. The assistant reads Google Calendar for availability across three time zones, checks Notion for project milestone deadlines, drafts a meeting agenda based on outstanding tasks, and sends the invite via Gmail. One natural language prompt. Four tool calls. Zero manual steps.
A Lagos-based developer builds a single MCP server that connects their Paystack webhook data to Claude. They can now ask “which of my customers downgraded their subscription last month?” or “what was my revenue on the fifteenth of last month?” in plain English, and get an accurate answer pulled from their live payment data. No SQL. No dashboard. Just a question and an answer.
That fifth example is not hypothetical. It requires perhaps a day of work using the Paystack API documentation and the official Python MCP SDK. The ediccrew SaaS MVP playbook covers the full product stack that an MCP-powered product sits inside the database, auth layer, hosting, and payment integration that makes a product of this kind real.
The security reality every MCP builder needs to understand
MCP’s power comes with real risks that deserve honest treatment, not as a disclaimer at the bottom of a guide, but as something a senior developer would tell a junior one before they went into production.
Three risks to understand clearly.
The first is prompt injection. A malicious MCP server can embed instructions in its tool descriptions that redirect the AI model’s behaviour. Because the model reads tool descriptions as part of its context, a bad actor who controls a server can use those descriptions to manipulate what the model does. The mitigation: only connect to the MCP servers you trust and have reviewed. Never install community MCP servers into production workflows without reading their source code.
The second is over-permissioned tools. MCP servers that expose write access where read-only access would suffice create an unnecessary attack surface. A tool that can delete database rows when the workflow only needs to read them is a risk with no upside. Apply the principle of least privilege: expose only what the AI genuinely needs for the tasks it’s authorised to perform.
The third is supply chain exposure. MCP integrations can be built and published by anyone. The community registry has grown rapidly, and not all servers in it have been reviewed for security. Organisations that let AI agents connect to arbitrary community servers are expanding their attack surface beyond what their security teams have approved.
The CIO analysis of MCP on enterprise security agendas covers the governance dimension in depth. For the Nigerian business context, the ediccrew AI security guide maps the threat landscape that matters for local operators.
The practical checklist before deploying any MCP integration in production: explicit user consent before tool invocations that cause side effects, read-only resources where write tools aren’t necessary, source code review for any third-party server, and audit logging for all tool calls.
The Africa opportunity: infrastructure, not just a tool
Here is the angle no global MCP explainer covers because no global explainer has the ediccrew vantage point.
The same pattern that produced African fintech innovation is now available at the protocol layer. Nigerian fintech builders didn’t wait for Stripe to serve them. They built Paystack and Flutterwave. They didn’t wait for the banking system to reach rural areas. They built agent banking networks that turned neighbourhood shops into financial access points. African solutions to African constraints — and those solutions became the templates the rest of the world studied.
MCP creates the same opening.
A developer who builds an MCP server that wraps the Paystack API, exposing payment history, subscription events, and customer churn data as MCP-accessible resources builds something the entire global MCP ecosystem needs and cannot replicate from the outside. The same logic applies to Flutterwave data integrations, USSD banking bridges for low-connectivity environments, and logistics API wrappers for African delivery networks whose address systems work differently from the global standard.
The infrastructure layer for AI-to-African-systems connectivity is currently largely unbuilt. The developers who build it are not just solving their own problems; they are creating tools that millions of AI applications worldwide will eventually need when they expand into African markets.
The Nigeria Fintech Tech Stack article on ediccrew documents the payment and infrastructure layer that MCP servers could wrap. The TechCabal AI infrastructure analysis makes the broader opportunity case with data. The gap is real. The tools to fill it exist today.
Phase 4: run your first MCP server today
How to get started: three paths depending on your level
The barrier to using MCP is genuinely low. Here are three entry points, matched to where you are right now.
If you’re non-technical: Connect an existing MCP server to Claude Desktop using a JSON configuration file. Anthropic ships reference servers for GitHub, Slack, Google Drive, Postgres, and Puppeteer. Installing the GitHub MCP server requires adding a JSON block to Claude Desktop’s configuration file, roughly eight lines specifying the server command and your GitHub personal access token. After a restart, Claude Desktop can read your repositories, pull request lists, and file contents directly. No code required. The official MCP documentation walks through the exact configuration syntax.
If you’re a junior developer: Build a minimal MCP server from scratch using the official Python SDK. The scaffold for a server that exposes one tool, a function that queries a weather API, for example, is approximately 15 lines of Python. You define the server, declare the tool with a name and input schema, write the handler that makes the API call and returns a result, and run the server. Any MCP-compatible client can now use that tool. The Python path is recommended over Node.js for readers on Nigerian internet connections, where npm install overhead adds up on metered data. The ediccrew Tools section covers the broader ecosystem of tools worth knowing alongside the SDK.
If you’re an experienced developer: Use the MCP Inspector (npx @modelcontextprotocol/inspector) to debug server implementations and inspect JSON-RPC traffic between client and server in real time without involving an LLM. This is the fastest way to verify that your server is exposing the right capabilities, handling errors correctly, and responding within acceptable latency bounds.
Five questions you’ll have after finishing this article
Is MCP only for Claude?
No. OpenAI added native MCP support in early 2026 across its Agents SDK and ChatGPT desktop application. Google integrated MCP into the Gemini ecosystem. Microsoft shipped MCP support in Copilot Studio and broader developer tooling. Open-source models via Ollama and LM Studio also support the protocol. MCP is model-agnostic by design; any MCP-compatible host can connect to any MCP server.
Will MCP replace REST APIs?
No. MCP is a protocol for AI tool access, not a general-purpose API standard. Your existing REST and GraphQL APIs continue to serve human clients and traditional software exactly as they do today. MCP wraps those APIs to make them accessible to AI models. One sits on top of the other; neither replaces the other.
What’s the difference between MCP and A2A (Agent-to-Agent protocol)?
MCP connects AI agents to tools and data sources. A2A (Google’s Agent-to-Agent protocol) connects AI agents to other AI agents. They are complementary: MCP gives an agent its hands access to external tools and data. A2A lets agents collaborate in teams, delegating tasks between specialised agents. The two protocols are increasingly used together in complex agentic workflows.
Can I build an MCP server without JavaScript or Python?
Yes. Official SDKs exist for TypeScript, Python, C#, Java, and Swift. The community has published implementations in Rust and Go. The 2026 MCP roadmap from the official blog covers where official SDK support is expanding throughout the year.
Is MCP safe to use in production?
Yes, with proper practices in place: explicit user consent before tool invocations that cause side effects, the principle of least privilege when designing what your server exposes, source code review for any third-party server before connecting it, and audit logging for all tool calls. Security maturity across the ecosystem is still developing; treat MCP servers the way you’d treat any third-party code running with access to your systems.
For the workflows and mental models that make AI tools genuinely useful at the application layer, the AI-First Workflows article on ediccrew builds the right foundation for applying these capabilities in practice.
Now build the thing
Pick one thing your AI tool cannot currently do because it lacks access. A spreadsheet. A database. A Paystack webhook. Your own product’s backend. A local government API.
That is your first MCP server. One tool, one data source, one weekend.
The standard is open. The SDKs are free. The ecosystem is alive. And the window for building infrastructure that matters, especially African infrastructure that the global AI ecosystem will eventually need, is open right now.
The natural next read from here is the ediccrew SaaS MVP playbook, which covers the full product stack that an MCP-powered product sits inside. And if you want the next breakdown as it publishes, the ediccrew newsletter is where it goes first.
The full library lives on the ediccrew blog.
Published on ediccrew.com | explore. understand. build.
Discover more from ediccrew
Subscribe to get the latest posts sent to your email.
