Which integrations are available for this server?

Provides tools for analyzing Google Fit exported data from Google Takeout, including daily activity metrics (steps, calories, active minutes, distance), workout sessions, sleep records, and raw fitness file parsing, along with resources and prompts for fitness progress analysis and coaching.

How do I use mcp-takeout-googlefit?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-takeout-googlefit What were my total steps last week?" 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-takeout-googlefit

by tskxz

Overview Schema Source Related Servers Discussions Admin

Python

Local

Servidor MCP para Google Fit (Google Takeout)

Este projeto contém um Servidor MCP (Model Context Protocol) modular desenvolvido em Python com a biblioteca FastMCP. O servidor descompacta, lê, filtra e analisa automaticamente as pastas exportadas do Google Fit (extraídas do Google Takeout em Português) colocadas na pasta ./data.

Estrutura Modular do Projeto

cli_project/
├── data/                                # Ignorada no .gitignore (dados privados)
│   ├── Atividades/                      # Ficheiros de registo de treinos e sessões
│   ├── Métricas de atividade diária/   # Ficheiros de passos, calorias e minutos ativos
│   ├── Todas as sessões/               # Histórico completo de sessões de exercício
│   └── Todos os dados/                  # Ficheiros JSON derived_com.google.*
├── src/                                 # Pacote Python com arquitetura modular
│   ├── models/                          # Schemas e estruturas de dados Pydantic
│   │   └── fitness_schemas.py
│   ├── parsers/                         # Parsers de ficheiros (ZIP, CSV, JSON)
│   │   ├── zip_extractor.py
│   │   ├── csv_parser.py
│   │   └── json_parser.py
│   ├── services/                        # Regras de negócio e agregação de dados
│   │   └── fitness_service.py
│   ├── server/                          # Componentes registados no FastMCP
│   │   ├── tools.py                     # Definição das Ferramentas (@mcp.tool)
│   │   ├── resources.py                 # Definição dos Recursos (@mcp.resource)
│   │   └── prompts.py                   # Definição dos Prompts (@mcp.prompt)
│   └── app.py                           # Inicialização e configuração do FastMCP
├── mcp_server.py                        # Ponto de entrada leve do Servidor MCP
├── pyproject.toml                       # Configuração e dependências
├── .gitignore                           # Proteção dos seus dados privados (data/)
└── README.md                            # Documentação de integração

Related MCP server: garmin-mcp

Instalação

Criar e ativar o ambiente virtual:

uv venv
.venv\Scripts\activate
uv pip install -e .

Como Integrar o Servidor MCP em Qualquer IA

Adicione o servidor no ficheiro de configuração MCP do seu cliente de IA (mcp_config.json ou claude_desktop_config.json):

{
  "mcpServers": {
    "google-fit-server": {
      "command": "uv",
      "args": [
        "run",
        "mcp_server.py"
      ]
    }
  }
}

Como Testar no MCP Inspector

Para testar o servidor e inspecionar as pastas do Google Fit no ambiente gráfico de desenvolvimento:

uv run mcp dev mcp_server.py

Guia Detalhado de Utilização dos Componentes MCP

1. Ferramentas (Tools)

As ferramentas permitem que os assistentes de IA executem funções de consulta e manutenção de dados.

`clean_empty_data_files`

Descrição: Analisa e deteta ficheiros JSON ou CSV na pasta ./data que contêm zero pontos de dados ou apenas valores vazios "".
Parâmetros:
- dry_run (boolean, opcional, padrão: true): Se true, apenas lista os ficheiros vazios sem apagar. Se false, elimina fisicamente os ficheiros vazios do disco.
Exemplos de Valores e Chamadas:
- Simulação (listar sem apagar): clean_empty_data_files(dry_run=true)
- Eliminação física: clean_empty_data_files(dry_run=false)

`scan_google_fit_data`

Descrição: Percorre a pasta ./data, deteta as pastas exportadas (Atividades, Métricas de atividade diária, Todas as sessões, Todos os dados) e devolve uma contagem das pastas e ficheiros válidos.
Parâmetros: Nenhum argumento necessário.
Exemplo de Chamada: scan_google_fit_data()

`get_daily_activity`

Descrição: Extrai registos diários de contagem de passos (step_count), calorias despendidas (calories.expended), minutos ativos (active_minutes) e distância percorrida, ignorando ficheiros vazios.
Parâmetros: Nenhum argumento necessário.
Exemplo de Chamada: get_daily_activity()

`get_workout_logs`

Descrição: Extrai sessões de treino, exercícios e segmentos de atividade física a partir das pastas Atividades e Todas as sessões.
Parâmetros: Nenhum argumento necessário.
Exemplo de Chamada: get_workout_logs()

`get_sleep_records`

Descrição: Extrai registos e horários de sono dos ficheiros derived_com.google.internal.sleep.
Parâmetros: Nenhum argumento necessário.
Exemplo de Chamada: get_sleep_records()

`read_fitness_file`

Descrição: Lê e interpreta o conteúdo bruto ou parseado de qualquer ficheiro localizado na pasta ./data.
Parâmetros:
- file_path (string, obrigatório): Caminho relativo do ficheiro dentro da pasta ./data.
Exemplos de Valores de Parâmetro:
- file_path="Métricas de atividade diária/Daily activity metrics.csv"
- file_path="Todos os dados/derived_com.google.step_count.delta_com.google.android.fit.json"
- file_path="Atividades/Atividades.csv"
Exemplo de Chamada: read_fitness_file(file_path="Métricas de atividade diária/Daily activity metrics.csv")

2. Recursos e Templates de Recursos (Resources & Resource Templates)

Os recursos fornecem aos assistentes de IA leitura direta de dados através de URIs padrão.

`fitness://summary` (URI Direta)

Descrição: Devolve um resumo executivo em JSON com o estado da ligação, total de ficheiros e ficheiros válidos detetados.
Exemplo de URI de Acesso: fitness://summary

`docs://documents` (URI Direta)

Descrição: Devolve uma lista JSON com os caminhos de todos os ficheiros disponíveis na pasta ./data.
Exemplo de URI de Acesso: docs://documents

`docs://documents/{doc_id}` (Template de Recurso)

Descrição: Template de URI parametrizado para aceder ao conteúdo de qualquer ficheiro individual.
Parâmetro do Template: {doc_id} (Caminho relativo do ficheiro).
Exemplos de URIs Completas para Acesso:
- docs://documents/Métricas de atividade diária/Daily activity metrics.csv
- docs://documents/Todos os dados/derived_com.google.calories.expended.json
- docs://documents/Todas as sessões/Sessões.csv

3. Prompts

Os prompts são rotinas de análise pré-definidas que orientam a IA para tarefas específicas de coaching e análise.

`analyze_progress`

Descrição: Orienta a IA a analisar a evolução de passos, distância, minutos ativos e calorias.
Parâmetros:
- period (string, opcional, padrão: "all"): Período temporal de análise.
Exemplos de Valores de Parâmetro: "7_dias", "30_dias", "tudo"
Exemplos de Utilização no Cliente de IA:
- /analyze_progress period="7_dias"
- /analyze_progress period="30_dias"

`generate_workout_plan`

Descrição: Orienta a IA a criar um plano semanal de treinos e descanso adaptado ao histórico de atividades do utilizador.
Parâmetros:
- fitness_goal (string, opcional, padrão: "fitness_geral"): Objetivo de treino pretendido.
Exemplos de Valores de Parâmetro: "hipertrofia", "perda_peso", "resistencia"
Exemplos de Utilização no Cliente de IA:
- /generate_workout_plan fitness_goal="hipertrofia"
- /generate_workout_plan fitness_goal="perda_peso"

`give_coaching_feedback`

Descrição: Orienta a IA a fornecer comentários e recomendações práticas diárias sobre o nível de atividade física e qualidade de sono.
Parâmetros:
- date (string, opcional, padrão: "mais_recente"): Data alvo para avaliação.
Exemplos de Valores de Parâmetro: "hoje", "mais_recente", "2026-08-05"
Exemplos de Utilização no Cliente de IA:
- /give_coaching_feedback date="hoje"
- /give_coaching_feedback date="2026-08-05"

Available Tools

6 tools

clean_empty_data_filesA

Identifica e limpa ficheiros JSON/CSV sem pontos de dados válidos na pasta ./data

ParametersJSON Schema

Name	Required	Description	Default
`dry_run`	No	Se True, apenas lista ficheiros vazios. Se False, elimina os ficheiros vazios.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. 'Limpa' (cleans) is vague and does not explicitly state that files are deleted. The schema parameter 'dry_run' reveals deletion when false, but the tool description itself fails to mention the destructive nature or any safety details, leaving the agent to infer behavior.

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

Conciseness5/5

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

The description is a single, concise sentence that front-loads the main purpose and key details (file types, directory, criterion). Every word earns its place with no redundancy.

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

Completeness4/5

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

For a simple tool with one parameter and an output schema, the description provides adequate context: file types, target directory, and the criterion for 'empty'. The only weakness is the lack of explicit mention of deletion, but the schema partially compensates and the tool is not complex.

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

Parameters3/5

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

Schema coverage is 100%: the single parameter dry_run has a clear description explaining list vs. delete behavior. The tool description itself adds no parameter-level information, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's function: identifies and cleans JSON/CSV files without valid data points in the ./data directory. The verb 'identifica e limpa' is specific, the resource (JSON/CSV files) is explicit, and it is clearly distinguished from sibling tools which are all about reading/scanning fitness data.

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

Usage Guidelines3/5

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

The description implies the usage context (cleaning data files) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. However, the tool's purpose is sufficiently distinct from siblings, so the lack of explicit guidance is a moderate gap.

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

get_daily_activityA

Extrai o total de passos, calorias, minutos ativos e distância das métricas diárias, ignorando ficheiros vazios

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It transparently discloses that the tool extracts summarized metrics and specifically 'ignores empty files', which is a useful behavioral trait. It does not mention side effects or permissions, but as a read-only data retrieval tool, this is adequate.

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

Conciseness5/5

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

The description is a single, concise sentence that front-loads the primary action and includes a relevant caveat ('ignoring empty files'). Every word earns its place with no redundancy or unnecessary detail.

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's simplicity (0 parameters) and the presence of an output schema, the description is complete enough for an agent to understand its purpose and behavior. It covers what is extracted and a key edge case, and the output schema handles return value details.

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

Parameters4/5

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

The tool has zero parameters, which sets a baseline of 4. The description adds meaning by explaining what data will be returned (steps, calories, active minutes, distance), going beyond the empty schema. Since there are no parameters, no parameter-level clarification is needed.

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

Purpose5/5

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

The description clearly states the verb 'Extrai' (extracts) and specifies the resource: daily activity metrics including steps, calories, active minutes, and distance. This distinguishes it from sibling tools like get_workout_logs and get_sleep_records, which focus on different data types.

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?

The description provides clear context for when to use the tool (to retrieve daily activity totals) but does not explicitly mention alternatives or when not to use it. It implies usage for daily metrics, which is a sufficient context signal given the sibling tool names.

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

get_sleep_recordsA

Extrai dados e horários de sono a partir dos ficheiros derived_com.google.internal.sleep, ignorando ficheiros vazios

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose a behavioral trait: ignoring empty files. However, it does not mention read-only nature, return format, pagination, or any side effects. The description adds some value but leaves significant behavioral context undisclosed.

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

Conciseness5/5

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

The description is a single, concise sentence that front-loads the core action. Every word earns its place, providing essential information about the source and the empty-file filtering without unnecessary padding.

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

Completeness4/5

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

Given the tool has no parameters and an output schema exists (so return values need not be described), the description is reasonably complete. It specifies the source file and a key processing detail. It could mention broader usage context, but for a simple extraction tool, it covers the essentials.

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

Parameters4/5

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

The tool takes zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and per the baseline for 0-param tools, a score of 4 is appropriate. The description adds no parameter-specific semantics but none are needed.

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

Purpose5/5

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

The description clearly states the tool extracts sleep data and schedules from the specific derived_com.google.internal.sleep files. It uses a specific verb ('extrai') and resource, and the sibling tools (get_daily_activity, get_workout_logs) indicate this is the sleep-specific option, distinguishing it from alternatives.

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

Usage Guidelines3/5

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

The description implies usage for retrieving sleep data from a specific source, but does not explicitly state when to use this tool over siblings or provide exclusions. There is no mention of alternatives or contextual guidance beyond the source file, so the usage context is only implied.

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

get_workout_logsA

Extrai registos das pastas Atividades, Todas as sessões e segmentos de atividade física, ignorando ficheiros vazios

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The description adds a behavioral detail beyond the name: it ignores empty files and specifies which folders are scanned. However, with no annotations, it does not disclose output format or other behavioral aspects, though the read-only nature is implied by 'get'.

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

Conciseness5/5

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

The description is a single concise sentence that efficiently conveys the tool's function and a key behavioral detail. Every word earns its place.

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

Completeness4/5

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

For a parameterless read tool with an output schema, the description is adequately complete: it identifies the source folders and empty-file handling. It lacks usage guidance, but that is a minor gap given the simplicity of the tool.

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

Parameters4/5

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

The tool has zero parameters, so the schema trivially covers 100% of parameters. The baseline for 0 params is 4; the description does not need to explain parameters.

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

Purpose5/5

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

The description uses a specific verb 'Extrai' (extracts) and identifies a precise resource: records from folders 'Atividades', 'Todas as sessões e segmentos de atividade física'. This clearly distinguishes the tool from siblings like get_sleep_records or get_daily_activity.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus alternatives. There are no explicit when-to-use/when-not-to-use instructions or mentions of sibling tools.

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

read_fitness_fileA

Lê o conteúdo bruto ou parseado de qualquer ficheiro dentro da pasta ./data

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Caminho relativo do ficheiro dentro da pasta ./data

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses that it reads raw or parsed content and restricts to the ./data folder, which is a useful behavioral trait. However, it does not mention error behaviors (e.g., missing files, binary content) or permissions, and with no annotations provided, the description carries the full burden for behavioral disclosure. The existence of an output schema mitigates some return-value ambiguity.

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

Conciseness5/5

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

The description is a single, concise sentence that directly communicates the tool's purpose without extraneous detail. It is front-loaded and every word earns its place.

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

Completeness4/5

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

For a simple file-read tool, the description and schema provide sufficient context for an agent to invoke it correctly. The output schema covers return values, and the tool's scope is clearly limited to ./data. It lacks explicit usage comparisons with siblings, which is a minor gap, but overall it is adequately complete.

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

Parameters3/5

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

The schema description for file_path covers its meaning (relative path within ./data) completely, and the description only repeats this without adding additional nuance. Since schema coverage is 100%, the description adds no extra parameter semantics beyond the schema.

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

Purpose5/5

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

The description clearly states the tool reads raw or parsed content of any file inside ./data, with a specific verb ('Lê') and resource ('qualquer ficheiro dentro da pasta ./data'). This distinguishes it from sibling tools that focus on higher-level derived data (e.g., get_daily_activity), making its purpose unmistakable.

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

Usage Guidelines3/5

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

The description implies the tool is for accessing raw data files, which is distinct from the sibling tools, but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no guidance on when to prefer this over get_daily_activity or scan_google_fit_data, leaving the usage inference to the agent.

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

scan_google_fit_dataA

Percorre a pasta ./data, deteta as pastas exportadas do Google Fit (Atividades, Métricas de atividade diária, Todas as sessões, Todos os dados) e lista os ficheiros

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It explains the tool's behavior: scanning the ./data folder, detecting specific Google Fit export folder names, and listing files. This conveys a read-only, non-destructive operation. It does not explicitly say 'does not modify file contents' but 'lists the files' strongly implies a safe, scan-only action.

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?

The description is a single sentence that efficiently conveys the tool's purpose and scope. It is front-loaded with the action and location, and lists the specific export folder types. It is slightly verbose with the long list, but it earns its place by clarifying what is detected.

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

Completeness4/5

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

For a simple scan/list tool with zero parameters and an output schema present, the description is sufficiently complete. It details the folder detection logic and implies a read-only operation. The only missing element is an explicit connection to how the returned file list is used with sibling tools, but that is more of a usage guideline than a completeness gap.

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

Parameters4/5

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

The tool has zero parameters, so the baseline is 4. The description adds useful context about the folder structure and detection criteria, which is not captured by the empty input schema.

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

Purpose5/5

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

The description clearly states the tool's function: it scans the ./data folder, identifies Google Fit export folders (Activities, Daily activity metrics, All sessions, All data), and lists files. This specific verb+resource combination distinguishes it from sibling tools that read specific data types (e.g., get_daily_activity, read_fitness_file).

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

Usage Guidelines3/5

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

The description implies usage as a discovery step before reading specific files, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. The sibling tools are for reading, not scanning, so the use case is reasonably clear but lacks explicit guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Aug 5, 2026
- First observedclean_empty_data_files
- First observedget_daily_activity
- First observedget_sleep_records
- First observedget_workout_logs
- First observedread_fitness_file
- First observedscan_google_fit_data

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-05 20:15 across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: cleaning empty files, scanning directory structure, extracting daily activity, workout logs, sleep records, and reading any file. No overlapping functionality.

Naming Consistency5/5

All tool names follow the snake_case verb_noun pattern (clean, scan, get, get, get, read). Consistent and predictable naming.

Tool Count5/5

Six tools is well-scoped for a Google Fit Takeout processing server, covering both extraction and utility operations without being excessive.

Completeness5/5

The tool set covers the main Google Fit data types (daily metrics, workouts, sleep) plus scanning, cleaning, and arbitrary file reading. No obvious gaps for typical workflows.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Wellness Project AOAuth
ai.wellnessproject
Connect your health, fitness, nutrition, sleep, and wearable data to your AI assistant.
AI & Machine Learning Fitness Tracking Health & Wellness
7422
SomviaOAuth
app.somvia
Apple Health training load, recovery, HRV and workout detail for Claude, ChatGPT and any MCP client.
Health & Wellness Fitness Tracking
2
freddyOAuth
coach.freddy
Connect your wearables, rings and training apps, then ask your AI about your own health data.
Health & Wellness Fitness Tracking
2
FITsociety AOAuth
io.fitsociety
Access approved FITsociety clients, schedules, bookings and coaching data with AI assistants.
Fitness Tracking Health & Wellness Workplace & Productivity
21

Related MCP Servers

personal-fitbit-mcp-server
Health & Wellness Fitness Tracking
hiro-777-sky
A
license
A
quality
D
maintenance
Enables AI assistants to access and analyze Fitbit health data (activity, sleep, heart rate, weight, profile) via natural language through the Fitbit Web API.
Updated 6 months ago (2026-03-12 03:01 UTC)
7
MIT
garmin-mcp
Health & Wellness Fitness Tracking
shawnduggan
A
license
Not graded
quality
D
maintenance
Enables AI assistants to query live Garmin Connect health and fitness data, including daily metrics, activities, sleep analysis, and trends via natural language.
Updated 8 months ago (2026-01-04 23:36 UTC)
MIT
Apple Health Chat MCP
Health & Wellness Fitness Tracking
gh33k
F
license
B
quality
D
maintenance
Enables Claude to answer natural language questions about your Apple Health data by analyzing local CSV exports, supporting metrics like steps, heart rate, sleep, and more.
Updated a year ago (2025-10-21 11:00 UTC)
6
2
-
FitNotes MCP Server
Health & Wellness Fitness Tracking
makkoncept
F
license
Not graded
quality
D
maintenance
Enables analysis of FitNotes workout data through an LLM, providing insights on progress, muscle groups, and personalized recommendations.
Updated a year ago (2025-10-13 05:22 UTC)
3
-

Servidor MCP para Google Fit (Google Takeout)

Estrutura Modular do Projeto

Instalação

Como Integrar o Servidor MCP em Qualquer IA

Como Testar no MCP Inspector

Guia Detalhado de Utilização dos Componentes MCP

1. Ferramentas (Tools)

clean_empty_data_files

scan_google_fit_data

get_daily_activity

get_workout_logs

get_sleep_records

read_fitness_file

2. Recursos e Templates de Recursos (Resources & Resource Templates)

fitness://summary (URI Direta)

docs://documents (URI Direta)

docs://documents/{doc_id} (Template de Recurso)

3. Prompts

analyze_progress

generate_workout_plan

give_coaching_feedback

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`clean_empty_data_files`

`scan_google_fit_data`

`get_daily_activity`

`get_workout_logs`

`get_sleep_records`

`read_fitness_file`

`fitness://summary` (URI Direta)

`docs://documents` (URI Direta)

`docs://documents/{doc_id}` (Template de Recurso)

`analyze_progress`

`generate_workout_plan`

`give_coaching_feedback`