{"slug":"mcp-plain-terms","title":"MCP in Plain Terms: What Changes When the Agent Grows Up","description":"AI agents now search, chain, and summarize on their own. Here's what that means for DevOps, CloudOps, and SecOps teams building MCP tools.","date":"2025-09-13","author":"Elaph Hilful","thumbnail":"/placeholder.svg","tags":["MCP","AI Agents","DevOps","Platform Engineering","Automation","SecOps"],"category":"Platform Engineering","featured":true,"readTime":5,"htmlContent":"

The agent grew up. Our servers should too.

\n

MCP is how AI agents plug into our systems. What changed this year is simple: the agent now does more of the work itself, so what we build on our side has to change.

\n

The Shift: From Hand-Holding to Self-Service

\n
graph LR\n subgraph Before[\"Before: Hand Everything Over\"]\n A1[Agent] --> B1[All Tools Loaded]\n B1 --> C1[Manual Chaining]\n C1 --> D1[Full Output Dump]\n end\n\n subgraph After[\"After: Agent Fetches What It Needs\"]\n A2[Agent] --> B2[Search for Tool]\n B2 --> C2[Auto-Chain Calls]\n C2 --> D2[Summary Only]\n end\n
\n

The agent used to be handed everything at once. Now it fetches what it needs and chains the calls itself.

\n

What the Agent Now Does Itself

\n\n

What's Left to Us

\n\n

The point: don't just expose every API call as a tool. Offer the common jobs as single tools, the way an SDK offers shortcut methods. That's where the value is now.

\n

What This Means for Ops Teams

\n

DevOps, CloudOps, SecOps, SaaSOps — most of our work is already a fixed sequence of steps across several systems. That's exactly what should become a single tool.

\n
graph TD\n subgraph Tool[\"One Tool: triage_service\"]\n A[Agent calls triage_service] --> B[Pull recent deploys]\n B --> C[Fetch error logs]\n C --> D[Gather traces]\n D --> E[Check alerts]\n E --> F[Container health]\n F --> G[Return summary]\n end\n
\n

A runbook turned into one tool call. The steps and the order live in the tool, not in the agent's head.

\n

The Tool Catalog

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
TeamToolWhat It Does Behind the Scenes
DevOpstriage_servicePulls recent deploys, errors, traces, alerts and container health — returns one summary
DevOpspromote_releaseChecks the pipeline, ships the new version, watches health, rolls back if it fails
CloudOpsfind_cost_hotspotsCost data, untagged resources and idle capacity, mapped to the team that owns them
SecOpsreview_accessShows a role, its permissions, when they were last used, and what looks unusual
SecOpscollect_audit_evidenceGathers config snapshots, log retention proof and approvals for one control
SaaSOpsoffboard_personDisables the account, kills sessions and reclaims paid seats across every SaaS app
\n

Why This Is Safer, Not Riskier

\n

The correct order lives in the tool, so the agent cannot invent its own version of a runbook. Fewer half-finished changes, and a clean record of who ran what.

\n

How to Start, Safely

\n

Start with things that cannot break anything, then earn the right to add the ones that can.

\n
graph LR\n A[Read-Only Tools] -->|Build trust| B[Permission Tools]\n B -->|Prove safety| C[Change Tools]\n\n A1[\"list_services<br>get_logs<br>show_metrics\"] --> A\n B1[\"review_access<br>audit_config<br>check_compliance\"] --> B\n C1[\"promote_release<br>offboard_person<br>scale_service\"] --> C\n
\n

Read-only first, permissions next, changes last.

\n

Rules for Every Tool We Ship

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RuleWhy
Safe to run twiceAgents retry. Running a tool again must not create a second thing.
Show before you changeA preview call lists what would change. Approval is a separate step.
Short answersReturn a summary, not a huge dump. Big outputs get truncated or ignored.
Clear failuresSay which step failed and what is safe to do next.
Narrow permissionsOne set of permissions per group of tools, not one key for everything.
Logged and redactedRecord who called what. Strip secrets and patient data at the edge.
\n

Idempotency Example

\n
# Bad: Creates duplicate on retry\ndef create_user(name: str) -> dict:\n    return db.insert({\"name\": name})\n\n# Good: Safe to run twice\ndef ensure_user(name: str) -> dict:\n    existing = db.find_one({\"name\": name})\n    if existing:\n        return {\"status\": \"exists\", \"user\": existing}\n    return {\"status\": \"created\", \"user\": db.insert({\"name\": name})}\n
\n

Preview-Before-Change Pattern

\n
def promote_release(service: str, version: str, preview: bool = True) -> dict:\n    changes = calculate_changes(service, version)\n\n    if preview:\n        return {\n            \"action\": \"preview\",\n            \"would_update\": changes[\"pods\"],\n            \"rollback_available\": True\n        }\n\n    # Actual promotion requires explicit preview=False\n    return execute_promotion(service, version)\n
\n

The Architecture

\n
flowchart TD\n Agent[AI Agent] --> MCP[MCP Gateway]\n MCP --> Auth{Auth & Permissions}\n Auth -->|Allowed| Router[Tool Router]\n Auth -->|Denied| Reject[Reject + Log]\n\n Router --> DevOps[DevOps Tools]\n Router --> CloudOps[CloudOps Tools]\n Router --> SecOps[SecOps Tools]\n\n DevOps --> K8s[Kubernetes]\n DevOps --> CI[CI/CD Pipeline]\n CloudOps --> AWS[AWS/Azure/GCP]\n SecOps --> IAM[IAM Systems]\n SecOps --> SIEM[SIEM/Logs]\n\n subgraph Audit\n Log[Audit Log]\n Redact[PII Redaction]\n end\n\n Router --> Audit\n
\n

The Takeaway

\n

Let the agent handle finding and chaining tools. We decide:

\n
    \n
  1. Which jobs exist — the runbooks worth automating
    2. \n
  2. What they cost to run — rate limits, approval gates, resource bounds
    3. \n
  3. Who is allowed to run them — RBAC at the tool level, not the API level
    4. \n
\n

The agent got smarter. Our job isn't to give it more power — it's to give it the right power, safely packaged, clearly named, and properly logged.

\n

Resources

\n"}