The problem it solves
With N AI apps and M tools, you'd need N×M custom integrations. MCP makes it N + M: tools expose one standard server, and any MCP client (Claude, IDEs, custom agents) can use it.
Architecture
Server primitives
| Primitive | What | Example |
|---|---|---|
| Tools | Actions the model can call | create_lead, search_invoices |
| Resources | Readable context the app can attach | crm://accounts/123 |
| Prompts | Reusable prompt templates | "Summarise this account" |
Design notes
- MCP servers are integration boundaries: apply auth (OAuth for remote servers), scopes, rate limits and audit logs like any API.
- Keep tools coarse enough to be useful and narrow enough to be safe.
- Watch chained scrape-and-write flows. Content read by one tool can carry prompt injections that trigger another tool's writes.
Plan: expose the CRM/ERP agent platform's tools through an MCP server so any client, not just my own agent, can use them.
Sources & further learning
Videos, courses, docs and books I recommend for this topic.
My post on this
API Series, Part 2: Why MCP when we already have APIs?
MCP doesn't replace APIs. APIs are built for applications; MCP gives AI agents a standard way to discover tools, resources, prompts and existing services. Application → API, AI agent → MCP → APIs / tools / data.
Related topics
AI Agents & Tool Use
LLMs that plan and act through tools in a loop — workflows vs agents, the agent loop, guardrails, and when not to build an agent.
RAG (Retrieval-Augmented Generation) Architecture
Ground LLM answers in your own data — ingestion, chunking, embeddings, vector search, reranking, prompting with citations, and evaluation.