Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Bluetooth LE Health Sensors

PYPI · LABMCP-BLE-HEALTH · SCANNED SEP 30

MCP server for Bluetooth LE health sensors (standard GATT profiles).

Available components

67 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security50
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
  • 2 of 33 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to K-Dense-AI/lab-instrument-mcps). View diagnostics → Pass
  • Clear OSI-approved license (Apache-2.0).Pass
  • Actively maintained (last published 3 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability78
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 1299 tokens (~118/item across 11 items; 11 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
  • Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage98
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 93% of tool parameters carry a description.Partial
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 11 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 12 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass

Unverified: 1 category

A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

Install

How do I install the Bluetooth LE Health Sensors MCP server?

Bluetooth LE Health Sensors runs locally as a PyPI package, launched with uvx labmcp-ble-health. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · labmcp-ble-health

# add to Claude Code
claude mcp add k-dense-ai-labmcp-ble-health -- uvx labmcp-ble-health
// .cursor/mcp.json
{
  "mcpServers": {
    "k-dense-ai-labmcp-ble-health": {
      "command": "uvx",
      "args": [
        "labmcp-ble-health"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "k-dense-ai-labmcp-ble-health": {
      "command": "uvx",
      "args": [
        "labmcp-ble-health"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add k-dense-ai-labmcp-ble-health -- uvx labmcp-ble-health
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "k-dense-ai-labmcp-ble-health": {
      "type": "local",
      "command": [
        "uvx",
        "labmcp-ble-health"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add k-dense-ai-labmcp-ble-health --command uvx --arg labmcp-ble-health
# ~/.hermes/config.yaml
mcp_servers:
  k-dense-ai-labmcp-ble-health:
    command: "uvx"
    args: ["labmcp-ble-health"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "k-dense-ai-labmcp-ble-health": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "labmcp-ble-health"
      ]
    }
  }
}
# add to Vellum
assistant mcp add k-dense-ai-labmcp-ble-health -t stdio -c uvx -a labmcp-ble-health
// mcp.json
{
  "mcpServers": {
    "k-dense-ai-labmcp-ble-health": {
      "command": "uvx",
      "args": [
        "labmcp-ble-health"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 28 Sept 26 −4
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 27 Sept 26 0
    • Package version: 0.1.2 → 0.1.3 functional
  • 26 Sept 26 71

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 30 Sept 2026 · Analysed pypi/labmcp-ble-health@0.1.3

Provenance Verified

A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.

Result Verified
Ecosystem pypi
Reason Verified
Discovered via Registry attestation endpoint
Source repo K-Dense-AI/lab-instrument-mcps
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/K-Dense-AI/lab-instrument-mcps/.github/workflows/release.yml@refs/tags/labmcp-ble-health-v0.1.3
Rekor log index 2969518282
Predicate type PyPI publish attestation https://docs.pypi.org/attestations/publish/v1
Subject digest sha256:3f7d3d2c4cd88a77289fcea7c063d828e1d5b2546471ab7a04cb2b2526739dea

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 33 packages
Packages resolved 33
Stale 2
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 11 exposed · ~859 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
get_command_log ~46

Return the most recent raw commands sent to / replies received from the instrument (newest last). Useful for debugging and for recording what was done.

NameTypeReqDescription
limitinteger––
NameTypeReqDescription
resultarrayyes–

No examples provided.

get_connection_info ~40

Report which instrument is connected (identity, address, simulated or real), whether the server is read-only, and the active safety limits. Call this first.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

get_device_info ~57

Read the device's identity (manufacturer, model, serial, firmware), the standard health services it exposes and its features. Features include the body sensor location, supported oximeter / blood-pressure status flags, scale resolution and thermometer site.

Input schema present but exposes no named parameters.

NameTypeReqDescription
addressstringyes–
featuresobjectyesDecoded feature characteristics (sensor location, supported flags, resolutions)
firmware_revision–––
hardware_revision–––
manufacturer–––
model–––
serial–––
servicesarrayyesStandard Bluetooth SIG services found on the device
software_revision–––
system_id–––
timestampstringyes–

No examples provided.

read_battery ~25

Read the device's battery level (Battery Service, 0-100 %).

Input schema present but exposes no named parameters.

NameTypeReqDescription
addressstringyes–
battery_pctintegeryesBattery Level characteristic (0-100 %)
timestampstringyes–

No examples provided.

read_pulse_oximetry ~176

Read SpO2 (%) and pulse rate from a pulse oximeter, averaged over a few seconds or as a single spot-check reading. Continuous mode listens for `duration_s` and returns the latest valid values plus mean/min; spot-check mode waits for the oximeter's single stable reading. Early packets are often NaN while the sensor acquires; these are counted in `unavailable_samples`, never reported as values.

NameTypeReqDescription
duration_snumber–Continuous mode: seconds to average over
modestring–auto: connect, then continuous if the oximeter supports it, else wait for a spot-check. spot_check: wait for a reading even if the oximeter is not advertising yet
timeout_snumber–Spot-check mode: seconds to wait
NameTypeReqDescription
addressstringyes–
device_sensor_statusarrayyesDevice and Sensor Status flags of the latest packet
device_timestamp–yesDevice clock time of a spot-check measurement
malformed_packetsinteger–Packets that could not be decoded (skipped)
measurement_statusarrayyesMeasurement Status flags of the latest packet
modestringyescontinuous (PLX Continuous Measurement) or spot_check
pulse_amplitude_index_pct–yes–
pulse_rate_bpm–yesLatest valid pulse rate
pulse_rate_mean_bpm–yes–
samplesintegeryes–
spo2_mean_pct–yes–
spo2_min_pct–yes–
spo2_pct–yesLatest valid SpO2
timestampstringyes–
unavailable_samplesintegeryesPackets whose SpO2 or PR was a special value (NaN, NRes, ...)

No examples provided.

read_temperature ~87

Wait for a thermometer to send a temperature measurement and return it in °C. °F readings are converted; the measurement site is included if the device reports one.

NameTypeReqDescription
accept_intermediateboolean–If no final measurement arrives before the timeout, return the latest Intermediate Temperature value (probe still settling) instead of an error
timeout_snumber–Seconds to wait for a measurement
NameTypeReqDescription
addressstringyes–
device_timestamp–yes–
finalbooleanyesFalse if this is an Intermediate Temperature (probe still settling)
measurement_site–yes–
other_measurements_carrayyes–
received_atstringyes–
special_value–yes–
temperature_c–yes–
unit_reportedstringyes'C' or 'F' as sent by the device
value_reported–yes–

No examples provided.

read_weight ~64

Wait for a scale to send a weight measurement (kg), with BMI and height if the scale sends them. Ask the person to step on the scale after calling this. lb readings are converted to kg.

NameTypeReqDescription
timeout_snumber–Seconds to wait for a measurement
NameTypeReqDescription
addressstringyes–
bmi_kg_m2–yes–
device_timestamp–yes–
height_m–yes–
notesarrayyes–
other_measurements_kgarrayyes–
received_atstringyes–
scale_resolution_kg–yes–
unit_reportedstringyes'kg' or 'lb' as sent by the scale
user_id–yes–
value_reported–yes–
weight_kg–yesNone if the scale reported 'measurement unsuccessful'

No examples provided.

reconnect ~35

Close and re-open the connection to the instrument (e.g. after it was power cycled or a cable was re-plugged).

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

record_heart_rate ~124

Record heart rate for `duration_s`: bpm series, RR intervals and time-domain HRV (mean HR, SDNN, RMSSD, pNN50). The sensor must be worn with good skin contact. HRV statistics are for research, not clinical ECG analysis. Use `save_path` to keep every packet as CSV.

NameTypeReqDescription
duration_snumber–Recording length in seconds
max_pointsinteger–Max points returned per series
save_path––Optional new .csv file for the full recording (never overwrites a file)
NameTypeReqDescription
addressstringyes–
bpm_max–yes–
bpm_mean–yes–
bpm_min–yes–
bpm_seriesarrayyesReported heart rate (downsampled to max_points)
disconnected_earlybooleanyes–
duration_snumberyes–
energy_expended_kj–yesLast cumulative energy expended reported by the sensor
hrvobjectyes–
malformed_packetsintegeryes–
notesarrayyes–
notificationsintegeryes–
rr_intervals_downsampledbooleanyes–
rr_intervals_msarrayyesRR intervals in ms (downsampled to max_points if longer)
saved_to–yes–
sensor_contact_pct–yesShare of packets with skin contact (None if unsupported)
started_atstringyes–

No examples provided.

scan_devices ~111

Scan for nearby Bluetooth LE devices: address, name, signal strength and advertised health services. Works without a configured --address. Devices only show up while advertising (monitors often advertise only right after a measurement), and some do not list every service in their advertisement, so `service` filtering can miss them.

NameTypeReqDescription
name_contains––Case-insensitive name filter
servicestring–Only list devices advertising this service
timeout_snumber–How long to listen for advertisements
NameTypeReqDescription
devicesarrayyes–
notestringyes–
scanned_snumberyes–
service_filterstringyes–
timestampstringyes–

No examples provided.

wait_for_blood_pressure ~94

Wait for a blood pressure monitor to send a measurement: systolic, diastolic and mean arterial pressure (mmHg) and pulse rate. Call this, then ask the participant to start a measurement on the monitor. kPa readings are converted to mmHg; the unit sent is reported. Older stored readings are listed separately.

NameTypeReqDescription
timeout_snumber–Seconds to wait for a measurement
NameTypeReqDescription
addressstringyes–
cuff_pressure_updatesintegeryes–
device_timestamp–yesMeasurement time from the device clock (device local time)
diastolic_mmhg–yes–
max_cuff_pressure_mmhg–yes–
mean_arterial_mmhg–yes–
measurement_statusarrayyes–
other_measurementsarrayyesOlder stored measurements received in the same session (oldest first)
pulse_rate_bpm–yes–
received_atstringyes–
special_valuesarrayyesFields the device reported as NaN / NRes / INF
systolic_mmhg–yes–
unit_reportedstringyesUnit the device used (kPa values are converted to mmHg)
user_id–yes–

No examples provided.

Common questions

What is the Bluetooth LE Health Sensors MCP server?

Bluetooth LE Health Sensors is an MCP server listed in the public MCP registry as io.github.K-Dense-AI/labmcp-ble-health. MCP server for Bluetooth LE health sensors (standard GATT profiles). This page covers its PyPI package (labmcp-ble-health).

Is the Bluetooth LE Health Sensors MCP server safe to use?

Bluetooth LE Health Sensors scores 67 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 30 September 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Bluetooth LE Health Sensors MCP server expose?

Bluetooth LE Health Sensors exposes 11 tools: get_connection_info, get_command_log, reconnect, scan_devices, get_device_info, and 6 more. Their descriptions and schemas cost roughly 859 tokens of context every time the server is loaded.

Is the Bluetooth LE Health Sensors MCP server still maintained?

Bluetooth LE Health Sensors is still listed as active in the MCP registry. We last reached this channel on 30 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Bluetooth LE Health Sensors MCP server under?

Bluetooth LE Health Sensors declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.