mcpbeat Sign in

BatterySnap MCP Server

by battery-snap Your server? Claim it
answering

BatterySnap is answering right now. Last checked 12 min ago. It exposes 14 tools.

Real-world Android battery stats from BatterySnap users: device, model and fleet rankings.

Uptime history 24 days of history · worst day 99%
24 days agonow
100.0%
Uptime 24h
91 of 91 checks
14
Tools
read from the server
228 ms
Response time
average over 24h
open, no key
Access
streamable-http

What changed 14

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 2 November 2026. No other catalogue keeps this.

6 Nov a tool changed the parameters it asks for top_devices
2 Nov 6 tool descriptions were rewritten7 times that day devices, fleet_summary, model_summary and 3 more
2 Nov 4 tools changed the parameters they ask for5 times that day fleet_summary, model_summary, top_devices and 1 more
2 Nov a tool appeared region_summary
and 2 more, back to 2 November 2026

BatterySnap missed one check this week

Everything else answered, so this is steady rather than shaky. We check every 15 minutes, which is how a one-off gets told apart from the start of a pattern, and how you hear about the next one within the hour instead of from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 12 min ago.

run in your terminal
claude mcp add batterysnap --transport http https://mcp.battery-snap.com/mcp
Settings → Connectors → Add custom connector, then paste this address
https://mcp.battery-snap.com/mcp
~/.codex/config.toml
[mcp_servers.batterysnap]
url = "https://mcp.battery-snap.com/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "batterysnap": {
      "url": "https://mcp.battery-snap.com/mcp"
    }
  }
}
.vscode/mcp.json
{
  "servers": {
    "batterysnap": {
      "type": "http",
      "url": "https://mcp.battery-snap.com/mcp"
    }
  }
}

Available tools 14

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

top
top_devices
Rank INDIVIDUAL devices by any battery metric — the general-purpose leaderboard. Use it for 'which phones run hottest / last longest / charge fastest', optionally narrowed to one brand and/or model. Returns at most `limit` rows, so it answers superlative questions in a single small call instead of enumerating the fleet. Ranking is over each device's own lifetime aggregate. Pair the metric with the right `order`: e.g. hottest = temperature_c + desc, fastest AC charging = ac_charge_hours + asc, best battery life = discharge_hours + desc. There is no region filter here: regional questions go to the aggregates (`region_summary`, `top_models`, `fleet_summary`).
top_devices_by_live_uptime
Same as `top_devices_by_uptime`, but restricted to devices that have not yet rebooted past their recorded maximum — meaning the uptime is currently still climbing. These are the devices that are 'live' champions right now, as opposed to historical record-holders. Each entry includes a `url` pointing at the device's interactive battery history page on https://www.battery-snap.com.
top_devices_by_uptime
Return the devices with the longest single uptime ever recorded between reboots (max_elapsed_time). Optionally filter by brand and/or model. Useful to find which physical phones in the fleet are champions of staying powered on for weeks/months at a time. Each entry includes a `device_uid` you can feed into `device_summary` for deeper analysis, and a `url` pointing at the device's interactive battery history page on https://www.battery-snap.com.
top_models
Rank device MODELS by any battery metric, aggregating across every device of that model. This is the tool for 'which phone model has the best battery life', 'which models charge fastest', 'which run hottest' — questions that would otherwise need one `model_summary` call per model. Ordering is by the per-model MEDIAN of the metric (outlier-resistant); the mean is returned alongside. Use `brand` to rank within one manufacturer and `min_devices` to require a minimum sample size. `country` / `continent` rank the models as they behave in one region (e.g. heat in hot climates).
device
device_ranking
Answer 'is MY phone normal?' — rank one device's metric against other devices of the same model AND against the whole fleet, in one call. Returns the device's value, its 1-based rank, its percentile, and the cohort median / mean / min / max for both cohorts. Prefer this over fetching `device_summary` + `model_summary` and comparing by hand: it is a single call and gives the percentile directly. The model cohort is the meaningful one for 'is this device degraded'; the fleet cohort puts the model itself in context.
device_summary
Return aggregated battery metrics for ONE specific device: average / min / max temperature, average battery level, mean charge time per power source (AC, USB, wireless) and mean discharge time over a recent (~2 weeks) and a long (~2 months) window, plus awake ratio and basic device info. Also includes `url`: the public BatterySnap web page for this device's interactive battery history (https://www.battery-snap.com/device_history?device=<uid>). All values are pre-computed from the device's full snapshot history — no raw timeseries is returned.
fleet
fleet_summary
Aggregate battery metrics across the entire fleet, or across one brand when `brand` is provided, optionally restricted to one `country` / `continent`. Returns mean / median / p25 / p75 / min / max for the same set of metrics as `model_summary`. Use this for fleet-wide baselines that a single device or model can be compared against. A region scope with fewer than 5 devices is refused; to compare several regions at once use `region_summary`.
fleet_totals
Live fleet-wide counters: total devices, models, snapshots, sessions, the running snapshot-ingest rate (snapshots/sec) and the timing of the last insert batch. Use this for one-shot 'how big is the dataset / how fast is it growing' questions. Unlike `fleet_summary`, no per-device aggregation is involved — these are raw running counts from the database.
brands
brands
Return the mobile devices brands for which we have battery statistics, along with the number of distinct models, the number of devices recorded per brand, and the largest single-model device count within the brand (`max_devices_per_model`). Each entry also includes a `url` to the public BatterySnap web page for the brand (e.g. https://www.battery-snap.com/brands/samsung). Pass `min_device_count` / `max_device_count` and `min_model_count` / `max_model_count` to filter brands by recorded-device and distinct-model counts. Pass `fields` to keep only specific attributes in each entry. The full list is long: pass `limit` (and `offset` to page) unless you really need every brand, and prefer `search` when resolving one brand by name.
devices
devices
Return the list of individual physical devices matching one or more (brand, model) pairs for which we have battery statistics. Each entry in the returned list describes ONE specific device (identified by its own `device_uid`) and the metrics on that entry are aggregates computed only from THAT device's own snapshot history — they are not aggregated across devices. Two devices of the same brand and model will appear as two separate entries with their own independent metrics. Per-device fields include: brand, resolved model (street name), raw Android model, snapshot count, activity window (first / last seen), average battery level, average / min / max battery temperature in Celsius, awake-ratio, discharge speed and AC / USB / wireless charge speed (hours per full 100% swing), Android SDK level, and a `url` pointing at the public BatterySnap web page for the device's interactive battery history (https://www.battery-snap.com/device_history?device=<uid>). Each pair's model is matched case-insensitively against either the resolved street name (e.g. 'Galaxy S23') or the raw Android model identifier (e.g. 'SM-S911B'). Pass `fields` to keep only specific attributes per device and avoid bloated responses.
model
model_summary
Aggregate battery metrics across ALL devices of a given brand+model. Returns mean / median / p25 / p75 / min / max for: temperature (C), battery level (%), discharge speed (hours per 100%%), AC / USB / wireless charge speed (hours per 100%%), and awake ratio. Use this to characterize how a model behaves in the field, or to compare a single device against its model average. Also includes: * `raw_model_code`: representative raw Android Build.MODEL identifier (smallest among devices grouped under this street name), or null if none recorded. * `url`: public BatterySnap web page for the model (https://www.battery-snap.com/brands/<brand>/models/<raw_model_code>); null when `raw_model_code` is null. Pass `country` and / or `continent` to restrict to devices of that region; the call fails when fewer than 5 devices of the model remain.
models
models
Return the mobile devices models of the given brands for which we have battery statistics, along with the brand each model belongs to, the number of devices recorded, the average battery temperature in Celsius, and the min/max Android SDK level per model. Each entry is grouped by the resolved street name (e.g. 'Galaxy S23'), which may cover several raw Android Build.MODEL identifiers (carrier variants, regional SKUs, …). For URL building, every entry also exposes: * `raw_model_code`: a representative raw Build.MODEL identifier (the lexicographically smallest one among devices grouped under this street name), or null if no device reported a non-empty model code. * `url`: the public BatterySnap web page for the model, e.g. https://www.battery-snap.com/brands/samsung/models/SM-S911B. Built from `brand` + `raw_model_code`; null when either is null; `raw_model_code` is null. The page lists all devices reporting that exact raw model. Pass `min_device_count` / `max_device_count` to filter models by how many devices were recorded. For 'which models have the most devices' questions, pass sort='device_count' with a small `limit` (and typically fields=['brand', 'model', 'device_count', 'url']) instead of fetching and sorting the full list. Pass `fields` to keep only specific attributes in each entry. Omit `brands` (or pass an empty list) to return models across every brand.
region
region_summary
Compare battery behaviour across regions in one call: one entry per continent or per country, each with the same mean / median / p25 / p75 / min / max blocks as `fleet_summary` (temperature, level, discharge and charge hours, awake ratio). Narrow with `brand` / `model` (e.g. how one model fares per continent) or with `continent` (e.g. group_by='country' within 'Africa'). The region is derived from the time zone the phone is set to (not GPS / IP), so travellers and manual settings blur it. Regions with fewer than 5 devices are left out and only counted (`suppressed_*`), as are devices whose time zone names no place (`unlocated_device_count`); check each group's `device_count` before comparing — small groups are noisy.
search
search
Resolve free-form user text into the canonical brand / model identifiers the other tools expect. Meant for phones named in free text: the other tools match brands and models exactly, so a guessed spelling returns an empty list. Matching is substring-based and case-insensitive over brand, resolved model name and raw Build.MODEL, ranked by exact match then popularity.

Endpoints

URLTransportStateLatencyChecked
https://mcp.battery-snap.com/mcp streamable-http answering 235 ms 12 min ago

Alternatives to BatterySnap

same job, measured the same way
Devicely
by sureshkumarm8

Control real iOS & Android devices from AI agents; mirror one tap across a whole fleet.

469 installs/wk local only
SpyFu MCP by usefulapi
by usefulapi

Read domain stats, competitors, keywords, rankings and ad history in SpyFu.

19 tools answering
U
USGS Water Monitoring
by olyport

Real-time water levels and flow rates from USGS stream gauges

3 tools answering
AI Stupid Level
by studioplatforms

LLM benchmark rankings, drift status, incidents and Smart Router previews from AI Stupid Level.

65 installs/wk local only
Water Quality Portal MCP
by mrfentmen

US water monitoring stations and sample results from USGS and EPA.

32 installs/wk local only
Bidxon — ad-free AI shopping agent
by eduardorom

Real US store prices with shipping, daily price history and real-deal checks. Never paid rankings.

2 tools answering
MCP Agent Brokerage Resolver
by mambabuilt

Find a US real estate agent's brokerage, brokerage size, and license status from state registers.

231 installs/wk local only
AI Pricing Hub
by gishh

Source-backed AI model pricing, rankings, history, and benchmark data.

11 tools answering

BatterySnap — questions

Answers built from our own checks of this server.

What can BatterySnap do?
It exposes 14 tools, read directly from the server on our last check. Among them: brands, device_ranking, devices, device_summary, fleet_summary, fleet_totals and 8 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
What is BatterySnap mostly used for?
Its tools cluster around top, device and fleet. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.
Is BatterySnap working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 228 ms. The bar chart above shows every period we have measured.
How do I connect BatterySnap?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does BatterySnap need an API key?
No. BatterySnap completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 14 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is BatterySnap?
It answers our handshake in 228 ms on average, which is faster than 60% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.