MCP server that wraps lavacli (Linaro LAVA CLI)
Wellknown found it in public sources; nobody has proven control of it yet. Claiming takes one click if the repository is under your GitHub account, or a small file on your domain otherwise. Verified owners get the badge, 15-minute checks, status alerts, edits that outrank crawled data, and a ranking boost.
Agents can do it too: POST https://wellknown.network/api/v1/claims with {"agent":"mcp-lava","method":"well_known_file"} — machine-readable steps at claim.json, guide at /docs/claim.
Everything here was measured by our prober or read from a registry. Nothing is self-reported.
Attributed to the source that supplied each field. Treated as claims, not facts.
# mcp-lava `mcp-lava` is an **MCP (Model Context Protocol) server** that lets an LLM interact with a [Linaro LAVA](https://gitlab.com/lava/lava) by **wrapping** the official `lavacli` command-line tool. Instead of re-implementing LAVA's XML-RPC API, this server executes `lavacli` locally and returns results to the LLM in a tool-friendly way. ## Why an MCP server for LAVA? LAVA is powerful, but day-to-day workflows often involve many repetitive CLI steps: - checking device availability and health - locating the right job definition - submitting jobs and monitoring states - pulling logs and artifacts for failed jobs - correlating failures across multiple runs - re-running jobs to reproduce or to confirm a fix An LLM can help with these workflows **if** it can reliably call the right commands and parse the outputs. `mcp-lava` provides that bridge: - **Reuses `lavacli` subcommands and output formats** (many support `--json` / `--yaml`). - **Keeps server logic minimal** (no duplicated API client). - **Makes automation conversational**: "find the last failed run for this device type and summarize the failure", "show me the first kernel panic in the logs", etc. ## Example scenarios A few practical things you can do with an LLM + `mcp-lava`: 1. **Triage a failure quickly** - List recent jobs for a project - Detect failures, fetch logs, and summarize the suspected root cause - Extract the first occurrence of an error pattern (e.g. *kernel panic*, *timeout*, *SSH failed*) 2. **Lab status overview** - List devices and filter to offline/retired/busy - Show which workers are overloaded - Identify the most flaky device type based on recent job outcomes 3. **Job submission assistance** - Validate that a device type exists - Submit a job definition - Track the job until completion and then download artifacts 4. **Re-run / reproduce / confirm a fix ("rerun" workflow)** - Re-run the same job…
Mapped onto the structured taxonomy from declared text and observed tool names. Confidence shown for derived entries.
Every source is kept verbatim. Field changes are logged as events.