Model Context Protocol (MCP): The Missing Bridge Between AI and Your Tools

Kethareeswaran N
Mar 31
3.3k
0
1

Article

The Problem: AI Models Are Isolated by Default

Large Language Models (LLMs) like Claude, GPT-4, and Gemini are incredibly powerful at reasoning, writing, and problem-solving. But out of the box, they have a critical limitation:

They are isolated from the real world.

An AI model sitting inside a chat interface has no awareness of:

Your local files or databases
Your company's internal tools
Live data from APIs
Your development environment (GitHub, Jira, etc.)

Every time a developer wanted their AI to interact with an external tool, they had to write custom integration code — one-off, brittle, and impossible to scale.

What is MCP?

MCP (Model Context Protocol) is an open standard, introduced by Anthropic in November 2023, that defines a universal way for AI models to connect to external tools, data sources, and services.

Think of it like this:

USB-C for AI.
Just as USB-C is a universal connector that works with any device — charging, data, display — MCP is a universal protocol that connects any AI model to any external tool, without custom wiring every time.

MCP standardizes:

How AI models ask for tools (tool discovery)
How tools respond (structured responses)
How data is shared (resources and context)
How prompts are managed (reusable prompt templates)

How MCP Works — The Architecture

MCP is built around three core components:

1. Host (The AI Application)

The host is the application running the AI model — for example, Claude Desktop, a custom chatbot, or an IDE plugin. The host is responsible for managing the conversation and deciding when to invoke external tools.

2. MCP Client

The MCP Client lives inside the host. It handles the communication protocol — sending requests to MCP servers and receiving responses. Think of it as the "translator" between the AI model and the external world.

3. MCP Server

The MCP Server is a lightweight, standalone service that exposes specific capabilities — tools, resources, or prompts — to the AI. Each MCP server focuses on one domain:

A File System MCP Server gives the AI read/write access to files
A Database MCP Server lets the AI run queries
A GitHub MCP Server allows the AI to read/create issues, PRs, and commits
A Slack MCP Server enables the AI to read channels and send messages

Diagram 1: MCP Architecture Overview

Shows three zones: Host Application (AI Model + MCP Client) → MCP Servers (File System, Database, GitHub, Slack) → External Tools. Arrows from MCP Client fan out to all MCP Servers via JSON-RPC 2.0, and each server connects to its corresponding external tool.

Key Concepts in MCP

MCP defines four core primitives that structure how AI models and servers interact:

Tools

Tools are callable functions that the AI can invoke. They represent actions — like running a database query, creating a file, or calling an API. The server defines what tools are available, and the AI decides when and how to use them.

Example: run_sql_query(query: string) exposed by a Database MCP Server.

Resources

Resources are read-only data that the AI can access as context. Unlike tools (which perform actions), resources provide information — like the contents of a config file, a list of open GitHub issues, or a Slack channel's recent messages.

Prompts

Prompts are reusable, server-defined prompt templates. They allow teams to pre-define structured prompts for common workflows — like "summarize this codebase" or "review this pull request" — so the AI always has consistent, high-quality instructions.

Sampling

Sampling allows MCP servers to request the AI to generate text or make decisions mid-workflow. This enables complex, multi-step agentic tasks where the server and the AI collaborate back and forth.

MCP Request/Response Lifecycle

Here's what happens when a user asks an MCP-enabled AI to "Find all open bugs in the database and create a GitHub issue for the most critical one":

User sends a prompt to the AI via the Host application
AI Model analyzes the request and identifies it needs two external tools: database access and GitHub access
MCP Client sends a tool discovery request to available MCP servers
MCP Servers respond with their available tools and schemas
AI Model calls the Database MCP Server → query_bugs(status="open", severity="critical")
Database MCP Server executes the query and returns structured results
AI Model calls the GitHub MCP Server → create_issue(title=..., body=..., labels=["bug", "critical"])
GitHub MCP Server creates the issue and returns the issue URL
AI Model composes a final response to the user with a summary and link

Diagram 2: MCP Request / Response Flow

A 5-actor sequence diagram (User → AI Model → MCP Client → MCP Server → External Tool) with 12 numbered steps showing the complete request and response lifecycle, including tool discovery, tool invocation, and final response delivery. Dashed arrows indicate response flows.

MCP vs. Traditional API Integration

Before MCP, connecting an AI to an external tool meant writing custom code for every single integration. Here's how MCP compares:

	Traditional Integration	With MCP
Setup	Custom code per tool	Plug-in MCP server
Standardization	None — every integration differs	Unified JSON-RPC protocol
Reusability	Low — tied to one AI/app	High — any MCP-compatible AI
Maintenance	High — breaks when APIs change	Low — server handles API changes
Tool Discovery	Manual, hardcoded	Dynamic, automatic
Security	Varies	Built-in permission scoping

Diagram 3: MCP vs. Traditional Integration — Side-by-Side

Split view comparison. Left side (red zone): AI Model fans out to 4 separate Custom Code boxes — fragmented and hard to maintain. Right side (green zone): AI Model + MCP Client uses a single standardized protocol to connect to 4 MCP Servers — clean, scalable, and reusable.

Real-World Use Cases

MCP is already being used in production across a range of industries and workflows:

Development Tools

AI-powered IDEs that can read/write code, run tests, and commit to Git — all through natural language
Automated code review bots that pull context from Jira, GitHub, and internal wikis simultaneously

Data & Analytics

Business analysts asking natural language questions against live databases without writing SQL
AI dashboards that pull real-time metrics from multiple data sources in a single prompt

Enterprise Workflows

AI assistants that read Slack threads, summarize Confluence docs, and create Jira tickets in one step
Customer support AI that queries CRM data and drafts personalized responses

DevOps & Infrastructure

AI that monitors logs, detects anomalies, and opens incident tickets automatically
Infrastructure management bots that interact with cloud provider APIs through MCP servers

A Simple MCP Server — Hands-On Example (C# / .NET)

The official ModelContextProtocol NuGet package brings full MCP support to .NET. The C# SDK follows familiar .NET patterns — dependency injection, hosted services, and attribute-based tool registration — making it feel natural for any .NET developer.

Step 1: Create the project and install the NuGet package

dotnet new console -n MyMcpServer
cd MyMcpServer
dotnet add package ModelContextProtocol
dotnet add package Microsoft.Extensions.Hosting

Step 2: Define your MCP Tool

Create a file WeatherTools.cs:

using ModelContextProtocol.Server;
using System.ComponentModel;
 
[McpServerToolType]
public class WeatherTools
{
    [McpServerTool]
    [Description("Get the current weather for a given city")]
    public static string GetWeather(
        [Description("The name of the city")] string city)
    {
        // In a real implementation, call a weather API here
        return $"Weather in {city}: 24°C, Sunny skies";
    }
}

Step 3: Configure and run the MCP server

Update Program.cs:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using ModelContextProtocol.Server;
 
var builder = Host.CreateApplicationBuilder(args);
 
builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()   // Communicate via stdio (JSON-RPC 2.0)
    .WithTools<WeatherTools>();   // Register our tool class
 
await builder.Build().RunAsync();

What's happening here:

[McpServerToolType] marks the class as a tool provider that the MCP server will discover automatically
[McpServerTool] + [Description(...)] decorates each method — the description is sent to the AI so it knows when and how to use the tool
.WithStdioServerTransport() sets up JSON-RPC 2.0 over stdio — the standard MCP transport layer
.WithTools<WeatherTools>() registers all tools in the class via dependency injection — no manual wiring needed

Step 4: Connect to Claude Desktop

Publish the project and register it in claude_desktop_config.json:

{
  "mcpServers": {
    "my-weather-server": {
      "command": "dotnet",
      "args": ["run", "--project", "C:/Projects/MyMcpServer"]
    }
  }
}

That's it. Claude Desktop will launch your .NET MCP server as a subprocess, discover the GetWeather tool automatically via JSON-RPC, and invoke it whenever a user asks a weather-related question.

Why C# / .NET is a great fit for MCP:

Attribute-based registration ([McpServerTool]) integrates naturally with the .NET ecosystem
Full async/await support for non-blocking tool execution
Dependency injection makes it easy to inject services like HttpClient, DbContext, or any custom repository into your tool classes
Works seamlessly with ASP.NET Core if you need HTTP-based MCP transport instead of stdio
Strong typing ensures tool input schemas are generated automatically from method signatures

Who Should Use MCP — And when?

Use MCP if you are:

A developer building AI-powered applications that need to interact with external services
A team wanting to give your internal AI assistant access to company tools (databases, Slack, Jira)
An engineer building agentic AI workflows that require multi-step tool use
A product team wanting reusable, maintainable AI integrations across multiple AI models

MCP may not be needed if:

You only need a single, simple API call with no future reuse plans
You are building a purely conversational AI with no need for external data
You are in an early prototype phase where any integration approach works

The Future of MCP

MCP is still in its early days, but the trajectory is clear. It is fast becoming the de facto standard for AI-tool integration, similar to how REST APIs standardized web service communication in the 2000s.

Key developments to watch:

Growing ecosystem: Hundreds of open-source MCP servers already exist for tools like PostgreSQL, Redis, GitHub, Slack, Notion, Google Drive, and more
Multi-model support: While created by Anthropic, MCP is model-agnostic — OpenAI, Google, and others are expected to adopt or align with it
Enterprise adoption: Organizations are building internal MCP server libraries to give their AI assistants secure, governed access to company data
Agentic AI pipelines: MCP is becoming the backbone of complex multi-agent workflows, where AI agents hand off tasks to each other through standardized tool calls
IDE integration: Tools like VS Code, Cursor, and JetBrains are embedding MCP support to enable AI pair-programming at a new level

Summary

MCP solves one of the most important limitations in practical AI deployment: the inability of AI models to interact with the real world in a standardized, secure, and maintainable way.

By providing a universal protocol for tool use, resource access, and prompt management, MCP transforms AI models from isolated reasoning engines into connected, capable agents that can take real action in real systems.

If you are building AI-powered applications today, MCP is not optional knowledge — it is foundational.