Bluetooth LE Health Sensors — MCP Server
Let an AI agent read any Bluetooth Low Energy sensor that implements the standard Bluetooth SIG health profiles: record heart rate with RR intervals and HRV from a chest strap, read SpO2 and pulse rate from an oximeter, and capture blood pressure, body temperature and weight readings from monitors, thermometers and scales, in physiology labs, sports-science studies, sleep/HRV research and lab-operations settings.
| Package | labmcp-ble-health |
| Instruments | Any device implementing the Bluetooth SIG profiles: heart-rate straps/armbands (Heart Rate Service 0x180D), pulse oximeters (Pulse Oximeter Service 0x1822), blood pressure monitors (0x1810), thermometers (Health Thermometer 0x1809), weight scales (Weight Scale 0x181D), plus Battery (0x180F) and Device Information (0x180A) |
| Interfaces | Bluetooth Low Energy, via bleak (Linux/BlueZ, macOS/CoreBluetooth, Windows/WinRT) |
| Protocol | Bluetooth SIG GATT: GATT Specification Supplement, HRS 1.0, PLXS 1.0.1, BLS 1.1.1, HTS 1.0, WSS 1.0.1; IEEE 11073-20601 SFLOAT/FLOAT per the PHD Transcoding White Paper v16 |
| Status | 🧪 simulated: tested against a simulated BLE backend that emits byte-exact GATT packets, not yet verified on hardware. Report a hardware test |
Try it without hardware
uvx labmcp-ble-health --simulate --check
The simulator provides six devices (addresses 00:00:5E:00:53:01–06, from the IANA documentation range): a combined "health kit" (default) exposing every service, and a separate HR strap, oximeter, BP monitor, thermometer and scale. Pick one with e.g. --simulate --address 00:00:5E:00:53:04.
Connect your device
- Check the device uses the standard profiles. Only devices that implement the Bluetooth SIG services above work. Many consumer wearables (most smartwatches, many fitness bands, several BP-monitor and scale brands) use proprietary protocols instead, and some only speak the standard profile in a "pairing"/"data transfer" mode. Chest straps that advertise the Heart Rate Service are the most reliable choice for HRV work.
- Free the device. A BLE sensor usually accepts one connection: close the vendor's phone app (or switch phone Bluetooth off) before connecting.
- Find the address: start the server without
--addressand ask the agent to runscan_devices, or run it with--checkafter putting the device in advertising mode (wear the strap; press the monitor's Bluetooth/start button). On Linux/Windows the address is the MAC (AA:BB:CC:DD:EE:FF); on macOS it is a CoreBluetooth UUID that is specific to your computer. - Test the connection:
uvx labmcp-ble-health --address AA:BB:CC:DD:EE:FF --check # Linux / Windows uvx labmcp-ble-health --address 1A2B3C4D-1111-2222-3333-444455556666 --check # macOS
Devices that require bonding (common for BP monitors and scales): add--option pair=trueon Linux/Windows; macOS shows a system pairing prompt automatically. On Linux choose a non-default adapter with--option adapter=hci1; lengthen device discovery with--option connect_timeout_s=40(at most 60 s).
macOS: the terminal (or MCP client app) that launches the server needs Bluetooth permission (System Settings › Privacy & Security › Bluetooth). Without it macOS terminates the process as soon as Bluetooth is touched (exit code 134), before any error message can be printed.
Add to your MCP client
Claude Code
claude mcp add hr-strap -- uvx labmcp-ble-health --address AA:BB:CC:DD:EE:FF
Claude Desktop / Cursor / Windsurf (claude_desktop_config.json, .cursor/mcp.json, …)
{
"mcpServers": {
"hr-strap": {
"command": "uvx",
"args": ["labmcp-ble-health", "--address", "AA:BB:CC:DD:EE:FF"]
}
}
}
Every tool is read-only (nothing on the device is changed, no control points are written), so --read-only makes no difference. Run one server entry per device if you use several sensors at once. For other clients, generate the snippet with uvx labmcp config ble-health --address AA:BB:CC:DD:EE:FF --client vscode (also cursor, codex, claude-code).
Tools
| Tool | Kind | Description |
|---|---|---|
get_command_log |
👁 read | Return the most recent raw commands sent to / replies received from the instrument (newest last). Useful for debugging and for recording what was done. |
get_connection_info |
👁 read | Report which instrument is connected (identity, address, simulated or real), whether the server is read-only, and the active safety limits. Call this first. |
get_device_info |
👁 read | Read the device's identity (manufacturer, model, serial, firmware), the standard health services it exposes and its features. |
read_battery |
👁 read | Read the device's battery level (Battery Service, 0-100 %). |
read_pulse_oximetry |
👁 read | Read SpO2 (%) and pulse rate from a pulse oximeter, averaged over a few seconds or as a single spot-check reading. |
read_temperature |
👁 read | Wait for a thermometer to send a temperature measurement and return it in °C. |
read_weight |
👁 read | Wait for a scale to send a weight measurement (kg), with BMI and height if the scale sends them. |
reconnect |
🛑 safety | Close and re-open the connection to the instrument (e.g. after it was power cycled or a cable was re-plugged). |
record_heart_rate |
👁 read | Record heart rate for duration_s: bpm series, RR intervals and time-domain HRV (mean HR, SDNN, RMSSD, pNN50). |
scan_devices |
👁 read | Scan for nearby Bluetooth LE devices: address, name, signal strength and advertised health services. Works without a configured --address. |
wait_for_blood_pressure |
👁 read | Wait for a blood pressure monitor to send a measurement: systolic, diastolic and mean arterial pressure (mmHg) and pulse rate. |
get_connection_info, get_command_log and reconnect are built into every LabMCP server.
Safety limits
| Limit | Default | Meaning |
|---|---|---|
max_record_duration_s |
600 s | Longest heart-rate recording or continuous-oximetry averaging window an agent may start |
max_wait_s |
300 s | Longest time a tool may wait for a blood pressure, temperature, weight or spot-check reading |
Override at launch: --limit max_record_duration_s=1800. Note that many MCP clients also enforce their own per-tool-call timeout; long recordings may need that raised too (e.g. MCP_TOOL_TIMEOUT in Claude Code).
Example prompts
- "Record 5 minutes of heart rate from the chest strap and give me mean HR, SDNN and RMSSD, and save the raw RR intervals to ~/hrv/p07_baseline.csv."
- "Scan for heart-rate straps nearby and tell me which one has the strongest signal."
- "Wait for the blood pressure monitor: I'll start the cuff now. Report systolic/diastolic and whether the device flagged movement or an irregular pulse."
- "Average SpO2 and pulse rate over 30 seconds from the oximeter and tell me how many samples were unusable."
- "Read the scale when the participant steps on it and log weight and BMI with the device timestamp."
- "What's the battery level of the strap before we start the session?"
Notes
- Measurement devices push, they are not polled. Blood pressure monitors, thermometers, scales and spot-check oximeters only indicate a value when a measurement completes (these characteristics cannot be read). Call the tool first, then take the measurement. The tool keeps scanning and reconnecting until its timeout because many monitors only advertise right after measuring (for oximeters this needs
mode="spot_check";automust connect first to find out which mode the device supports). - One measurement at a time. Starting a measurement cancels one that is still running on the same server (for example a recording whose tool call already timed out in the MCP client), and
reconnectcancels it too; the cancelled call returns an error. - Malformed packets are skipped and logged (
get_command_log) rather than discarding the whole recording;record_heart_rateandread_pulse_oximetryreport how many inmalformed_packets. save_path(record_heart_rate) must be a new.csvfile:~is expanded, missing folders are created, and an existing file is never overwritten. It is checked before recording starts.- Stored measurements. Monitors send unsent stored readings back-to-back, oldest first, when they connect. Tools keep listening 1.5 s after the first one and return the newest as the result, listing older ones in
other_measurements; the device clock time is indevice_timestamp(device local time, often wrong if the clock was never set). - Special values (IEEE 11073 NaN, NRes, ±INF) are never turned into numbers: they are reported as
nullwith an explanation (special_values,unavailable_samples). Oximeters typically send NaN for the first seconds while acquiring. - Units: blood pressure in kPa is converted to mmHg (1 kPa = 7.500617 mmHg), °F to °C, lb to kg;
unit_reportedsays what the device sent. Weight resolution is 0.005 kg / 0.01 lb per the Weight Scale spec;0xFFFFmeans "measurement unsuccessful" and is returned asweight_kg: null. Energy expended is in kJ (HRS 1.0). - HRV is computed from the RR intervals the sensor sends (unit 1/1024 s): SDNN (sample SD), RMSSD, pNN50. RR intervals outside 0.3–2.0 s are excluded as artefacts; no further artefact correction or ectopic-beat editing is done. If a notification is lost over the air, the successive difference across that gap is not a true beat-to-beat difference. Optical wrist sensors often send no RR intervals at all. Use a validated ECG system for anything beyond exploratory research.
- The Enhanced Blood Pressure Measurement, Record Access Control Point (downloading a monitor's whole memory), Current Time and User Data services are not implemented; nothing is ever written to the device.
- Bluetooth pairing, bonding keys and OS permissions are handled by the operating system; the server never sees PINs.
Hardware verification
| Model | Firmware | Interface | Verified by | Date |
|---|---|---|---|---|
| none yet: be the first |
Release files for labmcp-ble-health 0.1.2
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| labmcp_ble_health-0.1.2.tar.gz | 38.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| labmcp_ble_health-0.1.2-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 73.5 kB
Release files / labmcp_ble_health-0.1.2.tar.gz
| Download URL | labmcp_ble_health-0.1.2.tar.gz |
|---|---|
| Size | 38.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
5360ca3b3beb1b62fa94d714d6293f4f1ba85a3a664066a86e3c5070dc6d951f
|
|
BLAKE2b-256 checksum How to use checksums |
badbc39e85da0f2378aafe6ab1425e38aadf95077a69528398e73a1874c5a520
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.
Transparency logRelease files / labmcp_ble_health-0.1.2-py3-none-any.whl
| Download URL | labmcp_ble_health-0.1.2-py3-none-any.whl |
|---|---|
| Size | 35.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
980f346a1a50af2b59f4b63767611bac15d87756f9dbca23b210ad54938fd0df
|
|
BLAKE2b-256 checksum How to use checksums |
4cc505ce475b42b8f6ee5502903b7ea0d250ddfd377297badcef8c9c36fa022d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 26, 2026.
Transparency log