VoiceOps Voice SRE Agent
Talk to your Kubernetes cluster: a LiveKit voice agent that calls MCP and A2A tools for SRE work.
- Source repo
- den-vasyliev/voice-mcp-agent
- Stars
- ★ 71
- Last updated
- 1y ago
- License
- MIT
- Primary language
- Python
- FA score
- 36/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesOpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An on-call SRE with hands busy wants to ask aloud for the pods or recent events in a namespace
- Not a fit if
- Teams that cannot send audio or prompts to OpenAI and ElevenLabs cloud APIs
- Users who need stdio/subprocess MCP servers — only HTTP/SSE servers are supported today
- Environments without Node.js/npx or any reachable MCP server endpoint
- Source review
- 36/100 · Major gaps 2 safety controls not found
What does this agent do, and when should you use it?
VoiceOps is a conversational voice assistant built on the LiveKit Agents framework, aimed at SRE and Kubernetes operations. Speech is transcribed by OpenAI Whisper, reasoned over by GPT-4o, spoken back through ElevenLabs, and gated by Silero voice activity detection. What makes it an agent rather than a chatbot is tool use: it reads server definitions from mcp_servers.yaml, connects to external services over HTTP/SSE via the mcp_client package, and can optionally attach A2A agents whose skills are discovered from /.well-known/agent.json and registered as callable tools. The entry point is main.py, orchestration lives in agent_core.py with tool wiring in tool_integration.py and a2a.py, and it runs as a local Python process that joins a LiveKit room. It is explicitly scoped to non-production experimentation, since it can modify and delete real cluster resources.
On start, the agent joins a LiveKit room and listens; Silero detects speech, Whisper transcribes, and GPT-4o decides whether to answer or call a tool. Tools come from mcp_servers.yaml: standard MCP servers are reached over SSE through sse_client.py, and allowed_tools accepts wildcards such as list_*, describe_*, get_*. For servers requiring authentication, auth.py signs each request with HMAC-SHA256 using a key read from the env_var named in the config, adding it as an auth parameter. Entries marked type: a2a are handled by a2a.py, which discovers skills from /.well-known/agent.json, exposes each as a tool, and forwards optional custom headers. Tool results return to the model, whose answer is synthesized by ElevenLabs. The README ships runnable examples: mcp-server-kubernetes in non-destructive mode and kubectl-ai bridged via Supergateway.
- An on-call SRE with hands busy wants to ask aloud for the pods or recent events in a namespace
- A platform engineer rehearses scaling a Deployment or pulling a Job's logs by voice in a sandbox cluster
- A team already running Kagent in Kubernetes registers its A2A endpoint and drives diagnosis by speech
- An operator wants several MCP servers (Kubernetes plus custom tooling) behind one voice interface with per-tool allowlists
- A developer evaluating MCP and A2A tool orchestration without building a UI first
How do you install or deploy this agent?
You need Python 3.9+, OpenAI and ElevenLabs API keys, and at least one HTTP/SSE MCP server endpoint; the sample server below also needs Node.js/npx.
make venv
source venv/bin/activate
make uv # optional, faster installs
make installSet credentials:
export OPENAI_API_KEY=your_openai_api_key
export ELEVEN_API_KEY=your_elevenlabs_api_keyOptionally start the sample Kubernetes MCP server restricted to non-destructive tools:
ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS=true ENABLE_UNSAFE_SSE_TRANSPORT=1 PORT=8092 npx mcp-server-kubernetesHow do you use this agent?
Edit mcp_servers.yaml in the project root to declare MCP servers and tool allowlists:
servers:
- name: k8s-mcp-server
url: http://localhost:8092/sse
allowed_tools:
- list_*
- describe_*
- get_*Servers that need authentication take an auth block:
servers:
- name: secure-mcp-server
url: https://example.com/sse
allowed_tools: [*_*]
auth:
type: secret_key
env_var: MY_SECRET_KEYAttach an A2A agent:
servers:
- name: my-a2a-agent
type: a2a
url: https://my-a2a-agent.example.com
headers:
Authorization: Bearer <token>Run tests and start the agent:
make test
make runSay hello, then try prompts such as "list pods in dev namespace".
What are this agent's strengths and limitations?
- The full voice path is already wired: Silero VAD, Whisper transcription, GPT-4o reasoning, ElevenLabs speech
- Tool configuration is genuinely flexible — multiple servers, wildcard allowlists, HMAC-SHA256 auth, and A2A skill discovery
- Builds on LiveKit Agents, so real-time room audio transport comes from an established framework
- Reproducible examples are included for both mcp-server-kubernetes in read-only mode and Supergateway-bridged kubectl-ai
- MIT licensed with unit tests (test_agent_config.py, make test) shipped in the repo
- Only HTTP/SSE MCP servers work today; stdio/NPX subprocess servers are unsupported and need a Supergateway bridge
- Model and speech providers are fixed to OpenAI and ElevenLabs paid APIs, with no documented local or alternative path
- Tools can create, modify and delete real Kubernetes resources; the README itself warns to tighten permissions and test safely first
- Setup is multi-step: npx/Node.js plus at least one reachable MCP endpoint are prerequisites
- Some details are thin — LiveKit room/credential wiring and the exact mapping of environment variables are not fully spelled out
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| VoiceOps Voice SRE Agent This agent | 36 · Major gaps | CLIFree + model costs | ★ 71 | 1y ago | Python | OpenAI API |
| Hector Agent Runtime | 55 · Major gaps | CLIFree + model costs | ★ 60 | 5mo ago | Go | OpenAI API · Claude API |
| Moltis Personal Agent Server | 53 · Major gaps | Self-hosted serviceFree + model costs | ★ 2.9k | 1d ago | Rust | Codex · Claude Code |
| Cordum Agent Control Plane | 64 · Some gaps | Self-hosted serviceFree | ★ 511 | 2d ago | Go | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README explicitly warns the agent can create, modify, and delete Kubernetes resources and offers an allowed_tools wildcard allowlist plus an ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS example, so least-privilege has a thin design (score 1); however the allowlist is optional and not enforced by default, and examples show broad grants like allowed_tools: [*_*] and [*]. No pre-execution user confirmation mechanism exists (user_confirmation 0). Data flow only describes connecting to a LiveKit room and external MCP/A2A services, without explaining how voice and tool data reach OpenAI/ElevenLabs (score 1). Sensitive data handling mentions env-var secrets and HMAC signing but no log redaction or key rotation (score 1). Dependencies use loose ~= pins with mcp exact-pinned, but no lockfile or vulnerability scanning (score 1). External effects (delete/scale) have no rollback or dry-run (rollback 0). Source attribution only acknowledges LiveKit/OpenAI etc., not code provenance (score 1).
README and requirements are broadly consistent, but README references a2a.py and mcp_client files whose contents are not provided, so implementation-doc consistency cannot be checked (self_consistency 1). Dependencies are public PyPI packages, but a2a-min is obscure and versions are unpinned, adding availability uncertainty (score 1). Troubleshooting covers SSL and schema errors but not tool-call failures or MCP disconnects surfaced to the user (failure_messages 1).
README defines SRE/Kubernetes scenarios, sample prompts, and a Kagent integration path, so audience and scenarios are clear (score 2). It explicitly states only HTTP/SSE MCP is supported and NPX/subprocess is not yet supported, documenting capability boundaries (score 2). Trigger precision relies only on natural language plus wildcard allowlists, with no disambiguation or destructive-action detection described (score 1). Environment fit gives macOS/Linux/Windows Node install tips, but Python 3.9+ compatibility with livekit-agents 1.0 is unverified (score 1).
README has a table of contents, project structure, configuration, and testing sections, giving good information architecture (score 2). Quick Start and Makefile targets are clear (score 2). Naming is inconsistent: repo voice-mcp-agent vs README title VoiceOps vs clone example voice-mcp (naming_stability 1). Sample prompts and troubleshooting/FAQ are reasonably rich (score 2). Known limitations only mention MCP transport, not security/operational limits (score 1). LICENSE is full MIT (score 2). No version number or CHANGELOG (0). Maintenance responsibility points only to the author and contribution flow, with no release/update path (score 1).
Output usability offers voice interaction and sample prompts but no actual output samples or result formats (score 1). Marginal value comes from combining voice with MCP/A2A tools for K8s ops, which is somewhat differentiated, but many similar projects exist and implementation details are not shown (score 1). Cost-benefit involves multiple paid APIs (OpenAI GPT-4o, Whisper, ElevenLabs) plus destructive risk to production clusters, with no quantification of benefit versus cost/risk (score 1).
README claims (HMAC auth, A2A discovery) cannot be cross-checked against the provided files and trace only to README itself (claim_traceability 1). Evidence is limited to README, LICENSE, and requirements, with no code or tests, so cross-source corroboration is weak (score 1). README mixes facts with inference (e.g., 'Vibe Coding' spirit, future NPX support) without clear separation (score 1).
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- The agent can create, modify, and delete resources on real Kubernetes clusters, and least-privilege allowlists are not enforced by default; examples show broad grants like [*_*], so tighten allowed_tools and validate in a safe environment before production use.
- There is no pre-execution user confirmation and no rollback or dry-run, so destructive actions are hard to recover from once triggered.
- Voice and tool data flow to third parties such as OpenAI and ElevenLabs, but the README does not describe data flow or retention; assess compliance yourself.
- Dependencies use loose version constraints and include the obscure a2a-min, with no lockfile or vulnerability scanning; verify supply-chain risk independently.
- Repo name, README title, and clone example are inconsistent, and there is no version number or CHANGELOG, making upgrades and change tracking difficult.
- Publisher identity is unverified by the FollowAgents registry and maintenance/update paths are unclear; confirm maintenance activity before adoption.