Provides tools for querying Docker container status, including name, image, state, health, uptime, and port mappings from a local Docker daemon.
Allows querying Grafana alert states via the Prometheus-style rules API, returning alerts grouped by state with details like name, folder, health, last evaluation, and annotations.
Enables executing Flux queries against a local InfluxDB v2 instance, returning parsed CSV records up to 500 rows (requires InfluxDB token and org environment variables).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-it-ops show me all running containers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that exposes homelab and IT-ops tools to Claude. Designed to grow tool-by-tool, starting with what's actually testable on a Linux homelab and extending toward AD / Intune / M365 when a corporate test environment is available.
Status: v0.0.5 (2026-04-19) — 8 working tools, 37 pytest tests, CI green on Python 3.10/3.11/3.12. Tools split into category modules under
tools/. Locally tested on niborserver. Not yet on PyPI; install from source.
Once installed and connected to Claude (Desktop or Code), Claude can call:
Tool | What it does |
| Local host's hostname, uptime, 1-min load, memory %, root-disk %, and running container count. Reads |
| Queries the Grafana Prometheus-style rules API and returns alerts grouped by state (firing / pending / inactive / no_data / error) with name, folder, health, last evaluation, annotations. |
| Profit, win rate, open trade count, balance from a freqtrade REST API. Bot name resolved via config. |
| Full |
| Loki LogQL |
| NVMe/SATA SMART health via |
| Reads |
| Executes a Flux query against the local InfluxDB v2 and returns parsed CSV records (capped at 500 rows). Auth via |
Related MCP server: log-analyzer-mcp
get_uptime_kuma_status — pull monitor states via Uptime Kuma API
HTTP transport so openclaw / other tailnet peers can query niborserver-resident tools (currently stdio only)
Eventually: get_ad_user, get_intune_compliance, get_m365_service_health — when a corporate test environment is available
git clone https://github.com/bastiaan365/mcp-it-ops.git
cd mcp-it-ops
python3 -m venv .venv
.venv/bin/pip install -e .Copy the example and customise:
cp config/settings.example.yaml config/settings.yaml
# Edit config/settings.yaml — point at your Grafana, freqtrade bots, etc.Secrets come from environment variables, never from the YAML. Default env var names:
Env var | What |
| Grafana admin password (referenced from |
| freqtrade bot1 API basic auth |
| freqtrade bot2 API basic auth |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS, or %APPDATA%/Claude/claude_desktop_config.json on Windows:
{
"mcpServers": {
"it-ops": {
"command": "/path/to/mcp-it-ops/.venv/bin/mcp-it-ops",
"env": {
"GRAFANA_PASSWORD": "your-grafana-password",
"MCP_IT_OPS_CONFIG": "/path/to/mcp-it-ops/config/settings.yaml"
}
}
}
}Restart Claude Desktop. The tools appear under "it-ops".
GRAFANA_PASSWORD=... .venv/bin/python -c "
from mcp_it_ops.server import get_system_health, get_grafana_alert_state
import json
print(json.dumps(get_system_health(), indent=2))
print(json.dumps(get_grafana_alert_state().get('summary'), indent=2))
"Or use the official MCP inspector:
.venv/bin/python -m mcp dev src/mcp_it_ops/server.pyPython 3.10+
mcp>=1.27.0, httpx>=0.27, pyyaml>=6.0 (auto-installed)
Read access to /proc, df, docker ps for get_system_health
Network reach + credentials for the services you want tools for
src/mcp_it_ops/server.py — all tool definitions
tests/ — pytest tests; one file per tool (TODO: backfill)
config/settings.example.yaml — committed template; config/settings.yaml is gitignored
When adding a tool: see CLAUDE.md for the workflow + design conventions.
MIT
Report on the niborserver backup pipeline's last run.
Reads /var/log/niborserver-backup.log and reports: last_run_started, last_run_completed, last_run_duration_seconds, last_run_size, last_run_succeeded.
Returns {"error": ...} if the log doesn't exist (backup not yet run).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the data source (log file), the specific fields reported, and error case when log is missing. Sufficiently transparent for a read-only status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, field list, error case. No wasted words, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an implicitly defined output schema via the field list, the description is complete. Sibling tools provide context. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially. Baseline score of 4 is appropriate as description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reports on the last run of the niborserver backup pipeline, lists specific fields returned, and mentions error behavior. Distinct from sibling tools which target different systems (container, freqtrade, grafana, smartd, system health, influxdb, loki).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use or not use this tool versus alternatives, but the sibling context makes it clear this is for backup status. Implicit usage guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return structured docker-ps output: per-container name, image, state, status, ports, age.
Shells out to docker ps with a tab-separated format string. Returns a list of containers plus a summary dict. Read-only — does not stop/restart anything.
Returns {"error": "..."} if docker isn't installed or the docker socket is unreachable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it shells out to docker ps with a specific format string, returns a list and summary, is read-only, and provides error handling for missing docker or socket issues. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that cover purpose, implementation, and safety. No unnecessary words; all sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the presence of an output schema, the description adequately covers tool behavior, error handling, and what is returned. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter-level meaning. Baseline 4 applies as no additional parameter info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns structured docker-ps output with specific fields (name, image, state, status, ports, age). It uses a specific verb 'Return' and resource 'docker-ps output', distinguishing it from sibling tools like get_backup_status or get_system_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is read-only and does not stop/restart containers, providing a usage constraint. However, it does not explicitly state when to use this tool versus siblings, though the context of container inspection is implied by the output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query a freqtrade bot's REST API for its current trading state.
bot_name must match a key under freqtrade.bots in config (e.g. 'steady', 'fun'). Reads basic-auth credentials from the env vars named in user_env / pass_env on the bot's config entry.
Returns a dict with: bot_name, dry_run, strategy, timeframe, exchange, closed_trade_count, open_trade_count, realised_p_and_l_fiat, realised_p_and_l_pct, total_p_and_l_fiat, total_p_and_l_pct, win_rate, open_positions (list of {pair, opened, current_pnl_fiat, current_pnl_pct}).
Returns {"error": "..."} on any failure (unknown bot, missing creds, API down).
| Name | Required | Description | Default |
|---|---|---|---|
| bot_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return dict structure, error handling, and credential source. No side effects mentioned, but it's a read-only query, adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet detailed, structured into purpose, config details, return format, and error handling. Front-loaded with the action, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (though not shown), the description compensates by detailing the return dict and error states. For a single-parameter tool with no annotations, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains bot_name: it must match a key in config, with examples ('steady', 'fun'). This adds essential meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries a freqtrade bot's REST API for its current trading state, with a specific verb and resource (query trading state). It distinguishes from sibling tools like get_backup_status by explicitly naming 'freqtrade bot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: bot_name must match a key in config, credentials from env vars, and error handling. It does not explicitly contrast with alternatives, but the specificity makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Grafana alert rules with their current state.
Queries the Grafana Prometheus-style rules API. Reads credentials from the config (Grafana URL + user) and from the env var named in grafana.password_env (defaults to GRAFANA_PASSWORD). Returns a dict with alerts grouped by state (firing/pending/inactive/no_data/error).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that the tool queries the Grafana Prometheus-style API, reads credentials from config and an environment variable, and returns a dict grouped by state. This provides good insight into behavior, though it could mention network dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line summary followed by two detail sentences. Every sentence adds value with no wasted words. The structure is front-loaded, immediately stating the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the existence of an output schema, the description explains the return value format (dict grouped by state) and credential setup. It is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description does not need to add parameter information, and it does not detract from completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List Grafana alert rules with their current state', specifying the verb (list), resource (Grafana alert rules), and scope (current state). This distinguishes it from sibling tools which deal with backups, containers, freqtrade, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Usage is implied by the tool's unique function, but no guidance on exclusions or when-not-to-use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query SMART health for a storage device via smartctl.
device: /dev/nvme0n1, /dev/sda, etc. Default is niborserver's NVMe. Returns: overall_health, critical_warning, temperature_c, available_spare_pct, percentage_used_pct, power_on_hours, unsafe_shutdowns, media_errors.
Requires sudo (smartctl needs raw device access). Returns {"error": ...} if smartctl isn't installed or sudo isn't permitted (the calling user must have NOPASSWD sudo for smartctl OR the MCP server must run as root).
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | /dev/nvme0n1 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description clearly discloses behavioral traits: requires sudo, returns error if smartctl not installed or sudo not permitted, and outlines return fields. It provides enough context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action, uses multiple sentences efficiently, and each sentence adds value. Slightly verbose but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and an existing output schema (though not provided), the description covers prerequisites, return fields, and error conditions. It is sufficiently complete for a simple health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'device' has a default and examples of valid values (nvme0n1, sda) in the description, adding meaning beyond the schema. Schema coverage is 0% but the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query SMART health for a storage device via smartctl.' It gives specific examples of devices and distinguishes itself from sibling tools like 'get_system_health' by focusing on SMART data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. It mentions the default device and sudo requirements, but lacks guidance on when not to use it or which sibling tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report local system health: disk, memory, load, uptime, container count.
Reads from /proc and shells out to df, uptime, docker ps. Designed for the host the MCP server runs on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data sources (/proc, df, uptime, docker ps) and scope (local host), providing important behavioral context beyond the lack of annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff. Every sentence provides essential information about metrics, implementation, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is complete: it explains what the tool does, how it works, and its intended scope. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline score of 4 applies; description adds no parameter information because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reports system health metrics (disk, memory, load, uptime, container count) with a specific verb and resource, and distinguishes from sibling tools which focus on specific subsystems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is designed for the local host the MCP server runs on, indicating scope. However, does not explicitly mention when to use vs. alternatives like get_container_status or get_backup_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a Flux query against the local InfluxDB and return parsed records.
flux: Flux query string. The bucket is NOT auto-substituted — include
from(bucket:"<bucket>") |> range(start: -1h) |> ... yourself.
bucket: name surfaced in the response for context (does not modify the query).
Reads InfluxDB URL from config (influxdb.url, default localhost:8086) and the
org + token from the env vars named in influxdb.org_env / influxdb.token_env
(default INFLUXDB_ORG / INFLUXDB_TOKEN).
Returns: {bucket, row_count, columns, records (list of dicts), truncated_at}.
Records are capped at 500 rows to keep Claude's context manageable; if more
were returned, truncated_at: 500 appears in the response.
Returns {"error": "..."} on missing token, network failure, or Flux syntax error.
| Name | Required | Description | Default |
|---|---|---|---|
| flux | Yes | ||
| bucket | No | monitoring |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: reads config and env vars, returns specific structure, caps records at 500, error handling details. This provides complete transparency for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs and front-loaded purpose. It is slightly verbose but every sentence adds value; minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (database query), the description covers input, configuration, output schema, row limit, and error responses. It is complete and enables correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds essential meaning for both parameters: explains flux query requirements and example, clarifies bucket is only for context. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('Flux query against the local InfluxDB'), and distinguishes from sibling tools like query_loki_logs by focusing on InfluxDB metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage instructions (e.g., bucket not auto-substituted, example query format, config/env variable setup). It implicitly differentiates from siblings (InfluxDB vs Loki) but lacks explicit when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search container/syslog logs via Loki LogQL.
query: LogQL query string, e.g. '{container="grafana"}' or '{container=~".+"} |= "ERROR"' since: how far back, e.g. '1h', '30m', '7d' (Loki duration syntax) limit: max log lines to return (Loki default = 100, hard-capped here at 1000)
Returns a dict with: total_streams, total_lines, streams (list of {labels, lines}). Lines are timestamp-sorted oldest-first. Returns {"error": "..."} on Loki unreachable or invalid query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| since | No | 1h |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations given, but description fully covers behavior: return format, sorting, error handling, hard cap on limit. Discloses all relevant traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and informative, though could be slightly trimmed without losing clarity. Every sentence provides useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, all parameters, return format, and error conditions. Appropriate for a tool with input schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains each parameter with examples, defaults, and constraints. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it searches container/syslog logs via Loki LogQL. Clearly different from sibling tools which are status queries or InfluxDB queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples and parameter details. Implicitly distinguishes from siblings by focusing on log searching, but lacks explicit when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.5get_backup_statusget_container_statusget_freqtrade_bot_statusget_grafana_alert_stateget_smartd_healthget_system_healthquery_influxdb_fluxquery_loki_logsScored across 8 tools
Each tool targets a clearly distinct subsystem (backup, docker, freqtrade, grafana, smartd, system, influxdb, loki). No two tools overlap in purpose; descriptions are detailed and unambiguous.
All tools follow a consistent verb_noun lowercase snake_case pattern. 'get_' is used for status/health retrieval and 'query_' for log/database queries, which is a sensible and predictable distinction.
8 tools is an ideal size for an IT operations server. It covers all essential monitoring domains without being overwhelming or sparse.
The tool surface covers key IT ops areas (health, docker, backups, alerts, logs) well. Minor gaps exist (e.g., network status, CPU temperature) but do not hinder common workflows.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Monitoring + status pages set up by talking to Claude. Auto-detects 30+ SDKs and your URLs.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.