An LLM on its own can only produce text. To act — read a file, query an API, restart a service — it needs tools. The Model Context Protocol (MCP) is an open standard for connecting models to those tools and data sources in a consistent way. Together they turn a chatbot into a capable agent.

🎯 Learning Objectives

By the end of this lesson you will:

• Understand what “tools” mean for an AI model
• Follow how a model decides to call a tool
• Understand what MCP is and the problem it solves
• Know the client/server roles in MCP

What Is a Tool?

A tool is a function the model is allowed to call. You describe it — its name, what it does, and its inputs — and the model can choose to invoke it during its reasoning.

{
"name": "get_pod_logs",
"description": "Fetch recent logs for a Kubernetes pod",
"parameters": {
  "pod_name": "string",
  "lines": "number"
}
}

Given this description, the model can decide when to call get_pod_logs, with what arguments — and then reason over the result.

The Tool-Calling Flow

1. Model decides: "I need the logs for web-abc"
2. Model emits:   get_pod_logs(pod_name="web-abc", lines=50)
3. Your code runs the real function
4. Result returned to the model
5. Model reasons over the logs and responds

The crucial point: the model doesn’t run anything itself. It requests a tool call; your code executes it and returns the result. That boundary is where you enforce security and permissions.

The Problem MCP Solves

Before MCP, every AI app connected to every tool in its own custom way. Ten apps × ten tools meant a hundred bespoke integrations — brittle and duplicated.

MCP standardises this. Build an MCP server for a system once (say, a GitHub server or a Kubernetes server), and any MCP-compatible AI app can use it. It’s often described as “USB-C for AI” — one standard connector.

Without MCP:  every app ↔ every tool  (N × M custom integrations)

With MCP:     apps ─┐                 ┌─ tools
                  ├─ MCP standard ──┤
                  ┘                 └─

MCP Client and Server

MCP follows a simple client/server model:

An MCP server can offer three things:

• Tools — actions the model can call (e.g. create_issue).
• Resources — data the model can read (e.g. a file’s contents).
• Prompts — reusable prompt templates for common tasks.

🧪 Hands-on Lab

list_pods(namespace)          # read-only
get_pod_logs(pod, lines)      # read-only
restart_deployment(name)      # DESTRUCTIVE → require human approval

🧠 Knowledge Check

💼 Interview Preparation

Summary

You now understand how tools give a model the power to act, the request/execute safety boundary, and how MCP standardises connecting AI to real systems. Next, we bring it all together with practical, safe uses of agentic AI across DevOps.