In the last few months, I’ve been working closely with the Model Context Protocol (MCP)—initially just to explore how it could integrate into our DevOps workflows. But what started as a curiosity turned into something more meaningful as I dove deeper into how the MCP server enables structured, intelligent, and context-aware model interactions.
This blog captures that learning journey and outlines the key features of MCP—specifically its architecture, how it manages memory, the concept of sampling, and how different clients interact with the protocol.
Whether you’re new to MCP or trying to evaluate how it might fit into your tech stack, I hope this serves as a helpful primer.
🌐 What is MCP?
At a high level, the Model Context Protocol is an open protocol for managing long-running, structured interactions between AI models, tools, memory, and users. It formalizes how a system should handle context, control flows, and decisions across different layers of an AI application.
Instead of treating each interaction as stateless (like traditional prompt-response systems), MCP introduces a way to:
- Maintain memory throughout sessions.
- Route tasks to the appropriate tools or models defined in respective MCP Servers
- Structure interactions using a shared, interpretable format
The result? A more context-aware, modular, and controllable AI system.
MCP Server: The Heart of the Protocol
The MCP server is the orchestrator of all interactions—it routes messages, manages memory, invokes models, and handles tool calls. Think of it as a central brain that:
- Accepts requests from various clients
- Retrieves memory and context
- Applies sampling logic to choose the right model/tool
- Sends the output back to the client
- Optionally updates long-term memory
This helps in providing a fine-grained control over how and when the LLM model sees certain information, and how it should act in response.
Tools
One of the most powerful features in the Model Context Protocol (MCP) is its support for tools. Tools allow the model to go beyond just generating natural language—they enable it to take actions, fetch data, or interact with external systems programmatically.
If you’ve ever seen an AI assistant that can query a database, summarize a report, create monitors or alerts, or open a JIRA ticket—that’s usually happening through tool calls behind the scenes.
Let’s dive deeper into what tools are in MCP, how they work, and why they’re essential for building truly useful AI systems.
How Tools Fit into the MCP Flow?
Key features of tools in MCP include:
- Tool Discovery
- Clients that acts as a User-Interface retrieve a list of available tools by making a
tools/listrequest. - This enables the LLM to understand which capabilities it can access in the current session and what actions can be performed.
- Clients that acts as a User-Interface retrieve a list of available tools by making a
{
"tools": [
{
"name": "querySQLDatabase",
"description": "Execute a SQL query on a specified database and return the results.",
"parameters": {
"database": {
"type": "string",
"description": "The name or identifier of the target database."
},
"sql_query": {
"type": "string",
"description": "The SQL query to execute."
}
}
},
{
"name": "summarizeIncident",
"description": "Summarize an incident based on incident ID and historical context.",
"parameters": {
"incident_id": {
"type": "string",
"description": "Unique identifier of the incident."
}
}
},
{
"name": "createJiraTicket",
"description": "Create a Jira ticket for an incident or request.",
"parameters": {
"title": {
"type": "string",
"description": "Title of the Jira issue."
},
"description": {
"type": "string",
"description": "Detailed description of the issue."
},
"project_key": {
"type": "string",
"description": "Jira project key (e.g., 'DEVOPS')."
},
"issue_type": {
"type": "string",
"description": "Type of the issue (e.g., 'Bug', 'Task')."
}
}
}
]
}- Tool Invocation
- Tools are executed using a
tools/callrequest. This request includes the tool’s name and its parameters selected by LLM. - Upon receiving it, the server performs the corresponding action—whether it’s querying a database, calling an external API, or running a diagnostic check—and returns the result in a structured format.
- What This Means for the Model, When this tool list is provided to an LLM:
- It now knows which actions are available.
- It understands the inputs required for each tool.
- It can now generate structured tool calls like:
- Tools are executed using a
{
"tool_call": {
"name": "querySQLDatabase",
"arguments": {
"database": "customer_db",
"sql_query": "SELECT customer_id, last_login, subscription_status FROM users WHERE subscription_status = 'active' ORDER BY last_login DESC LIMIT 10;"
}
}
}
- Flexible and Extensible Design
- Tools in MCP are highly flexible. They can range from basic operations like math functions or string formatting to complex integrations with third-party systems (e.g., observability platforms, ticketing systems, or infrastructure control).
- These tools are purely guided via the descriptions added for them as it plays a very vital role for LLMs to undertsand the purpose.
Each tool is uniquely identified by its name and often includes metadata such as a description and input schema to guide its usage. While resources in MCP represent static or retrievable data, tools differ in that they represent executable logic—capable of modifying state, triggering workflows, or interacting with external systems in real time.
This tool framework is what enables LLMs to move from “just reasoning” to action-oriented behavior, creating intelligent, responsive systems that can operate in real-world enterprise environments.
Prompts
A prompt is the input you give to a language model (like GPT, Claude, etc.) to get a specific kind of output. It’s the way you “ask” the model to do something—whether it’s answering a question, writing code, summarizing data, or simulating a conversation.
Think of a prompt as a set of instructions or context that guides how the model responds.
Prompt = Instruction + Context + Example (Optional)
A good prompt usually includes:
- Instruction: What you want the model to do.
Example: “Summarize this article in bullet points.” - Context: Background or data the model needs.
Example: The actual article text. - Examples: (Optional) Demonstrations of the format/output you expect.
Example: “Input: [Text] → Output: [Summary]”
Sampling in MCP — What It Really Means (and When It Finally Made Sense)
Honestly, it took me a bit of time to truly understand what “sampling” in MCP actually meant. Initially, the term felt abstract — almost too model-centric — and didn’t immediately click with how we were trying to build real-world LLM workflows. But things started to make sense when we ran into practical issues, especially with token limits and model decision-making.
We were building observability assistants using MCP, integrating with tools like NewRelic, Prometheus and started seeing scenarios where we needed the model to:
- Choose whether to use a tool or not,
- Avoid overflowing the model with unnecessary tool definitions,
- Or just respond directly when memory already had the answer.
That’s when we started digging deeper into sampling blocks in MCP.
⚠️ Why Sampling Really Started to Matter: Token Limits
Once we started querying huge data for larger timeframes, we realized that returning all the data at once was bloating the token usage of LLM Models — sometimes breaking context windows or making the model slower and less accurate.
That’s when we appreciated sampling even more. Using it smartly meant:
Avoid memory overload and keep the flow efficient.
List only relevant tools, based on prior sampling decisions.
Let the model decide incrementally (e.g., list tools → choose → execute → return result → next sample → combine all the sampled results ).
✨ Why This Matters
As AI systems become more embedded into enterprise workflows, stateless models just aren’t enough. We need systems that:
- Remember
- Act intelligently
- Interact with real tools
- Respect structured context
MCP gives us a framework for that.
🧩 Wrapping Up
This blog covers the foundational components of the MCP server:
- How clients initiate and manage scoped sessions
- How sampling routes requests to the best model or tool
- How memory makes the system truly context-aware
- And how tools extend the model’s capabilities
The MCP server is more than a model wrapper—it’s a context engine that transforms isolated model calls into meaningful, memory-rich conversations. As enterprise AI adoption grows, such protocols will be key to unlocking smarter, more reliable, and secure AI-driven systems.
If you’re exploring the next step in operationalizing AI in observability or DevOps, integrating an MCP-like architecture could be a game-changer.
I’m a DevOps Engineer with 3 years of experience, passionate about building scalable and automated infrastructure. I write about Kubernetes, cloud automation, cost optimization, and DevOps tooling, aiming to simplify complex concepts with real-world insights. Outside of work, I enjoy exploring new DevOps tools, reading tech blogs, and play badminton.
Subscribe to our Newsletter
Please susbscribe
