Before we move ahead, find out our
Flagship AI PM Course (PMs at Microsoft, Google, Coinbase, Indeed & 800+ rated 4.9/ 5).
See testimonials and course details
Imagine you are a product manager at a fintech company.
You are building an AI assistant inside the app.
The assistant needs to do four things.
Check account balance.
Pull the last 10 transactions.
Transfer money.
Update KYC details.
Four simple jobs.
You sit with the engineering lead to scope it.
Balance lives in the core banking system. Transactions live in a data warehouse. Transfers go through the payments service. KYC sits inside a compliance vendor.
Each system has its own API. Each API has its own authentication. Each API returns data in its own shape.
The engineer looks at you and says six months.
You go back to your desk and start writing the requirements. Somewhere between rate limits and error handling, you realise something uncomfortable.
You are not building an AI product. You are building glue code.
The Real Problem is Not the Model
Every AI product team is stuck in the same trap. The model is not the bottleneck. The bottleneck is everything around the model.
Here is what the trap looks like in practice.
Every new tool the AI needs requires a fresh integration.
Every API change breaks the connection.
Every model upgrade forces a prompt rewrite.
Every new use case adds another custom endpoint.
Your team spends 70 percent of its time writing plumbing. It spends 30 percent building the actual product.
This is why most AI features die in staging. Not because the model is weak. Because the integration cost is too high.
The Model Context Protocol was built to break this trap.
What MCP Actually Is
MCP is an open standard. It defines how AI models talk to tools, data, and context in one consistent way.
Think of it as a shared language between the model and everything outside the model.
The model does not need to know how the payments API works. The model does not need to know what fields the KYC vendor returns. The model speaks MCP. The tool speaks MCP back.
Anthropic introduced the protocol. The industry adopted it fast, and the reason is simple.
Why Traditional APIs Do Not Fit AI Models
Traditional APIs were built for deterministic programs.
A program knows exactly what it wants. It calls the endpoint. It parses the response. It moves on.
A language model does not work like this. A model reasons probabilistically. It handles fuzzy inputs. It asks clarifying questions. It changes plans mid-task.
Instead of hard-coding every integration, the model queries what is available. It reads what each tool does. It chains tools together based on the task at hand.
The Architecture in One Picture
MCP runs on a client server model. Here is the whole system on one screen.
Two things to notice in this picture.
The first is that the model touches only one interface. Four systems, one protocol.
The second is that nothing below the MCP servers changes. The REST APIs, the SQL, the vendor integrations all stay exactly as they are. The MCP server wraps them.
The client is the AI agent. The server is the environment exposing resources. That is the entire mental model.
The Handshake: How Discovery Works
Here is where MCP gets interesting.
Read that response carefully. It is doing three jobs at once.
It names the tool.
It describes the tool in plain language the model can reason about.
It defines the exact inputs, their types, and which ones are mandatory.
This is the part that replaces prompt engineering. Nobody writes a system prompt explaining how transfers work. The schema is the documentation, and the model reads it at runtime.
No manual wiring. No static configuration. The payments team ships a new tool tomorrow, the model sees it tomorrow.
The Four Building Blocks
Every MCP server exposes some combination of four resource types.
Tools are actions the model can invoke.
Send an email. Search a database. Initiate a transfer. Each one carries metadata explaining what it does and what it needs.Resources are pieces of state or data.
An image, a database row, a text document. Anything the model reads to reason about the task.Prompts are reusable templates.
The server developer writes them once. Every model that connects gets them for free.Context is external information pulled into the reasoning process.
User preferences, company data, chat history.
A useful way to remember the split. Tools are verbs. Resources are nouns. Prompts are instructions. Context is memory.
The model treats all four identically regardless of which server they come from. A calendar server, a CRM, a GitHub server. Same language everywhere. That uniformity is the entire point of the protocol.
One Request, End to End
Now let us return to our fintech PM and trace a single request through the whole system.
A customer types: I want to send 5000 rupees to my mother.
Step 1. The model reads the tools advertised by all four servers. It matches the intent to initiate_transfer on the payments server.
Step 2. The model checks the input schema. It has the amount. It needs a beneficiary_id. It queries the resources on the banking server, finds a saved beneficiary tagged as mother, and picks up the ID.
Step 3. The model calls the tool.
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "initiate_transfer",
"arguments": {
"amount": 5000,
"currency": "INR",
"beneficiary_id": "ben_88213"
}
}
}
Step 4. The MCP server translates this into a call to the actual payments API, waits for the result, and returns a structured response.
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [
{
"type": "text",
"text": "Transfer of INR 5000 to ben_88213 initiated.
Reference: TXN-4471-2026. Status: PENDING_OTP"
}
],
"isError": false
}
}
Step 5. The model reads the result and replies to the customer. It sees PENDING_OTP in the response and asks the customer for the OTP. It never had to be told that transfers require an OTP. The response told it.
Notice what did not happen anywhere in this trace.
Nobody wrote a custom prompt for the transfer flow. Nobody wrote glue code between the model and the payments API. Nobody hard-coded the OTP step.
The six month plan compresses into weeks. Engineering builds four MCP servers, each one a thin wrapper over an existing system, and the assistant composes them on its own.
If you want to learn how to build product using AI and become AI Product Manager, you can join our 12 Weeks AI Product Manager/Builder Cohort (100 Hours including 20 Hours of Interview Prep)
About Author
Shailesh Sharma! I help PMs and business leaders excel in Product, Strategy, and AI using First Principles Thinking. AI Product Manager/Builder Cohort
More Resources
Product Management Mock Interview (Detailed)
Crack AI Business Roles (AI Management Consulting, AI Category Management, AI General Manager, Revenue Planning, etc.) - Course Details
Crack AI Program Manager Roles - Course Details
This is great explanation
Great article! need more code example