Bluetooth LE Health Sensors

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.

[!WARNING] Research and lab-operations use only. This is not a medical device. It is not intended for diagnosis, monitoring of patients, triage, or any clinical decision-making, and has not been validated or cleared by any regulator. Consumer sensors can be inaccurate; values pass through an AI agent that can misread them. Never use this server's output to make health decisions. Readings of people are personal data: follow your ethics approval and data-protection rules.

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:
   bash

   uvx labmcp-ble-health --address AA:BB:CC:DD:EE:FF --check                       # Linux / Windowsuvx 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

get_connection_info, get_command_log and reconnect are built into every LabMCP server.

Safety limits

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