airbattery-mcp
Related Servers
Alternatives to airbattery-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceA read-only MCP server that exposes data from native macOS apps (Mail, Notes, Calendar, Reminders, Contacts, Messages, Spotlight) to AI agents over stdio, currently in early development with no domain tools wired yet.4 npm5MIT
- AlicenseNot gradedqualityAmaintenanceA stdio MCP server exposing 43 tools that let AI agents diagnose and monitor a Mac's networking: which apps use bandwidth, Wi-Fi signal and channels, latency and packet loss, DNS and speed tests, why a host or API won't connect, whether traffic leaves via VPN, hotspot data budgets, and keeping the machine awake during long jobs. Read-only tools run without confirmation, while tools that change system settings prompt the agent to ask the user first.1GPL 3.0
- AlicenseAqualityBmaintenanceEnables AI assistants to read Apple Messages chat history and send iMessages or SMS on macOS, accessible locally via stdio or remotely over authenticated HTTP.5MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to discover and interact with iOS apps through a local MCP gateway, converting remote Streamable HTTP MCP endpoints into stdio tools. Provides dynamic device discovery, tool schema introspection, and deterministic tool calling for app analysis.-
- AlicenseNot gradedqualityBmaintenanceProvides macOS agent tools for Accessibility and EventKit operations over MCP stdio/HTTP, enabling UI automation, calendar/event access, permission gating, and optional vision configuration.MIT
- AlicenseNot gradedqualityDmaintenanceActvt's embedded MCP server for macOS. 25 tools for live CPU, GPU, memory and network metrics, listening ports with a guarded port_kill, and Claude Code and Codex session analytics (cost, tokens, transcript search, error patterns). It ships inside the Actvt macOS app and binds to loopback on the user's machine, so it starts with the app, not as a standalone or containerised process.MIT
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.