← articles

Notes on MCP (and why I'm building with Go)

Notes on understanding and building with the Model Context Protocol (MCP) using Go. Rather than being a complete guide, this is a breakdown of the concepts, mental models, architecture decisions, and implementation details that helped me understand how MCP enables AI agents to interact with tools, resources, and external systems in a structured way. I also explore why I chose Go over the more common Python/TypeScript stack, how MCP transports work, and why I believe MCP has the potential to become a foundational capability layer for intelligent systems. If you are a backend engineer curious about AI infrastructure, agent systems, orchestration, or protocol design, this article is for you.

Introduction

This article assumes basic familiarity with APIs, JSON, and AI agents.

MCP is still a nascent protocol, and early adopters are mostly building with Python or TypeScript. I had to dig in to understand the fundamentals,
read articles, see videos implemented in other languages, read other people's code implementations (almost my favorite thing to do these days), especially example implementations from the MCP repo itself. It was quite the journey, overwhelming yet fun, and I absolutely loved it.

This article is not meant to be a comprehensive guide because the MCP documentation does a pretty solid job in doing that. But instead,
a documentation of my insights and break down to a more approachable format while studying and building an MCP server in Go.

MCP

Model Context Protocol (MCP) is a protocol that enables AI models to communicate with other tools and services.

It provides a standardized way for AI models to discover, access, and utilize external data sources and functionality,
which extends their capabilities beyond their training data. Think of it as the USB-C for AI universal plug that lets models seamlessly interface with the outside world.

Why I Chose Go for MCP

Go? you ask. Why not go with Python? Aren't they more popular in the AI space?

I'll cover the deep dive into Go in another article, but here’s the short version: Go's simplicity and performance are perfect for MCP. When building an MCP server, you're essentially building a high-throughput JSON-RPC bridge. Go’s standard library, out-of-the-box concurrency (goroutines for parallel tool execution), and single-binary deployments make it incredibly painless to run an MCP server alongside your local or cloud agents.

Transport Modes and Go

Another thing I missed mentioning is how naturally Go handles MCP's communication transports. The protocol supports two primary transport modes:

  1. Stdio Transport: The client and server communicate via standard input and standard output. In Go, this is incredibly elegant. Because Go's standard library revolves around the io.Reader and io.Writer interfaces, wrapping os.Stdin and os.Stdout into an MCP JSON-RPC handler requires almost zero friction. You just plug standard I/O streams directly into a JSON decoder/encoder.
  2. SSE (Server-Sent Events) Transport: For server-to-server communication over HTTP. Go’s net/http package and its concurrency model make it trivial to hold open SSE connections. You can easily manage multiple client streams using channels, broadcasting updates without blocking the main thread or needing complex async runtimes like you would in Node.js or Python.

Important Concepts

Concepts Description example
Tools The raw functions that the AI application can call and execute to perform tasks or actions. Get balance, Schedule meeting, Get Employee Performance Data, etc.
Resources Data source for your MCP server, Could be files, third-party services, databases,etc. File system, Database, API, Git repository, Blockchain
Prompts Pre-defined instructions that guide the AI usage of Tools and Resources (like context templates or RAG, context templates helps in providing relevant context/information to the LLM). Transfer funds, Get balance, Schedule meeting with person, Summarize Employee Performance Data, etc.

for a more detailed explanation check MCP Documentation

Mental Model

As a backend engineer, I use to liken MCP to "Backend service for Agents". Then I took a step back to see the bigger picture and realized it's more than that.
It is a capability layer that exposes your existing or new system to agents in a structured, discoverable way, giving the agent the capability to decide when, how and which tool to use,
which data source to pull information from and how to best utilize it to achieve its goal.

What MCP Is Not

To build a solid mental model, it also helps to know what MCP is not:

  • It is not a replacement for APIs.
  • It is not an AI model.
  • It is not a database.
  • It is not an agent framework (like LangChain or AutoGen).

It is strictly a communication and capability protocol that standardizes how AI applications interact with tools and external systems.

Why MCP Matters

1. Agentic Intelligence

LLM usage is scaling, and so are the costs. Why? Because we often give LLMs broad tasks with inadequate context, forcing the application into expensive reasoning loops or complex data retrieval pipelines just to figure out what we mean.

Then we have the problem of hallucinations to deal with. The more reasoning the LLM has to do without proper context, the more likely it is to hallucinate due to context overload.

How does MCP help?

MCP constrains and guides reasoning through structured capability exposure. It tells the LLM, "Here is the context, here are the tools you can use, and here is the data you can access."

The heavy lifting is done by your optimized service—relevant retrieval is handled by your database, and the actual tool execution is done by your backend.
The LLM just has to select which tool to use and with what arguments. The output is then seamlessly returned to the agent.

2. Model Interoperability

Before MCP, when a developer builds an application that solves a particular problem—say, a code generation tool—they release it to the world. But if you want to use that tool in your application, you often have to build a custom integration, which defeats the purpose of it being a standalone tool.

MCP solves this by decoupling the tool from the model entirely.

It breaks down the problem into smaller, more manageable capabilities and executes them at the edge.

This way, the LLM handles the general reasoning and orchestration, while the MCP server holds the specialized domain knowledge and executes the deterministic logic. This separation is also far more cost-efficient.

Also, an LLM acting strictly as an orchestrator is not a bad thing. It means it is more general purpose. You can use the same LLM to solve different problems
depending on the context and tools it has access to. In terms of interoperability, it allows you to swap out different LLMs while keeping the same knowledge source and tools, saving you from rebuilding a niche agent when the team decides to switch from one LLM to another.

Say, your organization built a complex agent for your company's lawyers, which knows a lot about your company's internal laws and regulations and has access to all the internal documents,
and your company is now switching from using OpenAI to Anthropic LLMs.

If you are not using MCP, you would have to rebuild the entire agent to work with Anthropic LLMs, which would be a waste of time and resources.

But if MCP is used, you will need to plug in your new Anthropic Agent into your existing MCP server, which would be a much simpler process, efficient and more cost effective.

3. Tool Integration

The MCP server shines brightest when it comes to tool integration, with traditional APIs, exposing your service to agents is a bit of a
messy process, you have to figure out how to properly integrate the LLMs, the model APIs, the prompt templates, the retrieval systems, etc. into your service.

With MCP, you can abstract all of that into a MCP server, which can then be used by any agent that needs to access your service, without
rebuilding the entire service for each agent.

Your AI agent / application can now for example, a KPI agent that gets data on employees, summaries the data, generates reports and send to the email of the manager, while also having the capability
to schedule a 1:1 between manager and employees with the low KPI scores.

You need your agent to be able to:

  • Fetch relevant employee data from your database
  • Summarise the data
  • Generate reports
  • Send to the email of the manager
  • Schedule 1:1 meetings between manager and employees blocking your favorite integrated calendar (Google Calendar, Microsoft Outlook Calendar, etc.)
  • Send message over slack to the employee/manager
  • Send reminders to employees who have not responded to the 1:1 schedule request

All of this can be achieved with MCP by building a MCP server that exposes the above mentioned tools and resources to the agent.

sequenceDiagram
    participant Manager
    participant Agent as AI Agent
    participant MCP as MCP Server
    participant DB as Database
    participant API as External APIs (Slack/GCal)

    Manager->>Agent: "Review KPIs & schedule 1:1s"
    Agent->>MCP: Query Resource: Employee Data
    MCP->>DB: Fetch Records
    DB-->>MCP: Returns Data
    MCP-->>Agent: Context provided
    
    Agent->>MCP: Call Tool: Summarize & Generate Report
    MCP-->>Agent: Report generated
    
    Agent->>MCP: Call Tool: Email Manager
    MCP->>API: Send Email
    
    Agent->>MCP: Call Tool: Schedule 1:1s
    MCP->>API: Block Calendar & Slack Reminder
    
    Agent-->>Manager: "Task complete. Report sent & meetings scheduled."

How Does The MCP Work?

The MCP protocol is a simple standardized JSON-RPC protocol that is used to communicate between the MCP server and the agent.

The MCP server exposes a set of tools and resources that the agent can use to perform tasks, converts existing APIs into MCP-compatible endpoints, without requiring any changes to the original APIs.

It also handles authentication, defines capability and communication standards to be used by the LLMs and AI Applications.

It is set up in a way that enables the adaptation of existing APIs and functionality. You don't need to change existing APIs for Google, Figma, Slack, or GitHub. Instead, you write an MCP server that acts as a bridge, adapting their existing endpoints to the MCP standard.

Easily put, it's a plug-and-play layer between existing APIs and LLMs/AI Applications. What an amazing level of sophistication and flexibility for the intelligent automation systems of the future.

Tools and Resources

Let's make this clearer with a practical example.
Imagine you have a task for an agent: "Transfer $10 to Alice".

Concept Example for "Transfer $10 to Alice"
Tool transfer_funds (The function that executes the transfer)
Resource Alice's Account Balance (The data needed to check if the transfer is possible)
Prompt Transfer $10 to Alice from my account (The instruction given to the agent)

Let's break down the actual sequence of events when the agent executes your instruction:

sequenceDiagram
    participant User
    participant Agent as MCP Agent
    participant MCP as MCP Server
    participant DB as Backend System

    User->>Agent: "Transfer $10 to Alice"
    Agent->>MCP: Read Resource: Alice's Balance
    MCP->>DB: Check balance
    DB-->>MCP: Balance sufficient
    MCP-->>Agent: Resource data returned
    
    Agent->>MCP: Call Tool: transfer_funds(amount=10, to=Alice)
    MCP->>DB: Execute transaction
    DB-->>MCP: Transaction successful
    MCP-->>Agent: Tool execution result
    
    Agent-->>User: "Transfer Successful"

Multi-Service Single Agent Orchestration

MCP gives you the capability to create multiple services, each service with its own tools and resources, and expose it to agents.

This is particularly useful for building complex agents that need to perform multiple tasks, each task requiring different capability domain.

For example, A banking agent can be built to have the following MCP services:

  • The agent's primary service for its domain (Financial Domain for banking)
  • A Social Media service
  • A Project Management service

This way, a master agent has more power and flexibility to perform complex tasks across different domains in the organization by orchestrating the services, while still having a niche AI application / agent for each domain that can be used independently.

Summary

The MCP protocol holds a lot of potential to revolutionize the AI industry. It is a game-changing technology that enables the creation of complex, intelligent agents / AI applications that can perform tasks that were previously impossible cost effectively, securely and efficiently.

Think of it as USB-C for AI, where different devices can be plugged into different applications seamlessly.

The true power of MCP will only be seen in the coming years as it matures and more and more services and applications adopt the MCP standard.

Comments
← back to articles