airbattery-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIRBATTERY_CLI | No | Optionally set the environment variable AIRBATTERY_CLI to the absolute path of the AirBattery CLI executable if automatic discovery does not find it. The server finds AirBattery's command line tool in this order: $AIRBATTERY_CLI, /usr/local/bin/airbattery, /Applications/AirBattery.app/Contents/Resources/abt, ~/Applications/AirBattery.app/Contents/Resources/abt, then airbattery on PATH. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_battery_statusA | Get current battery levels of the user's devices (AirPods, iPhone, mice, headphones, speakers...). Data comes from the AirBattery app on this Mac. Each entry has:
Non-Apple devices only report while connected to this Mac, and some report coarse levels, so treat small differences cautiously. Args: device: optional case-insensitive name filter, e.g. "airpods" or "mx master". include_nearcast: also include devices reported by other Macs on the LAN via AirBattery Nearcast. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of misselection or overlap. Its purpose (read current battery levels) is stated precisely and its scope is unambiguous.
get_battery_status follows a clean verb_noun convention with no competing names to clash against. Within a single-tool server, naming is maximally consistent.
A single tool is on the thin side even for a narrow domain; a companion tool (e.g. listing known devices or per-device history) would round out the surface. The one tool does earn its place and the count is not excessive.
The read path is well covered: filtering by device, Nearcast inclusion, and rich per-entry metadata with staleness semantics. Minor gaps remain (no device enumeration without a call, no history or alerting), but the stated purpose is fully served.