Osquery has a wide table surface and a model writing queries blind will invent columns. Pairing `listOsqueryTables` and `getTableSchema` with a set of worked examples means it checks first and composes second. The native image is worth building if a voice or desktop client launches the server on demand — the JVM start is the part that makes that feel slow. Temperature and fan readings are macOS-only.
An Osquery server for system diagnostics. It runs osqueryi under the hood and adds ready-made queries for the questions people actually ask, plus schema discovery so the model can compose its own.
- Eleven tools. Core: `executeOsquery` runs any valid Osquery SQL, `listOsqueryTables` lists what your system exposes, `getTableSchema` returns the columns and types for one table
- Diagnostics: `getHighCpuProcesses`, `getHighMemoryProcesses`, `getHighDiskIOProcesses`, `getNetworkConnections` with process info, `getTemperatureInfo` for temperatures and fan speeds on macOS, and `getSuspiciousProcesses`
- Helpers: `getCommonQueries` returns worked examples for common problems so the model composes better SQL
- `getSystemHealthSummary` runs five diagnostic queries — CPU, memory, disk, network, temperature — concurrently on virtual threads, so it costs the slowest query rather than the sum
- Queries time out at 30 seconds and version checks at 5, with the process destroyed rather than left hanging
Java 25 or newer — GraalVM CE 25 if you want the native image — and osquery installed with `osqueryi` on your PATH. Build with `./gradlew bootJar` and run it over stdio, or `./gradlew nativeCompile` for a native binary. The repository also ships a Spring AI client and a Claude Code skill that runs osqueryi directly through Bash with no server process at all.
Build from source — clone the repository and build it, then point your client at the binary