The Universal Remote for AI: A Deep Dive into the Model Context Protocol (MCP)

Connect any AI model to any tool, database, or API — once and for all.

For years, AI developers faced what's known as the N × M integration problem.

Suppose you wanted three different AI models to interact with five external services — GitHub, Slack, a database, and Jira. You'd have to write and maintain fifteen separate, brittle custom integrations. Every new model meant five more. Every new service meant three more. The combinatorics were brutal.

The Model Context Protocol (MCP) changes everything. Think of it as the USB-C port for AI: a secure, open standard that lets any AI model seamlessly plug into any external data source or tool using one universal language.

Whether you're building a simple chat assistant or a fully autonomous agent, understanding MCP is no longer optional.

The N × M Problem, Visualised

Without a universal protocol, every model–service pair needs its own custom glue code. Three models × four services = twelve separate integrations to build and maintain:

                GitHub      Slack       Postgres    Jira
GPT           ❌ custom   ❌ custom   ❌ custom   ❌ custom
Claude        ❌ custom   ❌ custom   ❌ custom   ❌ custom
Your Agent    ❌ custom   ❌ custom   ❌ custom   ❌ custom

Add a new model? Four more integrations. Add a new service? Three more. The maintenance burden compounds with every addition.

With MCP, you connect your model once to the MCP ecosystem, and every MCP-compatible tool becomes instantly available. No more N×M explosions — just one clean, reusable interface.

Core Architecture: Three Roles, One Protocol

At its heart, MCP defines three distinct roles:

🖥️ Host
The application that runs the AI model and the user interface, orchestrating everything. Think of it as the brain of the operation. Examples: Claude Desktop, Cursor IDE, or your own custom agent app. The Host owns the LLM, the chat interface, and enforces security.

🔌 Client
A lightweight protocol engine embedded inside the Host — completely invisible to the user. It discovers available tools, manages request lifecycles, and translates AI commands into standard JSON-RPC messages. Think of it as the universal translator.

🌉 Server
A lightweight program that speaks MCP on one side and a native service API on the other. Think of it as a specialised power adapter. Examples: a local SQLite server, an enterprise Salesforce connector, or a file-system bridge.

Here's how they fit together:

  User
   │
   ▼
┌─────────────────────────┐
│  Host Application       │
│  (LLM + MCP Client)     │
└───────────┬─────────────┘
            │ JSON-RPC over Transport
            ▼
┌─────────────────────────┐
│  MCP Server             │
│  (GitHub, DB, FileSys…) │
└───────────┬─────────────┘
            │
            ▼
   External API / Database

The Transport Layer: How Client and Server Actually Talk

MCP messages travel over one of two transport mechanisms:

STDIO (Standard Input/Output)
Best for local integrations. The Host spawns the MCP Server as a child process, and they communicate through standard input/output streams — zero network overhead, ultra-fast, and secure by default since nothing leaves your machine. Perfect for personal dev tools.

HTTP / SSE (Server-Sent Events)
Best for remote or enterprise integrations. A central server runs in the cloud, and local clients connect using standard web protocols. Scalable, supports multiple simultaneous clients, and works over the internet. This is the backbone of team-wide and enterprise MCP deployments.

The Three Primitives: Verbs, Nouns, and Templates

When a Client connects to a Server, it gains access to three kinds of capabilities — the building blocks of every MCP interaction.

🛠️ Tools — what the AI can *do*
Executable functions the AI can invoke to take action. Examples: execute_sql_query, create_github_issue, send_email.

📂 Resources — what the AI can *read*
Read-only context the AI can pull in without taking any action. Examples: database schemas, log files, user profiles.

📝 Prompts — how the AI should structure its output
Server-hosted templates that shape how the AI thinks or formats its response. Examples: a "code review prompt" or a "customer support reply template".

Advanced Features: When the Server Talks Back

Early AI integrations were strictly one-way: the AI requested data, and the tool returned it. MCP introduces true two-way dialogue with three powerful mechanisms.

🔄 Sampling (Server → AI)

The MCP Server doesn't have its own LLM — but sometimes it needs AI reasoning mid-task.

Scenario: A server fetches 1,000 raw log entries. Instead of dumping them all into the conversation, it sends a Sampling request back to the Host: "Use your LLM to summarise these logs into the top 3 trends." The Host processes the logs, returns a clean summary, and the Server continues.

🛑 Elicitation (Server → User)

When high-stakes decisions are involved, the AI shouldn't guess. Elicitation lets a Server pause execution and ask the human for clarification before proceeding.

Scenario: The AI decides to delete old database records. Before executing, the MCP Server sends an Elicitation request. The Host surfaces a dialog: "Delete records older than 30 days or 90 days?" Once the user responds, execution resumes.

🌳 Roots (Safe Boundaries)

Roots define the strict sandbox where the AI is allowed to operate — most commonly used with file-system servers.

The Client tells the Server: "You may only read and write inside /projects/my-app." If the AI attempts to access /etc/passwd, the Server rejects the request outright based on that Root definition.

The Autonomous Agent Loop: The ReAct Pattern

So how does an AI actually use all of this to solve complex tasks without constant hand-holding? It follows the ReAct (Reason + Act) loop — a design pattern that keeps the agent moving forward, using only MCP for execution.

  User Input
      │
      ▼
  🧠 Reason (LLM thinks)
      │
      ▼
  🔀 Decide: need a tool?
   │               │
  No              Yes
   │               │
   ▼               ▼
 Done        ⚡ Act (MCP Tool Call)
                   │
                   ▼
             📥 Observe Result
                   │
                   └──── repeat ────┘

Here's what that looks like in code:

def agent_loop(user_prompt, mcp_client, llm, max_steps=10):
    conversation_memory = [user_prompt]
    tools = mcp_client.list_tools()

    for step in range(max_steps):
        # REASON
        ai_response = llm.generate(conversation_memory, tools)
        conversation_memory.append(ai_response)

        # DECIDE
        if ai_response.is_finished:
            return ai_response.final_answer

        if ai_response.has_tool_call:
            tool_name = ai_response.tool_name
            tool_args = ai_response.tool_arguments

            # ACT (MCP Client executes)
            result = mcp_client.execute(tool_name, tool_args)
            conversation_memory.append(f"Tool result: {result}")

    # Safety circuit breaker
    return "Error: task too complex, exceeded maximum steps."

The safety circuit breaker: The max_steps parameter prevents infinite loops. If the LLM gets stuck retrying a failing tool, this hard stop saves both compute and API costs.

Security: Two Rules That Actually Matter

Giving an autonomous agent access to a universal tool standard is powerful — and potentially dangerous. Two safeguards are non-negotiable.

1. Human-in-the-loop for destructive actions

Not every action carries the same risk. A rough rule of thumb:

• Read logs — no approval needed, it's a safe read operation
• Delete data — always require explicit user confirmation
• Send an email — always require explicit user confirmation

The Host should always require a physical confirmation click before the MCP Client executes any write or delete operation.

2. Principle of Least Privilege

Use Roots to lock servers to specific directories or data scopes. Never grant a server more access than it absolutely needs. Treat every MCP Server as a separate microservice with its own threat model — because effectively, it is.

Why MCP Is a Foundational Shift

• Standardisation — one protocol to learn, build, and debug across every tool and model
• Reusability — write a GitHub MCP server once; use it with any MCP-compatible AI
• Security — built-in boundaries via Roots, human approval gates, and sandboxed processes
• Scalability — from local one-off scripts to enterprise-grade agent fleets

MCP isn't just another abstraction layer. It's the shift that turns AI systems from fragile, hard-coded scripts into modular, secure, plug-and-play agents.

Where to Start

The best way to understand MCP is to build with it:

1. Spin up a simple MCP server — try a local filesystem or SQLite bridge
2. Connect it to a host — use Claude Desktop or a lightweight Python script
3. Experiment with tool calls — let your AI read files, query a database, or open a GitHub issue

The protocol is open, the tooling is maturing fast, and the ecosystem is growing quickly. The developers who get fluent with MCP now will be the ones building the agents that matter next.

Found this useful? Follow for more deep-dives into AI infrastructure and agentic systems.