BatterySnap

Find devices by model

devices

Read-onlyIdempotent

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=).

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.

Input Schema

Name	Required	Description	Default
`pairs`	Yes	One or more {brand, model} pairs to look up. Each pair fetches devices matching that brand and model.
`fields`	No	Optional whitelist of attribute names to keep in each returned entry, used to shrink the response. When omitted or empty, all attributes documented in the output schema are returned. Unknown names are silently ignored.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

removedOutput schema / properties / result / items / properties / first_seen

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 8601 timestamp of the earliest battery snapshot recorded for this device. Null if unknown."
-}

removedOutput schema / properties / result / items / properties / last_seen

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "ISO 8601 timestamp of the most recent battery snapshot recorded for this device. Null if unknown."
-}

changedOutput schema / properties / result / items / properties / snapshot_count / description

Previous value: -"Total number of battery snapshots recorded for this device. Higher values mean the per-device aggregates are based on more samples and are more reliable."New value: +"Approximate number of battery snapshots recorded for this device (one significant digit). Higher values mean the per-device aggregates are based on more samples and are more reliable."

Changed3 schema fields changedNov 2, 2026

removedOutput schema / properties / result / items / 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 / result / items / 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 / result / items / properties / time_zone

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "description": "IANA time zone identifier reported by the device (e.g. 'Europe/Paris', 'America/New_York'). Indicates the geographic region the device is operating in. Null when unknown."
-}

Changed2 schema fields changedNov 2, 2026

addedOutput schema / properties / result / items / 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 / result / items / 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

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent and closed-world, and the description adds genuinely new behavioral context: metrics are aggregated only from that device's own snapshot history, duplicate brand/model devices appear as separate entries, matching is case-insensitive against either street name or raw Android model, and each entry carries a public `url`. It does not say what happens on a no-match (empty list? error) or whether result ordering/pagination exists, which keeps it below 5.

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

Conciseness3/5

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

Purpose and the per-device-vs-aggregate clarification are front-loaded and well structured. However, the long enumeration of per-device fields ('brand, resolved model ..., snapshot count, activity window ..., average / min / max battery temperature ..., awake-ratio, discharge speed ...') largely reproduces the output schema and bloats the definition, as does the repeated matching-rule sentence.

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

Completeness4/5

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

For a read-only two-parameter lookup with a full output schema and complete schema descriptions, the description covers the semantics that matter: what one entry represents, non-aggregation across devices, dual-name model matching, and response trimming. Gaps are minor (empty-result behavior, ordering/pagination limits) and the return-value explanation is provided by the output schema rather than the description.

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 description coverage is 100%, so both `pairs` members and `fields` are already documented in the schema. The description restates the same matching rule ('case-insensitively against either the resolved street name ... or the raw Android model identifier') and the same `fields` intent ('keep only specific attributes'), adding no new syntax, limits, or format detail beyond the structured data. Baseline 3 applies.

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 the list of individual physical devices matching ... (brand, model) pairs') and immediately scopes the granularity: 'Each entry ... describes ONE specific device ... not aggregated across devices.' That contrast distinguishes it from aggregate siblings like model_summary, device_ranking and fleet_totals without the agent needing to open another schema.

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

Usage Guidelines3/5

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

Usage is implied rather than stated — the reader infers this is the right tool when they need per-device rows for known brand/model pairs, and 'Pass `fields` to keep only specific attributes per device and avoid bloated responses' gives a concrete efficiency rule. But no sibling is named (e.g. 'use search for free-text lookup, device_summary for one device') and no exclusion is given, so routing relies on inference.

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?