BatterySnap

Device battery summary

device_summary

Read-onlyIdempotent

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=). All values are pre-computed from the device's full snapshot history — no raw timeseries is returned.

Input Schema

Name	Required	Description	Default
`device_uid`	Yes	Stable device UUID returned by the `devices` tool.

Output Schema

Name	Required	Description
`url`	No	Public BatterySnap web page showing this device's interactive battery history, e.g. https://www.battery-snap.com/device_history?device=<uid>. Locale-agnostic.
`brand`	No	Lowercase Android brand identifier.
`model`	No	Human-readable resolved model name (e.g. 'Galaxy S23').
`raw_model`	No	Raw Build.MODEL string reported by the device.
`device_uid`	No	Stable UUID identifying this device.
`awake_ratio`	No	Fraction of observed time the device was awake / screen-on (0..1).
`observed_days`	No	Span of the recorded history in days, rounded to 30 days.
`snapshot_count`	No	Approximate snapshots recorded for this device (one significant digit).
`android_api_level`	No	Android SDK level (e.g. 34 = Android 14).
`avg_temperature_c`	No	Mean battery temperature in Celsius across all snapshots.
`max_temperature_c`	No	Hottest battery temperature in Celsius ever observed. Sustained highs are a battery-health concern.
`min_temperature_c`	No	Coldest battery temperature in Celsius ever observed.
`avg_battery_level_pct`	No	Mean battery charge level across all snapshots (0-100).
`mean_ac_charge_hours_long`	No	Hours to charge 100%% on AC over the last ~2 months.
`mean_discharge_hours_long`	No	Average hours to discharge 100%% over the last ~2 months.
`mean_usb_charge_hours_long`	No	Hours to charge 100%% over USB over the last ~2 months.
`mean_ac_charge_hours_recent`	No	Hours to charge 100%% on AC (wall charger) over the last ~2 weeks.
`mean_discharge_hours_recent`	No	Average hours to discharge 100%% over the last ~2 weeks. Null when not enough data.
`mean_usb_charge_hours_recent`	No	Hours to charge 100%% over USB (computer) over the last ~2 weeks.
`mean_wireless_charge_hours_long`	No	Hours to charge 100%% wirelessly over the last ~2 months.
`mean_wireless_charge_hours_recent`	No	Hours to charge 100%% wirelessly over the last ~2 weeks.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 6, 2026

removedOutput schema / properties / first_seen

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 8601 timestamp of the earliest snapshot."
-}

removedOutput schema / properties / last_seen

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 8601 timestamp of the most recent snapshot."
-}

changedOutput schema / properties / observed_days / description

Previous value: -"Span in days between first_seen and last_seen."New value: +"Span of the recorded history in days, rounded to 30 days."

changedOutput schema / properties / snapshot_count / description

Previous value: -"Total snapshots recorded for this device."New value: +"Approximate snapshots recorded for this device (one significant digit)."

Changed3 schema fields changedNov 2, 2026

removedOutput schema / properties / continent

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "Continent derived from the device's time zone: one of 'Africa', 'Antarctica', 'Asia', 'Europe', 'North America', 'Oceania', 'South America'. Null when unknown."
-}

removedOutput schema / properties / country

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 3166 alpha-2 country code derived from the device's time zone (e.g. 'FR' for Europe/Paris). It is where the phone's clock is set, not a GPS / IP location. Null when the zone names no place (UTC, GMT) or is unknown."
-}

removedOutput schema / properties / time_zone

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "IANA time zone reported by the device."
-}

Changed2 schema fields changedNov 2, 2026

addedOutput schema / properties / continent

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Continent derived from the device's time zone: one of 'Africa', 'Antarctica', 'Asia', 'Europe', 'North America', 'Oceania', 'South America'. Null when unknown."
+}

addedOutput schema / properties / country

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "ISO 3166 alpha-2 country code derived from the device's time zone (e.g. 'FR' for Europe/Paris). It is where the phone's clock is set, not a GPS / IP location. Null when the zone names no place (UTC, GMT) or is unknown."
+}

First observedOct 16, 2026

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real value beyond them: values are pre-computed from full snapshot history, no raw timeseries is returned, and the two aggregation windows (~2 weeks, ~2 months) are disclosed. It also explains the `url` field's meaning, though it doesn't discuss latency or data freshness beyond the window sizes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense paragraph that front-loads the core purpose and metric list, with the URL and pre-computation caveats following. Every sentence carries information, though the metric enumeration is long enough that a bulleted structure would read faster.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with an output schema, the description covers purpose, scope, aggregation windows, return nature (pre-computed, no raw timeseries), and the extra `url` field. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter is already documented as a stable device UUID from the `devices` tool, so the description adds little parameter-level meaning. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Return aggregated battery metrics for ONE specific device') and enumerates the exact metrics returned (avg/min/max temperature, battery level, charge/discharge times, awake ratio). The 'ONE specific device' scoping plus the metric list clearly separates it from fleet_summary, model_summary, and region_summary siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the selection condition explicit ('ONE specific device') and points to the `devices` tool as the source of the required device_uid, which is a useful routing hint. It stops short of stating when-not to use it or naming a specific alternative for multi-device queries, so it falls just below the top band.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BatterySnap tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?