An LLM on its own is a brain in a jar. It can reason, write and explain, but it cannot read your database, hit your API, open a file, or check your calendar. To make it actually useful, we wire it up to the outside world with tools. And for a while, every one of us was wiring it up in our own custom, one-off, slightly-broken way.

That is the problem Model Context Protocol (MCP) was built to kill.

Think about it. If you have M AI apps (Claude, Cursor, your own agent) and N systems you want them to talk to (GitHub, Postgres, Slack, your internal API), you were on the hook for M × N custom integrations. Every app spoke to every tool in its own bespoke dialect. It did not scale, and everyone was reinventing the same wheel.

MCP flips that into M + N. Build one MCP server for your tool, and every MCP-compatible app can use it. Build one MCP client into your app, and it can reach every MCP server out there. This is exactly why people call it "the USB-C port for AI", one standard connector instead of a drawer full of proprietary cables.

So What Actually Is MCP?#

At its core, MCP is a simple client-server protocol that standardises how an AI application feeds context to a model and lets the model take actions. It speaks JSON-RPC 2.0 under the hood, so if you have ever worked with an API, none of this will feel alien.

There are three roles to keep straight:

• Host — the AI application the user actually interacts with (Claude Desktop, Claude Code, Cursor, or your own agent). The host manages the LLM and orchestrates everything.
• Client — lives inside the host. Each client holds a dedicated 1-to-1 connection to a single server.
• Server — a lightweight program that exposes some capability (your database, the GitHub API, a filesystem) through the MCP interface.

So one host can run many clients, and each client talks to one server. Your agent might have a Postgres server, a GitHub server and a filesystem server all connected at once, and it does not care how any of them are implemented internally, they all speak the same protocol.

The Three Primitives Every Server Can Expose#

This is the heart of MCP. A server can offer three kinds of things, and the distinction between them matters because they are controlled by different parties.

• Tools (model-controlled) — functions the LLM can decide to call, like create_issue, run_query or send_email. These are actions. The model chooses when to invoke them, usually with a human approving the call.
• Resources (application-controlled) — read-only data the server can expose as context, like a file, a database row, or a log. Think of these as things you attach to the conversation rather than actions the model takes.
• Prompts (user-controlled) — reusable, parameterised prompt templates a user can pull in on demand, like a "review this PR" or "summarise this ticket" workflow.

The split is deliberate. Tools are powerful and side-effectful, so they sit behind the model's decision plus a human's approval. Resources are passive data. Prompts are user-triggered shortcuts. Get this separation right and your server feels natural to use.

How a Connection Actually Works#

When a client connects to a server, they go through a quick handshake and then settle into normal messaging. Roughly:

1. Initialize — the client and server exchange protocol versions and capabilities. "Here is what I support, what about you?"
2. Discovery — the client asks "what tools/resources/prompts do you have?" and the server responds with a list, each with a name, description and input schema.
3. Execution — the model reads those descriptions, decides it needs get_forecast, and the client sends a tools/call request. The server does the work and returns a result.

The transport underneath can be one of two things:

• stdio — the server runs as a local subprocess and talks over standard input/output. Perfect for local tools (filesystem, a local database, git).
• Streamable HTTP — the server runs remotely and talks over HTTP. This is how hosted, multi-user MCP servers work.

You write your server logic once; swapping the transport is a couple of lines.

Let's Build a Tiny MCP Server#

Enough theory. Here is a minimal server in TypeScript using the official SDK. It exposes a single tool that returns a weather forecast.

First install the SDK:

npm install @modelcontextprotocol/sdk zod

Now the server itself:

// server.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';
 
// 1. Create the server with a name + version
const server = new McpServer({
  name: 'weather',
  version: '1.0.0',
});
 
// 2. Register a tool. The Zod schema becomes the input contract the
//    model sees, so a good description here matters a LOT.
server.tool(
  'get_forecast',
  'Get the current weather forecast for a given city',
  { city: z.string().describe('City name, e.g. "Bengaluru"') },
  async ({ city }) => {
    const res = await fetch(
      `https://api.example.com/forecast?city=${encodeURIComponent(city)}`
    );
    const data = await res.json();
 
    return {
      content: [
        { type: 'text', text: `Forecast for ${city}: ${data.summary}` },
      ],
    };
  }
);
 
// 3. Connect over stdio so a local host can spawn it
const transport = new StdioServerTransport();
await server.connect(transport);

That is a fully working MCP server. Notice the tool takes a name, a description, an input schema (Zod), and a handler. The description and schema are what the model reads to decide when and how to call it, treat them like documentation for a very literal junior developer.

Plugging It Into a Host#

To use this server in a host like Claude Desktop or Claude Code, you register it in a config file. The host then spawns your server and wires it into the model automatically.

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/absolute/path/to/weather-server/build/server.js"]
    }
  }
}

That is it. Restart the host, and the model can now call get_forecast. Ask "what's the weather in Bengaluru?" and the model will discover your tool, call it, and fold the result into its answer, no custom glue code on the app side at all.

This is the whole magic of MCP: you wrote the integration once, and now any MCP-aware app can use it. The same server works in Cursor, in a custom agent you build, or in the next AI app that has not even shipped yet.

Claude Code vs OpenCode - Which AI Coding Assistant Should You Use?

A detailed comparison between Claude Code and OpenCode - two powerful AI coding assistants. Learn which one fits your workflow, budget, and development needs.

Read Full Post

Where MCP Fits in the Agentic Wave#

MCP did not appear in a vacuum. It landed right as agentic coding and autonomous AI workflows went mainstream. An agent is only as capable as the tools it can reach, and before MCP, giving an agent new capabilities meant custom integration work every single time.

Now the loop looks like this: the model reasons about a task, sees the menu of MCP tools available, calls the ones it needs, reads the results, and keeps going until the job is done. The protocol is the connective tissue that makes agents genuinely useful instead of just chatty.

Agentic Coding: Why AI-Powered Development is the Present and Future

Agentic coding is transforming how developers write software. Learn why it is the future, best practices for using AI agents, and how to efficiently review and collaborate with AI-powered development tools.

Read Full Post

The Part Nobody Should Skip: Security#

Here is where I have to put my serious hat on. MCP gives an AI agent real hands, the ability to run queries, hit APIs, touch your filesystem. That power cuts both ways, and the threat model is genuinely new.

A few things to burn into your brain:

• Prompt injection through tool results. If a tool returns attacker-controlled text (a web page, an email, a GitHub issue), that text can contain instructions the model might follow. Treat every tool output as untrusted data, never as commands. This is the number one MCP risk.
• Over-broad tool permissions. A server that can run any SQL is a server that can DROP TABLE. Scope your tools tightly. A get_user_by_id tool is far safer than a raw run_sql tool.
• Human-in-the-loop on side effects. Reads can be automatic. Writes, deletes, sends and payments should require explicit user approval. Good hosts enforce this; good servers make it easy.
• Malicious or compromised servers. Installing a random MCP server is running someone else's code with access to your data and machine, exactly the same supply-chain risk as installing a random npm package. Vet what you connect.

That last point is worth dwelling on, because the MCP ecosystem is exploding and it is tempting to npx any server you find. Don't. The same discipline you apply to dependencies applies here.

One npm install Away from Disaster: A Developer Guide to Supply Chain Attacks

Supply chain attacks are exploding in the age of AI agentic tooling. Learn how a single compromised npm package can drain your crypto wallet or wipe your machine, and the exact configs and best practices every developer needs to install packages safely.

Read Full Post

Conclusion#

For the longest time, connecting AI to the real world was a mess of one-off integrations that none of us enjoyed writing. Model Context Protocol fixes that with a boring, beautiful idea: one open standard, so tools and AI apps can talk to each other without knowing each other's internals. M × N becomes M + N, and suddenly the whole ecosystem compounds.

If you build developer tools, shipping an MCP server is fast becoming table stakes, it is how your product shows up inside every AI app your users already live in. And if you build agents, MCP is the cleanest way to give them capabilities without drowning in glue code.

Start small. Spin up a server with one tool, connect it to Claude Code or Cursor, and watch the model reach out and use it. That first moment where an agent calls your tool and folds the result into its reasoning is genuinely magical, and once you see it, you will start wanting an MCP server for everything.

Just remember the security side while you are having fun. Give your agents good tools, scope them tightly, and keep a human in the loop for anything that bites.

If this helped, or you have built something cool with MCP, drop a comment below. Happy building! 🔌🚀