Skip to main content

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

  1. 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.
  2. Free the device. A BLE sensor usually accepts one connection: close the vendor's phone app (or switch phone Bluetooth off) before connecting.
  3. Find the address: start the server without --address and ask the agent to run scan_devices, or run it with --check after 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.
  4. 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=true on 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"; auto must 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 reconnect cancels 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_rate and read_pulse_oximetry report how many in malformed_packets.
  • save_path (record_heart_rate) must be a new .csv file: ~ 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 in device_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 null with 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_reported says what the device sent. Weight resolution is 0.005 kg / 0.01 lb per the Weight Scale spec; 0xFFFF means "measurement unsuccessful" and is returned as weight_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)

Source distribution for labmcp-ble-health 0.1.2
File Size Uploaded
labmcp_ble_health-0.1.2.tar.gz 38.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for labmcp-ble-health 0.1.2
File Interpreter ABI Platform
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 log

Release 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

Release history Release notifications | RSS feed

0.1.3

2 release files

This release

0.1.2 This release

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page