
Agentic AI for DevOps: From Suggesting Fixes to Actually Fixing Things
September 7, 2026Large Language Models (LLMs) have evolved from answering questions to performing real-world tasks: reading files, querying databases, interacting with GitHub, sending Slack messages, and much more. However, each of these services exposes its own APIs, authentication methods, and integration patterns, making AI applications increasingly complex to build and maintain.
The Model Context Protocol (MCP) addresses this challenge by providing a standardized way for AI applications to discover and interact with external tools. Instead of implementing a custom integration for every service, developers can build or connect to MCP-compatible servers that expose capabilities through a common protocol.
In this article, we’ll understand what MCP is, why it was introduced, how it works, and how you can build your own MCP server. We’ll also compare MCP before and after the July 28, 2026 specification update to understand how it has evolved.
Before MCP, AI applications connected to every service separately. If an AI assistant needed to access GitHub, PostgreSQL, Slack, or Google Drive, developers had to write and maintain a separate integration for each one.
Each service came with its own API, authentication method, request format, and documentation. As more tools were added, the application became harder to maintain and extend.
For example, imagine building an AI assistant that can:
- Read GitHub issues
- Fetch data from PostgreSQL
- Send a Slack message
Without MCP, each feature requires its own implementation. If you later want to support another service, such as Notion or Jira, you need to repeat the integration process again.
This approach works well for a few services, but it becomes difficult to manage as AI applications grow. Developers spend more time writing integrations than improving the AI experience itself.
This is the problem MCP was designed to solve—a common way for AI applications to communicate with different tools.
The Model Context Protocol (MCP) is an open standard introduced by Anthropic in collaboration with other leading GenAI labs that defines a common way for AI applications to communicate with external tools,services, and models.
Instead of creating a separate integration for every API, developers can connect their AI applications to MCP-compatible servers. This allows AI models to interact with different tools using the same communication standard, making integrations simpler and consistent.
At a high level, MCP follows a client-server architecture. The AI application sends requests through an MCP Client, which communicates with one or more MCP Servers. Each server provides capabilities that the AI can use, such as reading files, querying a database, calling an external API, etc.
The core components of MCP are:
- Host: The application where users interact with the AI, such as Claude Desktop or Cursor.
- Client: Acts as a bridge between the host and MCP servers.
- Server: Exposes capabilities to the AI.
- Tools: Functions that perform actions, like fetching GitHub issues or sending an email.
- Resources: Read-only information such as files, documents, or database schemas.
- Prompts: Reusable prompt templates that help guide AI interactions.
By separating these responsibilities, MCP makes it easier to build AI applications that can work with different tools without requiring custom integrations for each.
Let’s understand MCP with a simple example.
Suppose a user asks:
“Show me all open GitHub issues assigned to me.”
The AI understands the request, but it cannot directly access GitHub. Instead, it sends the request to an MCP Client, which checks the available MCP Servers for a suitable tool.
The GitHub MCP Server exposes a tool to fetch issues. The client invokes this tool, receives the response, and passes the result back to the AI. Finally, the AI presents the information to the user in a readable format.
This flow remains the same regardless of the service. Whether the AI is working with GitHub, PostgreSQL, Slack, or a local file system, it communicates through the same protocol instead of learning a different API for each integration.
How becoming stateless improved MCP as a standard
The July 28, 2026 specification introduced one of the biggest changes to MCP: it became stateless.
Before this update, every client had to establish a session with the server. Each request included a session identifier, which meant servers had to maintain session information. While this worked, it made scaling applications across multiple servers more difficult.
After the update, MCP no longer depends on sessions. Each request contains all the information needed to process it, allowing any server instance to handle the request independently. This makes MCP easier to deploy in cloud environments and improves scalability.
Now that we’ve understood the core concepts of MCP, let’s build a simple MCP server using the official SDK.
An MCP server exposes one or more tools that an AI application can discover and invoke.
Step 1: Install the official MCP Python SDK
Step 2: Create the MCP Server
This creates a new MCP server. At this point, it doesn’t expose any tools.
Step 3: Register a Tool
Let’s understand the important parts:
- Tool Name – A unique identifier that the client uses to discover the tool. (execute_action)
- Description – Helps the AI understand when the tool should be used.
- Input Schema – The MCP Python SDK generates the input schema from the function’s type hints.
- Handler – Contains your application’s business logic and returns the response.
Note:
The business logic can perform any operation, such as:
// Read a file
// Query a database
// Call an external REST API
// Execute an internal service
// Trigger a workflow
The MCP protocol doesn’t define what your tool does—it only standardizes how the AI discovers and calls it.
Step 4: Run the Server
Your MCP server is now ready to accept requests from any compatible MCP client.




