Skip to main content
Glama

fitbit_get_spo2

Access nightly SpO2 data from Fitbit by specifying a date range. Optionally fetch directly from the Fitbit API. Requires Fitbit Premium. Returns average, minimum, and maximum SpO2 percentages.

Instructions

Get nightly SpO2 (blood oxygen saturation) data.

Returns data from the local cache by default. Use live=True to fetch from Fitbit API. Run fitbit_sync first to populate the cache.

SpO2 data is sparse: only nights with on-wrist sleep tracking produce readings. Requires Fitbit Premium for access to this endpoint.

Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, fetch directly from Fitbit API instead of cache.

Returns one entry per night with avg, min, max SpO2 percentage. Normal range: 95-100%. Below 90% may indicate sleep apnea.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_dateNo
end_dateNo
liveNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main tool handler function `fitbit_get_spo2` - an async MCP tool decorated with @mcp.tool() and @require_auth. Accepts start_date, end_date, and live flag. Fetches SpO2 data either live from the Fitbit API via _fetch_live() or from local SQLite cache via db.query_spo2(). Returns JSON response with spo2 entries and count.
    @mcp.tool()
    @require_auth
    async def fitbit_get_spo2(
        start_date: str | None = None,
        end_date: str | None = None,
        live: bool = False,
    ) -> str:
        """Get nightly SpO2 (blood oxygen saturation) data.
    
        Returns data from the local cache by default. Use live=True to fetch
        from Fitbit API. Run fitbit_sync first to populate the cache.
    
        SpO2 data is sparse: only nights with on-wrist sleep tracking produce readings.
        Requires Fitbit Premium for access to this endpoint.
    
        Args:
            start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days.
            end_date: End date as "YYYY-MM-DD". Default: today.
            live: If true, fetch directly from Fitbit API instead of cache.
    
        Returns one entry per night with avg, min, max SpO2 percentage.
        Normal range: 95-100%. Below 90% may indicate sleep apnea.
        """
        start, end = parse_date(start_date, end_date, default_days=30)
    
        if live:
            entries = await anyio.to_thread.run_sync(lambda: _fetch_live(start, end))
        else:
            await anyio.to_thread.run_sync(lambda: auto_sync_if_stale("spo2"))
            def _query():
                conn = db.get_db()
                rows = db.query_spo2(conn, start.isoformat(), end.isoformat())
                conn.close()
                return rows
            entries = await anyio.to_thread.run_sync(_query)
    
        if not entries:
            return format_response({
                "message": "No SpO2 data found for this period.",
                "hint": "Try live=True to fetch directly from the API.",
            })
    
        return format_response({"spo2": entries, "count": len(entries)})
  • The _fetch_live() helper function that directly calls the Fitbit SpO2 API endpoint (/1/user/-/spo2/date/{start}/{end}.json), handles chunking via SPO2_MAX_RANGE_DAYS (30), normalises the API response, and returns sorted entries with date, avg, min, max fields.
    def _fetch_live(start_date, end_date) -> list[dict]:
        """Fetch SpO2 data directly from the API."""
        from ..config import SPO2_MAX_RANGE_DAYS
        results = {}
        d = start_date
        while d <= end_date:
            chunk_end = min(d + timedelta(days=SPO2_MAX_RANGE_DAYS - 1), end_date)
            path = f"/1/user/-/spo2/date/{d}/{chunk_end}.json"
            data = api.get(path)
            # API may return a list, a single dict, or {} (no data). Normalise to list.
            entries = data if isinstance(data, list) else [data]
            for entry in entries:
                ds = entry.get("dateTime")
                if not ds or "value" not in entry:
                    # Empty response ({}) or missing data - skip
                    continue
                results[ds] = {
                    "date": ds,
                    "avg": entry["value"].get("avg"),
                    "min": entry["value"].get("min"),
                    "max": entry["value"].get("max"),
                }
            d = chunk_end + timedelta(days=1)
        return sorted(results.values(), key=lambda x: x["date"])
  • Imports and module setup. The `@mcp.tool()` decorator on line 39 registers fitbit_get_spo2 as an MCP tool via the shared FastMCP instance imported from ..mcp_instance.
    """SpO2 (blood oxygen saturation) query tool."""
    
    from datetime import timedelta
    
    import anyio
    
    from ..mcp_instance import mcp
    from ..helpers import format_response, require_auth, parse_date
    from .. import api, db
    from .sync_tools import auto_sync_if_stale
  • Import of `mcp` from the shared FastMCP instance - used by the @mcp.tool() decorator to register the tool.
    from ..helpers import format_response, require_auth, parse_date
  • The shared FastMCP instance ('fitbit-mcp') that serves as the MCP server. The @mcp.tool() decorator on fitbit_get_spo2 registers the tool with this instance.
    """Shared FastMCP instance for the Fitbit MCP server."""
    
    from mcp.server.fastmcp import FastMCP
    
    mcp = FastMCP("fitbit-mcp")
Behavior4/5

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

With no annotations, the description fully carries the burden. It discloses caching behavior, sparse data condition (on-wrist sleep tracking), and premium requirement. No contradictions. Could mention rate limits, but overall thorough.

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

Conciseness4/5

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

Well-organized with clear sections. Front-loaded with main purpose. Not overly verbose, but could be slightly more concise without losing essential information.

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

Completeness5/5

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

Given the tool complexity (3 params, no annotations, output schema present), the description covers: purpose, usage methods, prerequisites, limitations, parameter details, and return value shape. It is complete and informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains all three parameters with formats, defaults, and behavior. start_date, end_date, and live are well-described, adding full meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get nightly SpO2 data' with a specific resource and verb. It also mentions cache vs live data and a prerequisite, making the purpose distinct. However, it does not explicitly differentiate from sibling tools like fitbit_get_heart_rate, but the resource is unique enough.

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

Usage Guidelines4/5

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

Provides explicit usage context: default cache vs live=True, prerequisite to run fitbit_sync, and requirement for Fitbit Premium. It lacks explicit when-not-to-use or alternative tools, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/partymola/fitbit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server