MCP Servers Explained In Under 10 Minutes |

Welcome to this article where we will walk you through some of the modern architectural components for developing and architecting production-ready AI systems, starting from the ground up. Today, we'll explore MCP servers.

The Bleeding Edge of AI Architecture

MCP, which stands for Model-Context-Protocol, is a cutting-edge concept in AI development. If you're reading this, you're getting a look at a technology that is just beginning to circulate within the developer community. It's a raw concept that engineers are starting to implement in production, learning from their experiences and sharing their findings.

The idea of MCP was introduced by Anthropic, an AI company known for its innovative solutions. The primary purpose of MCP is to offer a standardized way—whether remote or local—for large language models (LLMs) to utilize external resources or functions.

Imagine you have an LLM running, and you want it to access real-time information, like the current weather. You would need it to communicate with a weather API, retrieve the data, and process it to answer a user's query. This capability makes an LLM more powerful, turning it into an agent-like system using a Retrieval-Augmented Generation (RAG) approach to fetch the latest data. MCP provides the framework for this interaction. Think of it as a marketplace where various MCP servers exist, each serving a specific purpose. You can subscribe your LLM to these servers to access their data and tools.

Understanding the Core Components of MCP

At its heart, MCP relies on a Model that works with Resources (or Context) through a Protocol. This defines the entire client-server relationship.

Model: This can be any LLM, from a massive model to a smaller one like TinyLlama.
Context: This represents your data, which could be a file storage system, memory, or any other data source.
Protocol: This defines the communication rules between the LLM and the resources or servers.

This architecture involves a consumer at the edge, the context and intelligence, and the protocol enabling back-and-forth communication.

The Server-Side Architecture

An MCP server consists of three main parts:

Protocol: This is the exposure layer that describes how other services can communicate with the server. It could be a RESTful API, gRPC, or another standard.
Resources: This is the data hosted on the server that you are making available. It can be raw content, a JSON file, or any other data format.
Tools: These are more intelligent than simple resources. A tool is a function that performs an action, such as an add function that calculates the sum of two numbers. While modern LLMs can often perform such calculations internally, this serves as a simple, illustrative example.

The Client-Side Interaction

On the other side of the architecture, the client also has three components:

Prompt: A prompt from a user initiates the call.
Model: The prompt is sent to a model, which then looks up the available MCP tools.
MCP Tools: The MCP client communicates with the MCP server via the protocol to discover what tools or resources are available to fulfill the user's request.

The flow is as follows: a prompt triggers the model, the model calls the MCP tools on the client side, which then communicates with the server's protocol to access the server's tools and resources. This interaction is fundamental to how MCP functions.

Building a Simple MCP Server in C

Let's walk through a simple C# implementation to see this in action. We will build a basic MCP server and a client to communicate with it.

First, we'll start with an empty solution and create a console application for the server.

// SimpleMcp.Server project

We need to install a library to handle the MCP implementation. For this example, we'll use a straightforward library called Mcp.

After installing the package, we can create our first tool. Remember the architecture diagram; we are creating a Tool that will be exposed through a Protocol.

CalculatorTool.cs ```csharp using Mcp;

public class CalculatorTool { [McpTool(Name = "addition", Description = "This tool will add two numbers")] public static int Addition( [McpParameter(IsRequired = true, Description = "first number")] int firstNumber, [McpParameter(IsRequired = true, Description = "second number")] int secondNumber) { return firstNumber + secondNumber; } } ```

In this CalculatorTool, we define a function Addition. We use the McpTool attribute to give it a name and description, which the LLM will use to understand its purpose. The McpParameter attribute documents the function's parameters, making it clear what inputs are required.

Next, we register this tool and start the server.

Program.cs (Server) ```csharp using System; using System.Threading.Tasks;

public class Program { public static async Task Main(string[] args) { McpServer.RegisterTool(typeof(CalculatorTool));

    await McpServer.StartAsync(
        serverName: "SimpleMcpServer",
        version: "v1.0.0"
    );

    // Keep the server running
    await Task.Delay(-1);
}

} ``This code is remarkably simple. We register ourCalculatorTool` and start the server with a name and version. The server will now run and wait for client requests.

Building the MCP Client

Now, let's build the client to talk to our server. We'll create another console application.

// SimpleMcp.Client project

We install the same Mcp library. The client needs to know the server's location. Since we are running it locally, we can point the client directly to the server's executable for direct standard input/output communication.

Program.cs (Client) ```csharp using Mcp; using System; using System.Collections.Generic; using System.Threading.Tasks;

public class Program { public static async Task Main(string[] args) { var client = new McpClient( name: "McpClient", version: "v1.0.0", server: @"/path/to/your/SimpleMcp.Server.exe" // Update with the correct path );

    // 1. List available tools
    var tools = await client.GetToolsAsync();
    Console.WriteLine($"Found {tools.Count} tool(s).");
    foreach (var tool in tools)
    {
        Console.WriteLine($"Name: {tool.Name}, Description: {tool.Description}");
    }

    // 2. Call the 'addition' tool
    var parameters = new Dictionary<string, object>
    {
        { "firstNumber", 5 },
        { "secondNumber", 10 }
    };

    var result = await client.CallToolAsync("addition", parameters);

    Console.WriteLine($"Result: {result.Content[0].Text}");
}

} ``` To test this, first run the server project. It will start and wait for connections. Then, run the client application.

The client will produce the following output: Found 1 tool(s). Name: addition, Description: This tool will add two numbers Result: 15 As you can see, the client successfully connected to the server, discovered the available addition tool, and called it with the specified parameters to get the result 15.

Conclusion and Future Steps

In this article, we've built the foundational components of an MCP architecture: the server, a tool, the protocol, and a client that can consume the tool. Your LLM can now learn about the server's capabilities and use them to perform tasks.

This signifies a major part of the overall architecture. The next step is to integrate a model and a prompt handler, allowing an LLM to learn about these MCP tools and act as an agent, making calls to various MCP servers to serve different purposes.

There are still numerous challenges to address. This technology is new, and its reliability is still being tested. It relies on the hope that a smart LLM can learn the tools and call them with the exact schema required—a challenge the entire industry is working to solve. With so many brilliant minds on the case, solutions are surely on the horizon.

This step is a critical piece of a larger puzzle, connecting concepts like local LLM execution, agentic models, and RAG. The ability to have a C# application call a large language model, which in turn uses external tools via a standardized protocol, is the next big leap in AI architecture.