OpsVoice

Ask Alexa+ about builds, deployments, and cluster health. An MCP server that diagnoses failures and runs multi-step fixes, confirming with you before anything risky.

Comment

Inspiration

When a deployment breaks, the first few minutes go to juggling a terminal, a pipeline dashboard and cluster logs just to answer "what happened?" I'm a CS student who has worked with Kubernetes, CI/CD and Terraform through Google Cloud labs, and I wanted to see whether the "what just broke?" part could be handled by voice, so the engineer can concentrate on the fix.

What it does

OpsVoice is an MCP server that exposes DevOps tools to a voice assistant. You can ask:

  • "What's the status of payments-api?"
  • "Why is auth-service failing?"
  • "Roll it back."

Five tools are available: list_services, pipeline_status, diagnose, propose_rollback and confirm_rollback.

  • Short, speakable answers. Responses are written as one or two plain sentences, not log dumps.
  • Conversation memory. After you mention a service once, follow-ups like "why is it failing?" use it automatically.
  • Safe rollbacks. A rollback is two steps. propose_rollback only plans and changes nothing, then returns a short code. confirm_rollback runs it. Codes are single-use and expire after 2 minutes, so a misheard request can't trigger a deploy.

How I built it

  • Python MCP server using the official mcp SDK, served over Streamable HTTP at /mcp
  • A core logic layer with no MCP dependency, covered by 6 unit tests
  • A provider interface, so the simulated backend can be swapped for GitHub Actions or Kubernetes
  • Docker support, and an MIT-licensed open-source repo
  • I exposed the local server through a Cloudflare tunnel to test it from a public HTTPS URL

[CHOOSE ONE]

  • A: I registered the server as an Alexa+ add-on using the Alexa AI CLI.
  • B: I did not complete Alexa+ add-on registration in time. The server is built to the Alexa+ MCP requirements (Streamable HTTP, remote URL) and is tested with a standard MCP client.

Challenges

  • SDK version break. A fresh install pulled mcp 2.x, which broke my code written for 1.x. I pinned mcp<2.
  • Designing for voice. Tool output has to be short and unambiguous, and anything risky has to be confirmed, because you can't scroll back through speech.
  • Remote access. Alexa+ needs a public HTTPS endpoint, not localhost, so I had to learn how to expose a local server safely for testing.

What I learned

  • How MCP tools, sessions and Streamable HTTP work end to end
  • That voice tools need confirmation steps for any action that changes state
  • Keeping logic separate from the protocol layer makes testing much easier

Current limitations (honest status)

  • Data is simulated: three fake services, with no real GitHub Actions or Kubernetes connection yet
  • Diagnosis is rule-based keyword matching, not an AI model
  • State is in memory and shared by all callers, so it's a single-user demo

What's next

  • Real providers for GitHub Actions and Kubernetes
  • An LLM-based diagnosis layer for messier logs
  • Per-user sessions and permissions

Built With

Share this project:

Updates

Submission history