luneos-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| luneos_list_topicsA | List all LuneOS knowledge-base topics with a one-line description of each. Use this first to see what porting/debugging knowledge is available. |
| luneos_get_topicA | Return the full markdown content of one LuneOS knowledge topic (e.g. 'kernel-porting', 'debugging', 'device-bluejay'). Use luneos_list_topics to see valid names. |
| luneos_searchA | Case-insensitive search across the whole LuneOS knowledge base. Returns matching lines with surrounding context and the topic they came from. Good for symptoms ('wait_for_prop', 'EGL_BAD_ALLOC', 'FMP self test'), config options, file names, tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| luneos-session-start | Load the complete LuneOS porting knowledge base into the session before working on LuneOS. |
| luneos-port-device | Start porting LuneOS to a new Android device — walks kernel, boot image, Yocto machine and bring-up. |
| luneos-debug-boot | Debug a LuneOS device that does not come up — staged triage from kernel panic to UI. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| All LuneOS porting knowledge | Every LuneOS GSI/GKI porting, bring-up and debugging topic concatenated. Load this at session start when working on a LuneOS port. |
| LuneOS GSI + GKI Architecture | LuneOS is moving from device-specific images to **one universal LuneOS arm64 rootfs** that boots on essentially any unlockable Treble/GKI Android device, with per-device cost reduced to a boot image and a handful of config files. This document describes the target architecture, the storage/install model, the Tier A/Tier B kernel split, the adaptation tier model, and the current status (verified on the Pixel 3a `sargo` pilot device, August 2026). Historically, a LuneOS port = one Yocto `MACHINE` + one forked Android device tree + one full Halium Android build + one kernel fork — everything rebuilt per device (`TUNE_PKGARCH:append = "-halium"` taints every package with the machine arch). That is why LuneOS never scaled past Android 9. |
| Boot Image Construction for LuneOS Ports | How to build, verify and flash LuneOS boot images across the three device layout |
| LuneOS GSI/GKI Bring-up Debugging Playbook | A stage-by-stage playbook for "the device doesn't come up", distilled from real bring-ups: Pixel 3a (sargo, Halium 9→14/16 GSI), Pixel 6a (bluejay, GKI Tier A), Pixel 7 (panther), and a MediaTek MT6739 32-bit device (mindphone). Every failure mode here was hit on hardware and diagnosed; the fixes named are the ones that shipped. Work through the stages in order — each stage's failures are only visible once the previous stage is cleared, and several of these bugs hide behind one another. |
| Device: bluejay (Google Pixel 6a) | First Tensor LuneOS port (nobody — Halium/UT/Droidian/SFOS — has shipped any Tensor port). GKI Tier A: our own ACK-built kernel + LuneOS initramfs in `boot`, everything vendor-side stock. Working reference for the "one kernel per KMI" model: the same kernel binary serves panther. Working notes: `gsigki/bluejay/bluejay-notes.md`; build repo `~/Documents/GitHub/luneos-bootimg-bluejay`. |
| Device Bring-up in meta-smartphone / Yocto | How a LuneOS device port is wired into the Yocto build: repo and layer geography, what a |
| Device: mindphone (MediaTek MT6739, 32-bit) | The odd one out: a 64-bit-capable SoC running a **32-bit kernel and 32-bit userland**, Android 11 stock, non-dynamic partitions, boot header v2 — the legacy (Tier B) end of the spectrum. Most subsystems are **up**: UI, wifi, BT, dual-SIM modem, hardware keypad with T9. Also the port that produced the 32-bit `halium_arm` GSI (11 and 16). Working notes: `gsigki/mindphone/mindphone-notes.md`. Yocto: layer `meta-smartphone/meta-greentouch`, `MACHINE=mindphone`, build tree `/media/herrie/LuneOS/wrynose/webos-ports`. |
| Device: panther (Google Pixel 7) | Sibling of the bluejay port — same KMI, literally the same kernel binary — but an **A13-launch device**, so it exercises the `init_boot` split that bluejay cannot. No hardware has been flashed yet; everything below is host-side verified from the factory image. Working notes: `gsigki/panther/panther-notes.md` (method details in `../bluejay/bluejay-notes.md`). |
| Device: sargo (Google Pixel 3a) — the GSI pilot | The device the whole GSI/GKI architecture was proven on. **One generic rootfs (`MACHINE=halium-arm64`, no kernel, no GSI baked in) boots sargo on both the Halium 14.0 and 16.0 GSIs over its stock Android 12.1 vendor** — `systemctl is-system-running = running`, 0 failed units, full UI, 32 audio sinks, working nyx, sensorfwd, bluebinder, bluetooth and ofono. The same build serves both GSIs. Full history: `gsigki/luneos-gsi-gki-migration-plan.md` (§0, §2, §11). |
| Building Halium GSIs for LuneOS | The generic `/android` system image LuneOS mounts is a **Halium GSI**: an AOSP/LineageOS build of the `halium_arm64` (or 32-bit `halium_arm`) product from the `Halium/android` manifests, with hybris-patches applied. It is built ~once per Halium generation (9/11/13/14/16), never per device, and shipped as a tarball that the Yocto `android-system-image` recipes consume. This document records how the images are built, the traps hit on `halium-16.0` (lunch combo, version gates, removed modules), the device-tree patches required for a 16.0 GSI serving older vendors, and the complete recipe for building 32-bit `halium_arm` GSIs (needed for 32-bit-userland devices like mindphone/MT6739). |
| Userspace HAL Stack and Per-Subsystem Bring-up | LuneOS talks to Android vendor HALs through the Mer/Sailfish-lineage glue stack |
| Installing LuneOS on Ported Devices (Flash Kits) | LuneOS installs without touching the device's `system`, `vendor`, `vendor_boot`, `dtbo` or `super` partitions: you flash a verification-disabled `vbmeta`, a LuneOS boot image (and on A13-launch devices an `init_boot` image), and a `userdata` image containing the LuneOS rootfs and the Halium GSI as plain files. Stock Android's vendor stays in place and provides the HALs; the install is reversible. This document records the general model, the "athena-shape" pure-fastboot kit layout, the per-device flash sequences for bluejay (Pixel 6a), panther (Pixel 7) and mindphone (MT6739), debug-image workflow, and the anti-rollback constraints that can brick a device if ignored. |
| Kernel Porting for LuneOS (GKI Tier A and Legacy Tier B) | This document is the distilled kernel-porting method from the LuneOS GSI/GKI work |
| Nyx Modules and the Per-Machine CMake | Nyx is the webOS hardware portability layer: `nyx-lib` defines the API, `nyx-modules` |
| Porting & Debug Tools Reference | The small, self-contained tools built during the LuneOS GSI/GKI work, with usage |
TDQS
Scored across 3 tools
The three tools map cleanly onto distinct retrieval modes: enumerate topics (list), fetch one full document (get), and full-text search across the corpus (search). Descriptions explicitly state when to use each, including cross-references ('Use luneos_list_topics to see valid names'), leaving no realistic chance of misselection.
All three names use the same luneos_ prefix followed by a verb_noun pattern (luneos_list_topics, luneos_get_topic, luneos_search). The singular/plural distinction between get_topic and list_topics is meaningful rather than inconsistent, and the style is uniform throughout.
Three tools is on the thin side but each has a distinct, non-overlapping role and the whole surface is coherent for a read-only knowledge base. Nothing feels padded or missing at the operation level, though a slightly larger set (e.g. browsing by category or recency) would not be unreasonable.
For a read-only knowledge base, list/get/search covers the full retrieval lifecycle with no dead ends: an agent can discover topics, read them in full, or jump straight to a symptom via search. Minor gaps exist around metadata such as topic freshness, categories, or pagination for very large corpora, but core usage is fully supported.