ai

Prompting Is Out. Context Protocols Are the Future.

Because your LLM doesn't need to eat the entire internet to do its job: Model Context Protocol explained.

  • llm
  • artificial-intelligence
  • prompt-engineering
  • developer-tools
  • retrieval-augmented-gen

Summary

What
Welcome, nerds.
Who it is for
Developers and engineers interested in practical frontend and tooling notes.
Result
A clear takeaway you can apply in day-to-day engineering work.

Welcome, nerds.

LLMs are everywhere nowadays. Like Roy Kent. (I can already hear the chant)

They do that, they do this, they do it all. If you’ve got a powerful LLM, maybe even one hooked up to tools, APIs, databases: the works.

And if you’ve either:

  1. Broken it with a prompt longer than your startup’s runway, or
  2. You asked your AI assistant something from a few messages ago, only to get gaslit in JSON…

…then you know the struggle.

But hey, it’s not the size (that’s what she said) of the prompt that matters, it’s how you handle the context.

You’re not alone. Enter Model Context Protocol (MCP)!

Sounds like it’s a dating app for robots. It’s not. But it is hot.

Prompt dump vs MCP context

Stuff the window vs structured tools + context

Shift: stop stuffing the prompt. Protocolize how the model pulls context.

What’s MCP?

Model Context Protocol (MCP) is a new open standard from the folks at Anthropic who built Claude. It’s like the universal adapter for your model’s context: one protocol to plug in all your memory, tools, and data sources. No more dangling wires.

It shines when you don’t want to stuff the whole internet into the prompt like a Thanksgiving turkey. Think fetching context on-demand. Just fetch what you need, when you need it. Clean. Smart.

MCP lets models say: Hey boss, I don’t remember your 20MB HR policy, but I’ll go check that dusty Google Doc if you ask nicely.

It’s like RAG reimagined. Contextual ingestion is now modular. Data sources are pluggable. Indexing is opinionated. The LLM? It’s no longer freeloading: it’s contextually accountable.

You give it a hit list, a map, and a reason. And now it remembers everything.

RAG Was Just the Beginning!

Who Needs It?

  • AI Assistants who want to do more than quote Shakespeare and crash
  • Internal dev tools that should know your API schema better than your junior dev
  • Product teams trying to act like they invented the future with GPT-4 and a Figma prototype
  • Platform engineers who’ve been voluntold to “make it scalable” by EOD
  • Indie hackers who want to RAG responsibly but can’t deal with 3 vector DB SDKs

How the Black Magic Works

You declare “context providers”

These are your data dealers. They sling calendar invites, Jira tickets, GitHub threads, Slack drama, Notion docs, even Kubernetes logs: whatever your model’s craving.

They’re standardised, so your model doesn’t stop mid-sentence like:

Is this… XML? Is that still legal? Who hurt you?

Your model becomes more strategic

Instead of stuffing all the data into one god-sized prompt like a buffet plate at 3am, the model just says:

Yo, context router, fetch me the meaning of life (or at least the user’s latest expense report).

Plug. Play. Profit.

You can run this whole thing on your laptop if you want. Or scale it up for your enterprise like it’s your company’s only KPI this quarter.

Why You Might Actually Want to Use MCP (Besides Impressing Your Team Slack)

  • Standardized AI Integration: Clean, structured interfaces for piping context into your models without crying over YAML.
  • Flexibility: Easily swap between models and vendors. OpenAI, local models, or that GPU box under your desk with the weird thing your cousin trained. Your wish.
  • Enterprise-Safe by Design: Your data stays inside the walls of your infrastructure. Not in someone else’s S3 bucket labeled “Definitely Not PII.”
  • Built for Scale and Chaos: MCP can handle transports like WebSockets, HTTP SSE, UNIX sockets, or good old stdio. Easily add new brains to your bot army: simply connect another MCP server.

Examples

  • SlackBot Copilot: Model reads your threads, then digs into internal docs to answer “what the hell is useStableMemo?” without sounding like it Googled it five minutes ago.
  • Onboarding Buddy: Junior devs ask where the repo is. Model fetches the actual link and setup instructions from Confluence. You don’t have to talk to people. Bliss.
  • Customer Support AI: User says “billing issue.” Model grabs Stripe logs, email thread, and dark secrets from Salesforce. Responds like a pro, doesn’t cry afterward.

But Is It Secure?

MCP makes sure your model only sees what it’s allowed to. You define what’s fetchable, what’s restricted, and what should never be exposed (like that “final-final-v2-FIXED-really-final.docx” you still use).

So, Should You Care?

If you’re building AI tools that aren’t glorified magic 8-balls, yes.

If your model:

  • Sucks at memory
  • Lies like your gym app
  • Costs a kidney in tokens
  • Feels more “vibes” than “verifiable”…

Then MCP is your friend.

How to create one?

Here’s a concise breakdown of the pipeline:

  • Server initialization: Start an MCP server to communicate with Claude Desktop, Windsurf, Cursor… whichever works for you.
  • Fetching data: Retrieve the data from the external API. I have mine connected to a code generation service which fires back React components like a vending machine.
  • Ship it: Now, the AI sidekick, Claude Desktop or Windsurf, reads the code, understands the stakes and creates files as required and drops crisp code in there. Just beautiful execution. You don’t even need a separate tool.

Create an MCP server

const { z } = require("zod");
const { McpServer } = require("@modelcontextprotocol/sdk/server/mcp.js");
const { StdioServerTransport } = require("@modelcontextprotocol/sdk/server/stdio.js");

const mcp = new McpServer({
  name: "My MCP server",
  description: "Generates code",
  version: "1.0.0",
  capabilities: {
    tools: [],
  },
});

mcp.tool(
  "get-code",
  "Generates code for design",
  {
    url: z.string().describe("URL for the design"),
  },
  async ({ url }) => {
    try {
      // abra cadabra
      return {
        content: [
          {
            type: "text",
            text: JSON.stringify(
              {
                success: true,
                result,
              },
              null,
              2
            ),
          },
        ],
      };
    } catch (error) {
      // whoops
      return {
        isError: true,
        content: [
          {
            type: "text",
            text: JSON.stringify(
              {
                success: false,
                error: error.message,
              },
              null,
              2
            ),
          },
        ],
      };
    }
  }
);

const transport = new StdioServerTransport();
mcp.connect(transport);

Start the server and wire it up

If you’re running it with Node, just:

node your_mcp_server.js

Now, if you’re using Windsurf like I am, here’s how to hook it up:

  1. Open Windsurf Settings → Cascade → click “View raw config”
  2. That opens a file called mcp_config.json. Add your server config there like this:
{
  "mcpServers": {
    "Codegen from Figma MCP server": {
      "command": "node",
      "args": ["/path/to/your_mcp_server.js"],
      "env": {},
      "transport": "stdio"
    }
  }
}

Almost there…

Hit “Refresh” under Windsurf settings → Cascade, and your server should show up, ready to roll.

What happens then?

Once your server is added, the AI will hit it up when it needs to. In this setup, if you give it a Figma URL, it routes that to the “Codegen from Figma MCP server” you just added: gets the code back, and boom: file(s) created.

Heads-up

This example uses stdio for transport: so it runs locally. If you’re deploying the server somewhere, consider switching to SSE or another supported transport.

You might run into these

  • Windsurf or Claude desktop doesn’t always hit up the same MCP for a specific task
  • You want your AI to convert the data it receives from the MCP, or don’t modify at all
  • Maybe you want to do some extra processing on the data you get

For these situations, you don’t have to repeat yourself every time. Just throw the instructions into the global or workspace rules files: if the tool supports it. For example, Windsurf lets you set global and workspace rules in the settings. Write it once, ship it to your fellow devs, and collaborate like a pro.

Example rule:

1. Use the Codegen from Figma MCP server for generating code whenever a Figma URL is given

Cool. This Was Supposed to Be a Quick Read.

You just read 1,000+ words about not stuffing 1,000 PDFs into a prompt. Appreciate the scroll. Now go teach your LLM to read more efficiently.

Refresher: Here’s a quickie

You can think of these as wrappers for APIs: but for models.

  • LLMs fetch only what they need, when they need it
  • You define the sources, they do the rest
  • Local-first, enterprise-ready, scale-happy
  • Perfect for copilots, chatbots, internal tools, and probably sentient toasters

Now go break the prompt stuffing habit. Build something that remembers. Or don’t. But then don’t whine when your AI hallucinates a pizza order during a support call.

Thanks, ya’ll: go build something epic! Have fun!


Originally published on Medium.