Skip to content
BSWEN
Blog

MCP (Model Context Protocol): The USB Standard for AI Agents

Cowrie
Cowrie
Dev @ Bswen

I spent three days writing a custom adapter to connect my AI agent to Google Drive. Then another two days for Slack. Then I started on PostgreSQL and realized: this is unsustainable. Every new agent meant rewriting the same integrations. Every new data source meant N new adapters. N agents times M data sources equals N×M integrations - a combinatorial explosion.

Then I discovered MCP (Model Context Protocol). Anthropic’s open standard that solves exactly this problem. It’s the USB moment for AI agents - one connector for everything.

The N×M Problem That Was Killing Me

Before MCP, connecting agents to tools was manual labor:

Agent A  --- custom code --->  Google Drive
Agent A  --- custom code --->  Slack
Agent A  --- custom code --->  PostgreSQL
Agent B  --- custom code --->  Google Drive  (again!)
Agent B  --- custom code --->  Slack         (again!)
Agent B  --- custom code --->  PostgreSQL    (again!)

Each line represents hours of work. Duplicate effort. No standard. No reuse.

I tried building a shared library. But each agent framework had different assumptions. Each tool had different authentication. Each integration broke when APIs changed.

The real issue: there was no standard. No universal way to say “here’s what I can do” and “here’s how to use me.”

MCP: One Protocol to Connect Them All

MCP (Model Context Protocol) changed everything. Released by Anthropic in November 2024, it’s an open standard based on JSON-RPC 2.0. The core idea is simple:

Instead of N×M integrations, you get N+M.

Each agent implements MCP client once. Each data source implements MCP server once. Done.

Agent A  ---\
Agent B  ---+---> MCP Protocol <---+--- Google Drive MCP Server
Agent C  ---/                      +--- Slack MCP Server
                                   +--- PostgreSQL MCP Server
                                   +--- GitHub MCP Server

The protocol provides three server primitives:

  1. Tools: Actions an agent can invoke (create issue, send message, query database)
  2. Resources: Data an agent can read (files, records, documents)
  3. Prompts: Pre-defined prompt templates for common tasks

And two client primitives:

  1. Roots: Directories the client can access
  2. Sampling: Request the server to generate text via LLM

My First MCP Server in 10 Minutes

I decided to test MCP with a simple GitHub integration. Here’s what I built:

mcp-server-github.json
{
  "name": "github-mcp-server",
  "version": "1.0.0",
  "tools": [
    {
      "name": "create_issue",
      "description": "Create a GitHub issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "repo": { "type": "string" },
          "title": { "type": "string" },
          "body": { "type": "string" }
        },
        "required": ["repo", "title"]
      }
    },
    {
      "name": "list_repos",
      "description": "List repositories for a user",
      "inputSchema": {
        "type": "object",
        "properties": {
          "username": { "type": "string" }
        },
        "required": ["username"]
      }
    }
  ],
  "resources": [
    {
      "uri": "github://repos/{owner}/{repo}",
      "name": "Repository",
      "description": "Access repository information"
    }
  ]
}

The inputSchema uses JSON Schema - familiar territory for anyone who’s worked with OpenAPI or TypeScript interfaces.

My Claude agent immediately understood how to use it:

User: Create an issue in my repo about fixing the login bug


Claude: I'll use the create_issue tool from your GitHub MCP server.
- repo: "myusername/myrepo"
- title: "Fix login bug"
- body: [auto-generated description]


Issue created: #247

No custom code. No adapter. Just worked.

Why MCP Matters More Than You Think

The brilliance of MCP isn’t technical - it’s ecosystem economics.

Before MCP: If you build a new agent, you need to write integrations for every tool your users want. That’s weeks of work before you’re useful.

After MCP: You implement MCP once. Instantly, your agent can use thousands of existing MCP servers. Google Drive, Slack, PostgreSQL, GitHub, Notion, Linear, Jira… the list grows daily.

By early 2026, the MCP ecosystem had exploded:

  • Thousands of community-built MCP servers
  • Official servers from Google, Slack, GitHub
  • Support in Claude, Cursor, Windsurf, Continue
  • OpenAI adopted MCP in December 2025
  • Anthropic donated MCP to Linux Foundation (December 2025)

This is the network effect in action. More servers attract more clients. More clients attract more server builders.

Common Confusion Points I Encountered

MCP vs Function Calling

I initially confused MCP with function calling. They’re related but solve different problems:

  • Function Calling: How a model invokes a tool (mechanism)
  • MCP: How agents discover and connect to tools (transport/protocol)

Think of it this way: Function calling is how you press a button. MCP is the USB port the button is connected to.

MCP vs A2A

Google announced A2A (Agent-to-Agent) protocol in late 2025. I wondered: are they competing?

Not really. A2A handles agent-to-agent communication. MCP handles agent-to-tool communication. They’re complementary.

In practice, MCP has stronger ecosystem momentum because:

  1. Launched first (November 2024 vs late 2025)
  2. More community adoption
  3. Broader industry support
  4. Already donated to Linux Foundation

”Isn’t This Just Another Standard?”

I was skeptical. We’ve seen countless “universal” protocols. What makes MCP different?

Three things:

  1. Timing: AI agents are exploding. The pain point is real and immediate.
  2. Simplicity: JSON-RPC 2.0 foundation. Easy to implement in any language.
  3. Backing: Anthropic built it, open-sourced it, donated it. No vendor lock-in possible.

How I Use MCP Now

My agent architecture has simplified dramatically:

Before MCP:
├── agents/
│   ├── agent-a/
│   │   └── integrations/
│   │       ├── google-drive.ts    (custom)
│   │       ├── slack.ts           (custom)
│   │       └── postgres.ts        (custom)
│   └── agent-b/
│       └── integrations/
│           ├── google-drive.ts    (duplicate!)
│           ├── slack.ts           (duplicate!)
│           └── postgres.ts        (duplicate!)


After MCP:
├── agents/
│   ├── agent-a/  (MCP client built-in)
│   └── agent-b/  (MCP client built-in)
└── mcp-servers/
    ├── google-drive/
    ├── slack/
    └── postgres/

Each server is a standalone npm package or Docker container. Agents discover tools at runtime. No recompilation needed.

Mistakes I Made Implementing MCP

Mistake 1: Reinventing the wheel

I spent a day writing my own MCP server from scratch before discovering the official TypeScript SDK:

install-mcp-sdk.sh
npm install @modelcontextprotocol/sdk

Don’t do this. Use the SDK.

Mistake 2: Over-engineering resources

I initially tried to make every piece of data a “resource.” Turns out, resources are for read-heavy, cacheable data. Tools are for actions. Keep them separate.

Mistake 3: Ignoring prompts

The prompts primitive felt redundant at first. But they’re powerful for domain-specific workflows. My coding agent now has a “review-code” prompt that includes my team’s style guide.

The Ecosystem Reality Check

MCP isn’t perfect. Current limitations:

  1. Streaming support: JSON-RPC 2.0 isn’t designed for streaming. Large responses can be slow.
  2. Authentication: Each server handles auth differently. No standard OAuth flow yet.
  3. Discovery: No central registry. Finding MCP servers is manual work.

But these are growing pains, not fundamental flaws. The Linux Foundation governance means these will get solved.

What You Should Do Now

If you’re building AI agents:

  1. Stop writing custom integrations. Check if an MCP server exists first.
  2. Implement MCP client support. Most frameworks have plugins now.
  3. Contribute servers. If you need something that doesn’t exist, build it. The community will thank you.

The USB moment has arrived. MCP is the connector. Everything else is just implementation.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

The standard is open. The ecosystem is growing. The question isn’t whether to adopt MCP - it’s how quickly you can.

Comments

Tags: