lava-mcp
This server provides an MCP interface to a LAVA (Linaro Automated Validation Architecture) instance, allowing AI agents to query the board farm, manage test jobs, and interact with hardware test infrastructure.
Observation & Discovery
whoami/version— Identify the authenticated user and LAVA server versionlist_devices/get_device— List or inspect devices with filters by type, health, or stateget_device_dictionary— Get a device's rendered Jinja2/YAML configurationget_qdl_info— Summarize QDL/flash capabilities (useful for Qualcomm boards)list_device_types/list_workers— List device types and dispatcher workers
Job Monitoring
list_jobs/get_job— List or inspect test jobs with filters (state, health, submitter, device type)get_job_definition— Retrieve the original YAML job definitionget_job_logs— Fetch job logs with optional line range filteringget_job_results— Get test-case pass/fail resultsget_queue/get_running/get_lab_health— View queue, running job counts, and overall lab health
Job Management (Write Operations)
validate_job— Validate a YAML job definition without submittingsubmit_job— Submit a job and receive new job ID(s)cancel_job/resubmit_job— Cancel or resubmit jobsset_job_priority— Adjust a job's queue priority (0–100)
Additional Features
Read-only mode: Disable write operations for safe observation (
--read-only)Credential flexibility: Supports per-request HTTP header auth (multi-user) or environment-based auth
Flexible transport: Runs over stdio or streamable HTTP, with optional HTTPS via Caddy
SSH gateway: In hosted mode, enables an SSH rendezvous for board sessions without inbound worker access
Interactive board sessions (hosted mode): Open sessions to boards, run commands (e.g., fastboot, adb), and close sessions
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@lava-mcp list devices available in the board farm"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
lava-mcp has moved
This repository has moved to https://github.com/lava-mcp/lava-mcp
Please update your remotes, bookmarks, and issue links:
git remote set-url origin git@github.com:lava-mcp/lava-mcp.gitAll history, issues, and ongoing development live at the new location.
Available Tools
21 toolscancel_jobB
Request cancellation of a running or queued job.
Inputs: job_id (required).
get_deviceB
Get the full record for one device by hostname.
Inputs: hostname (required).
get_device_dictionaryC
Get a device's rendered configuration dictionary (Jinja2/YAML text).
Inputs: hostname (required). Returns: result
get_jobA
Get the full record (state, health, device, times) for one job.
Inputs: job_id (required).
get_job_definitionA
Get the original submitted YAML job definition for a job.
Inputs: job_id (required). Returns: result
get_job_logsA
Get a job's logs (YAML). Optionally limit to the [start, end) line range.
Inputs: job_id (required), start, end. Returns: result
get_job_resultsC
Get a job's test-case results (pass/fail per case).
Inputs: job_id (required), limit.
get_lab_healthB
Get per-device health across the lab.
Inputs: no named parameters.
get_qdl_infoA
Summarise a device's QDL/flash capability (qdl/fastboot deploy + boot params).
Useful before flashing a Qualcomm board: reports whether the device supports qdl, the qdl deploy/boot method parameters, and all available deploy/boot methods, derived from the device's rendered configuration.
Inputs: hostname (required).
get_queueB
Get the queue of submitted jobs waiting for a device.
Inputs: no named parameters.
get_runningB
Get per-device-type running/reserved counts.
Inputs: no named parameters.
list_devicesA
List devices, optionally filtered by device_type, health or state.
Returns {count, results}. health is e.g. Good/Bad/Maintenance/Unknown; state is Idle/Reserved/Running.
Inputs: device_type, health, state, limit.
list_device_typesC
List the device types known to this LAVA instance.
Inputs: limit.
list_jobsB
List test jobs, newest first, with optional filters.
state is e.g. Submitted/Scheduling/Scheduled/Running/Canceling/Finished; health is Unknown/Complete/Incomplete/Canceled.
Inputs: state, health, submitter, device_type, +1 more.
list_workersA
List the dispatcher workers and their health/state.
Inputs: no named parameters.
resubmit_jobC
Resubmit a finished job with the same definition.
Inputs: job_id (required).
set_job_priorityB
Set a job's queue priority (0-100, higher runs sooner).
Inputs: job_id (required), priority (required).
submit_jobC
Submit a YAML job definition. Returns the new job id(s).
Inputs: definition (required).
validate_jobB
Validate a YAML job definition without submitting it.
Inputs: definition (required).
versionA
Return the version of the connected LAVA server.
Inputs: no named parameters.
whoamiA
Return the LAVA user your token authenticates as.
Inputs: no named parameters.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 21 tools
Each tool targets a distinct resource or action: device queries (get_device, get_device_dictionary, get_qdl_info) are clearly separated from job operations (submit, cancel, resubmit, set_priority, validate) and listings (list_devices, list_jobs, etc.). No two tools appear to overlap in purpose.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_device, submit_job, list_devices). There are no deviations or mixed conventions.
With 21 tools, the count falls in the 'borderline heavy' range (16-25). While each tool appears necessary, the set could potentially be trimmed by combining some closely related functions, but overall it remains functional.
The tool set covers core LAVA workflows: device inspection, job lifecycle (submit, validate, resubmit, cancel, priority), queue/worker status, and lab health. Minor gaps exist (e.g., no device CRUD, no test definition management), but the essential user-facing operations are present.
Maintenance
Related MCP Connectors
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP Server for an Agent Task Marketplace
MCP server for Appcircle mobile CI/CD platform.
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that enables LLMs to interact with Agent-to-Agent (A2A) protocol compatible agents, allowing for sending messages, tracking tasks, and receiving streaming responses.528MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that exposes Language Server Protocol features to external clients, allowing access to hover information, definitions, completions, references, and rename functionalities.6 npm43MIT
- AlicenseAqualityFmaintenanceAn MCP server that acts as a proxy to connect MCP clients to agent frameworks like Mastra and LangGraph, enabling agent discovery, dynamic server connections, and recursive agent networks.551 npm10MIT
- AlicenseAqualityDmaintenanceAn MCP server that connects AI agents to TestOps, enabling test case management, launches, defects, and analytics through natural language.4825 npmMIT