Platform engineering has multiple objectives: standardization, automation, compliance, governance, but there’s one dimension that often gets lost in the architecture diagrams and control planes: developer ownership and DevOps culture.
At Qubika, as we evolve toward AI-native solutions, we’re seeing how Model Context Protocol (MCP) servers address this specific challenge in a way that traditional platform tools don’t. This isn’t about replacing your developer portal or infrastructure control plane, it’s about recognizing that fostering ownership requires lowering friction for low-complexity operational tasks.
The culture problem: ownership vs. tooling overhead
Platform engineering excels at standardization, scalability, automation, and security. But there’s a cultural gap that tooling alone hasn’t solved: how do we make developers truly feel ownership of their production systems without overwhelming them with operational complexity?
The reality is that most operational tasks are low-complexity:
- Check pod status in a namespace
- View recent logs for a service
- Restart a deployment
- Check resource consumption
- Correlate metrics across tools
These shouldn’t require:
- Opening a developer portal
- Navigating through multiple clicks
- Finding the right dashboard
- Remembering which tool shows what metric
- Context-switching between 3-4 different UIs
This friction kills ownership. When troubleshooting takes hours instead of minutes, developers fall back to opening tickets. The cultural shift toward DevOps stalls.
MCP servers: A common language for infrastructure
Model Context Protocol servers provide something fundamentally different from traditional platform tools: a conversational interface with a common language for interacting with infrastructure.
Instead of training developers on Backstage navigation, Datadog query syntax, and Kubernetes dashboard layouts, they simply ask:
“Why is the checkout service slow in production?”
The MCP server, connected to your infrastructure:
- Checks pod status in your EKS cluster
- Pulls recent error logs from CloudWatch
- Correlates with APM metrics from Datadog
- Identifies the root cause
All through natural language. No context switching. No remembering which dashboard shows what.
What this means for DevOps culture
- Ownership becomes natural, not forced. When developers can troubleshoot their own services without friction, they want to take ownership. The barrier isn’t capability—it’s cognitive overhead.
- The feedback loop tightens. Going from “something’s wrong” to “I see the problem” takes seconds, not minutes. This changes behavior. Developers start investigating issues proactively instead of reactively.
- Knowledge becomes democratized. Junior developers don’t need to memorize kubectl commands or Grafana query syntax. They ask questions in plain language and learn by seeing the results.
The right tool for the right goal
This is where clarity matters. MCP servers are not the right solution for platform engineering goals like standardization and governance, but for the specific goal of fostering developer ownership and DevOps culture through low-friction operational interactions, MCP servers are uniquely effective:
- Daily troubleshooting – Natural language beats clicking through dashboards
- Quick operational tasks – “Restart the auth service” is faster than portal → cluster → namespace → deployment → actions → restart
- Cross-tool correlation – AI can pull data from Kubernetes + logs + metrics + traces in one conversation
- Learning by doing – Developers see the actual commands and queries being executed
Security and guardrails
One concern: “Won’t this give developers too much access?”
Not if implemented correctly. MCP servers can enforce the same RBAC and policies as your existing tools:
- Read-only by default – Start with viewing logs, status, metrics
- Role-based permissions – MCP server checks user’s IAM/AD groups before executing commands
- Audit logging – Every MCP interaction is logged, just like portal actions
- Gradual expansion – Add write operations (restart, scale) only after read operations are stable
The goal isn’t unrestricted access, it’s removing friction for authorized operations.
How we’re building this at Qubika
Our Cloud Bootstrapper already automates infrastructure provisioning in Azure and AWS. But after provisioning, developers still needed AWS Console access or Terraform knowledge for routine operations, creating friction and dependency on the Cloud and SRE team.
The solution: An MCP server that exposes operational capabilities through natural language, with zero-configuration experience.
When Terraform provisions an environment, it generates a JSON config file with all metadata (cluster names, log groups, service code names). The SRE team provides this to developers, who immediately start interacting through their AI IDE—no setup required.
Instead of this:
- Open AWS Console
- Navigate to ECS → find cluster → Services
- Click service → Tasks → find task
- View logs → wait for CloudWatch
- Set filters → search
Developers ask:
“Show me errors in the last hour from production”
“What’s the current CPU usage?”
“Restart staging”
Early impact:
- Troubleshooting: 30-40 minutes → 30 seconds
- Developers proactively investigate vs. opening tickets
- SRE team focuses on platform evolution, not routine tickets
This is ownership-through-reduced-friction in action.
Getting started: A cultural shift, not just technical
If your platform engineering goals include fostering DevOps culture and developer ownership:
- Identify high-friction, low-complexity workflows – What are developers asking ops teams to do that they could do themselves?
- Start with read-only MCP capabilities – Logs, status checks, metrics queries
- Measure cultural impact, not just metrics – Are developers troubleshooting their own issues? Are ops tickets decreasing for routine tasks?
- Keep your developer portal for its strengths – Service catalog, provisioning workflows, governance dashboards
- Use MCP for daily operations – The 80% of routine tasks that don’t need visual workflows
- Iterate based on developer feedback – Which conversations feel natural? Which still need portal workflows?
Conclusion: Culture through code
The hardest part of DevOps isn’t the technology—it’s the culture. You can implement perfect CI/CD pipelines, comprehensive monitoring, and self-service platforms, but if developers don’t feel ownership of production systems, the culture doesn’t shift.
MCP servers don’t replace your platform engineering tools. They complement them by addressing a specific, critical gap: making operational ownership feel natural instead of burdensome.
When a developer can solve their own production issue in 30 seconds through a conversation instead of 10 minutes through portal navigation, something changes. They stop seeing operations as “someone else’s problem.” They start seeing their service holistically—code and infrastructure together.
That’s the culture shift platform engineering aims for. MCP servers make it accessible.
