MCPAI ArchitectureTechnical

How AI Assistants Talk to Your Tools: MCP Explained Simply

AR Security
March 9, 2026
6 min read

If you've used Claude, ChatGPT, or any modern AI assistant to connect with external tools like Figma, GitHub, or your database, you've likely encountered MCP — the Model Context Protocol.

But how does it actually work under the hood? Let me break it down the same way I'd explain it to a colleague.

What is MCP?

MCP is a universal standard for connecting AI assistants to external tools and data sources.

Think of it as USB for AI — one standardized plug that works everywhere, instead of every tool needing its own custom integration.

Before MCP: Every AI-to-tool connection was custom-built.

After MCP: Build once, works with Claude, ChatGPT, Gemini, and any MCP-compatible host.

The Architecture

There are three players:

┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
│      HOST       │      │   MCP SERVER    │      │   EXTERNAL API  │
│ (Claude Desktop)│ ←──► │ (Figma plugin)  │ ←──► │   (figma.com)   │
└─────────────────┘      └─────────────────┘      └─────────────────┘
      Your AI              The translator           The service
  • Host: The AI application (Claude Desktop, your custom app)
  • MCP Server: A small program that exposes tools to the AI
  • External API: The actual service (Figma, GitHub, Slack, etc.)

How They Communicate: stdio

Here's where it gets interesting.

The Host and MCP Server don't talk over the internet. They use something called stdio — standard input/output.

stdio (pronounced "standard I-O") is how programs on your computer communicate via simple text streams:

  • stdin (standard in): How a program receives input
  • stdout (standard out): How a program sends output

These are local pipes between two processes on your machine. No network. No ports. No internet. Just two programs passing text back and forth in memory.

┌─────────────────────┐              ┌─────────────────────┐
│   CLAUDE DESKTOP    │              │   FIGMA MCP SERVER  │
│                     │              │                     │
│  writes to ──────────── stdin ────────► reads from       │
│                     │              │                     │
│  reads from ◄─────────── stdout ─────── writes to        │
│                     │              │                     │
└─────────────────────┘              └─────────────────────┘
            ▲                                    ▲
            └────────── SAME MACHINE ────────────┘
                      (no network)

It's the same as running this in your terminal:

echo "hello" | cat

echo writes "hello" to stdout → pipe → cat reads it from stdin. All local. All in memory.

Real Example: Figma MCP

Let's walk through what happens when you ask Claude to export a design from Figma.

Step 1: You ask Claude

"Export the header frame from my design"

Step 2: Claude → MCP Server (LOCAL via stdin)

Claude writes a JSON request to the Figma MCP server's stdin:

{"method": "export_frame", "params": {"frame": "Header"}}

Step 3: MCP Server → Figma API (INTERNET via HTTP)

The MCP server reads the request, then calls Figma's actual API over the internet.

Step 4: Figma API → MCP Server (INTERNET)

Figma returns the exported image URL.

Step 5: MCP Server → Claude (LOCAL via stdout)

The MCP server writes the result back:

{"result": {"image_url": "https://figma.com/exports/header.png"}}

Step 6: Claude tells you

"Here's your exported header frame."

The Key Insight

There are two separate communication channels:

YOUR LAPTOP                                    INTERNET
┌─────────────────────────────────┐           ┌──────────────┐
│                                 │           │              │
│  Claude ◄──stdio──► MCP Server ─────HTTP────► Figma API   │
│                                 │           │              │
│        100% LOCAL               │           │   REMOTE     │
│       (no internet)             │           │              │
└─────────────────────────────────┘           └──────────────┘
  • Claude ↔ MCP Server: Local stdio pipes (never touches the internet)
  • MCP Server ↔ External API: HTTP over the internet (this is the actual data transfer)

The MCP server acts as a translator between local communication and remote APIs.

Why This Design?

Why use local stdio instead of HTTP for the Claude ↔ MCP connection?

stdioHTTP
No port conflictsNeeds an available port
No network exposurePotential security risk
Simple subprocessMore complex setup
Works on every OSRequires server configuration

It's simpler, safer, and more portable.

Security Considerations

MCP does have known security concerns:

  • Prompt injection via tool responses
  • Tool permission abuse — combining tools to exfiltrate data
  • Lookalike tools — malicious servers impersonating trusted ones

If you're deploying AI agents with MCP in production, security tooling to monitor and validate tool calls is essential.

TL;DR

  • MCP = Universal standard for AI ↔ tool connections
  • stdio = Local communication pipes (stdin/stdout)
  • How it works: Claude talks to MCP servers locally via stdio; MCP servers talk to external APIs via HTTP
  • Why it matters: Build once, works everywhere

The architecture is elegant in its simplicity. And now that you understand it, you'll see MCP everywhere.

Share this article

Need AI Agent Security?

AR Security provides real-time protection against prompt injection, data exfiltration, and other AI agent threats.