Skip to main content
Glama
Thecimal

Quantified Self MCP Server

Servidor MCP de Quantified Self

Un servidor local del Model Context Protocol (MCP) que permite a un LLM — p. ej. Claude Desktop — consultar tus datos personales de salud y finanzas. Todo se almacena en dos archivos SQLite locales y se lee directamente del disco mediante un proceso de Python que tú controlas. Sin base de datos en la nube, sin panel de control, sin servicios de terceros.

Qué incluye

quantified-self-mcp/
├── server.py              # the MCP server (FastMCP) — 2 tools
├── init_db.py              # loads a CSV file into the local SQLite database
├── requirements.txt
├── .gitignore              # keeps data/ and .db files out of version control
└── sample_data/
    ├── health_sample.csv   # 30 days of sample data, so you can try it immediately
    └── finance_sample.csv  # ~2 months of sample expenses

Al ejecutar init_db.py se crea una carpeta data/ junto a server.py que contiene health.db y finance.db; esa carpeta no está incluida aquí, ya que se genera en tu máquina a partir de tus propios datos.

Related MCP server: apple-health-mcp

Herramientas expuestas

Herramienta

Devuelve

Parámetros (todos opcionales)

read_health_data

Pasos diarios, horas de sueño, frecuencia cardíaca en reposo

start_date, end_date (ISO AAAA-MM-DD; por defecto, los últimos 30 días)

read_finance_data

Libro de gastos por categoría, con totales

start_date, end_date, category (por defecto, los últimos 90 días, todas las categorías)

Ambas herramientas devuelven las filas coincidentes más resúmenes calculados (promedios/mín/máx para salud, totales por categoría para finanzas), de modo que el modelo no tenga que hacer su propia agregación entre muchas filas.

1. Configurar el entorno

Requiere Python 3.10+.

cd quantified-self-mcp
python3 -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -r requirements.txt

2. Cargar tus datos

Pruébalo de inmediato con las muestras incluidas:

python init_db.py health  sample_data/health_sample.csv
python init_db.py finance sample_data/finance_sample.csv

Para usar tus propios datos, expórtalos a CSV con estas columnas y ejecuta los mismos comandos con tus archivos:

  • CSV de salud: date, steps, sleep_hours, resting_heart_rate

  • CSV de finanzas: date, category, amount, description (description es opcional)

Las fechas deben estar en formato ISO (2026-08-23); también se acepta MM/DD/AAAA y se convierte. Las cantidades/números pueden incluir $ y , (p. ej. $1.234,56) — se eliminan automáticamente. Una fila con un problema (fecha incorrecta, cantidad no numérica, categoría faltante, etc.) se omite con una advertencia en lugar de abortar toda la importación; la última línea impresa siempre te indica cuántas filas se cargaron frente a cuántas se omitieron.

Volver a ejecutar init_db.py health actualiza por fecha (es seguro re-ejecutarlo a medida que añades días); init_db.py finance añade filas nuevas cada vez, ya que un libro de gastos no tiene una clave única natural. Añade --replace a cualquiera de los dos comandos para vaciar la tabla primero.

3. (Opcional) probarlo de forma independiente

Antes de conectarlo a cualquier cliente, puedes abrir el MCP Inspector y llamar a las herramientas directamente en un navegador:

fastmcp dev inspector server.py

4. Conectarlo a Claude Desktop

Claude Desktop lanza servidores MCP locales como subprocesos y se comunica con ellos a través de stdio, según un archivo de configuración JSON:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Puedes ir directamente desde la aplicación: Ajustes → Desarrollador → Editar configuración.

Añade una entrada en mcpServers, usando rutas absolutas — es importante que command apunte al intérprete de Python dentro del entorno virtual que acabas de crear, no a un python a secas. Claude Desktop ejecuta los servidores en un entorno mínimo que no hereda de forma fiable el PATH de tu shell ni un venv activado, por lo que un "python" a secas suele resolverse al intérprete incorrecto (o a ninguno) y el servidor falla silenciosamente al iniciarse.

{
  "mcpServers": {
    "quantified-self": {
      "command": "/absolute/path/to/quantified-self-mcp/.venv/bin/python3",
      "args": ["/absolute/path/to/quantified-self-mcp/server.py"]
    }
  }
}

En Windows, normalmente es:

{
  "mcpServers": {
    "quantified-self": {
      "command": "C:\\absolute\\path\\to\\quantified-self-mcp\\.venv\\Scripts\\python.exe",
      "args": ["C:\\absolute\\path\\to\\quantified-self-mcp\\server.py"]
    }
  }
}

Guarda el archivo y, a continuación, cierra y vuelve a abrir Claude Desktop por completo (no basta con cerrar la ventana; es necesario reiniciar para cargar los cambios de configuración). Busca el icono de herramientas/martillo en el cuadro de chat para confirmar que quantified-self está conectado.

FastMCP también incluye un atajo CLI que edita este archivo por ti — fastmcp install claude-desktop server.py --name "Quantified Self" — merece la pena probarlo (ejecuta fastmcp install claude-desktop --help para ver las opciones actuales), pero el JSON manual anterior siempre funcionará y es más fácil de depurar si algo falla. Anthropic también tiene un formato de empaquetado más reciente de "Desktop Extension" con un solo clic para servidores MCP locales; no es necesario para un uso personal como este, pero conviene saber que existe si algún día quieres compartir este servidor con alguien menos cómodo editando JSON.

5. (Opcional) ejecutarlo en Docker / alojarlo en Glama

#5-optional-run-it-in-docker--host-it-on-glama

Se incluye un Dockerfile para quien quiera ejecutar esto en un contenedor en lugar de un venv local, incluido alojarlo en Glama, que compila directamente a partir del Dockerfile de un repositorio cuando está presente.

docker build -t quantified-self-mcp .
docker run -i --rm -v "$PWD/data:/app/data" quantified-self-mcp

La imagen es solo Python (python:3.12-slim + pip install -r requirements.txt); no hay Node.js en ningún lugar de este proyecto. HEALTH_DB_PATH y FINANCE_DB_PATH apuntan por defecto a /data/health.db y /data/finance.db dentro del contenedor, de modo que un volumen montado (p. ej. el montaje /data de Glama) conserve tus bases de datos entre redespliegues; consulta la sección de Configuración al principio de server.py para sobrescribirlos.

glama.json es intencionadamente mínimo — solo indica a Glama que use este repositorio; el Dockerfile es la fuente de verdad real sobre cómo se compila e inicia la imagen (python server.py, a través de stdio). Una versión anterior de glama.json intentaba configurar manualmente un buildpack genérico (una imagen base debian:trixie-slim desnuda más pasos de compilación manuales de pip install y cmdArguments) en lugar de usar un Dockerfile — esa imagen no tenía un intérprete de Python aprovisionado de forma fiable, y la plataforma acababa intentando ejecutar un punto de entrada de Node.js que no existe en este repositorio (Cannot find module '/app/server.js'). Incluir un Dockerfile elimina esa ambigüedad.

Modelo de privacidad — qué significa realmente "local"

Conviene ser precisos al respecto, ya que es el objetivo principal del proyecto:

  • Ambas bases de datos SQLite viven solo en tu disco, dentro de la carpeta data/ de este proyecto. El servidor no realiza llamadas de red, no tiene telemetría y no sincroniza nada en ningún sitio.

  • server.py abre ambas bases de datos en modo de solo lectura de SQLite (no es solo que "no emita escrituras" — la conexión es físicamente incapaz de hacerlo). Ni siquiera un prompt con errores o malintencionado puede conseguir que ninguna de las dos herramientas modifique tus datos; solo init_db.py, ejecutado por ti desde la terminal, escribe en ellas.

  • Cuando un cliente MCP llama a una de estas herramientas, las filas específicas devueltas para esa consulta pasan a formar parte de la conversación enviada al modelo que responda — ese es el mecanismo que usa MCP para dar información a un modelo. Si usas Claude Desktop con un modelo alojado, eso significa que la porción de datos sobre la que preguntes se envía a Anthropic para ese turno, igual que cualquier otra cosa que escribas en el chat.

  • Así que "local" aquí significa: tu conjunto de datos completo nunca se almacena ni se sincroniza en ninguna base de datos de terceros, y no se transmite nada a menos que se invoque realmente una herramienta — y, aun así, solo las filas que devuelve esa llamada concreta, no toda la base de datos. No significa totalmente sin conexión de extremo a extremo. Para eso necesitarías un runtime de modelo totalmente local (p. ej. Ollama) junto con un cliente compatible con MCP.

Solución de problemas

  • El servidor no aparece en Claude Desktop: comprueba que command y args usan rutas absolutas, confirma que la ruta de Python del venv existe realmente y confirma que cerraste y volviste a abrir la aplicación por completo. Los registros están en ~/Library/Logs/Claude (macOS) o %APPDATA%\Claude\logs (Windows) — mcp-server-quantified-self.log mostrará el stderr de este servidor específicamente.

  • "No health/finance database found" desde una herramienta: ejecuta primero init_db.py para ese conjunto de datos — las herramientas no crean bases de datos vacías automáticamente a propósito, para que no obtengas respuestas vacías en silencio.

  • Los cambios en server.py no parecen surtir efecto: reinicia Claude Desktop; inicia el proceso del servidor una vez por sesión de la aplicación, no por mensaje.

  • El alojamiento en Glama falla con Cannot find module '/app/server.js': esto significa que el despliegue recurrió a un runtime de Node.js en lugar de Python — este repositorio no tiene server.js. Compila a partir del Dockerfile incluido (consulta "Ejecutarlo en Docker / alojarlo en Glama" más arriba) en lugar de una configuración de buildpack genérica, para que la plataforma ejecute python server.py de forma fiable.

Ampliar esto

Algunos pasos siguientes naturales, si los quieres — nada de esto está construido, solo es hacia donde lleva el patrón:

  • Escribir herramientas (log_expense, log_daily_metric) para que las entradas se puedan añadir a través del LLM en lugar de mediante CSV/SQL directamente.

  • Más métricas — peso, entrenamientos, estado de ánimo, ingesta de agua — cada una es solo otra tabla y otra herramienta de lectura.

  • Una herramienta de presupuesto frente a real que compare los totales de read_finance_data con los objetivos que definas.

Available Tools

3 tools
clear_metricA

Blank out (set to null) a single metric for a single day, without touching that day's other metrics. The counterpart to log_daily_metric for undoing a bad value — e.g. a mood logged for the wrong day, or a weight entered with the wrong units.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesThe day to clear a field for, formatted YYYY-MM-DD.
fieldYesWhich metric to blank out. One of: steps, sleep_hours, resting_heart_rate, weight_kg, workout_minutes, mood, water_ml.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly communicates the mutation ('blank out'), the exact scope (one metric, one day), and the guarantee that other metrics are untouched. It could add permanence or no-op behavior details, but the core destructive semantics are clear.

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 compact and front-loaded with the action and scope. The examples are meaningful and help clarify intent without wasted words.

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?

For a two-parameter tool with full schema coverage and an output schema, the description covers the operation's purpose, scope, and usage context. Nothing essential is missing for correct invocation.

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 description coverage is 100%, so the input schema already documents date formatting and the allowed field values. The description adds contextual examples but no new parameter-level semantic detail, so the baseline of 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 uses a specific verb ('Blank out (set to null)') and names the exact resource: a single metric for a single day. It also explicitly distinguishes itself from log_daily_metric, making the tool's purpose unambiguous.

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

Usage Guidelines5/5

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

It explicitly frames this tool as the counterpart to log_daily_metric for undoing bad values, with concrete examples. This gives clear when-to-use guidance and implies the alternative for normal metric logging.

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

log_daily_metricA

Record one or more health metrics for a single day, creating that day's row if it doesn't already have one.

Only the metrics you pass are written — anything left as null is not touched, so logging just today's mood doesn't erase today's steps if they were set earlier. To undo a value logged by mistake, use clear_metric rather than trying to overwrite it with a placeholder.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesThe day to log, formatted YYYY-MM-DD.
moodNoMood rating on a 1-10 scale.
stepsNoStep count for the day. 0-200,000.
water_mlNoWater intake in millilitres. 0-10,000.
weight_kgNoBody weight in kilograms. 1-500.
sleep_hoursNoHours of sleep. 0-24.
workout_minutesNoMinutes of exercise. 0-1,440.
resting_heart_rateNoResting heart rate in bpm. 20-250.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and succeeds: it discloses row creation, partial-write semantics, and the fact that nulls are untouched. This is exactly the kind of behavioral context an agent needs before calling a mutating tool.

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?

Three sentences with no filler. The core purpose is front-loaded, and every sentence contributes either behavioral semantics or usage guidance. The description is compact yet rich.

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?

The tool has an output schema (per context), so return-value prose is unnecessary. The description covers creation, partial updates, null behavior, and the correct sibling for undo. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is 100%, giving the baseline 3, but the description adds meaningful parameter behavior beyond the schema: only passed metrics are written, nulls are not touched, and at least one metric is implied. This improves the agent's understanding of how the nullable parameters actually behave.

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 opens with a specific verb and resource: 'Record one or more health metrics for a single day.' It also distinguishes itself from siblings by explicitly naming clear_metric for undo operations, so an agent can tell logging from reading or clearing without ambiguity.

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

Usage Guidelines5/5

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

It clearly states when to use the tool (logging metrics for a day) and when not to ('To undo a value logged by mistake, use clear_metric'). It also explains the partial-update behavior, which prevents agents from thinking they must re-send all values.

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

read_health_dataA

Read daily health metrics from the local database: steps, sleep hours, resting heart rate, weight (kg), workout minutes, mood, and water intake (ml).

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoLast day to include, formatted YYYY-MM-DD. Defaults to today.
start_dateNoFirst day to include, formatted YYYY-MM-DD. Defaults to 30 days before end_date. Ranges over ~10 years are rejected.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must carry the burden. It clearly indicates the operation is a read from a local database, implying no mutation, and enumerates the data domains. It does not disclose potential behaviors like pagination, empty-result handling, or timezone assumptions, but output schema plus 'read' cover the essential safety profile.

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?

A single, front-loaded sentence states the operation, source, and the complete list of metrics with units. There is no filler or repetition of schema details.

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 read tool with no required parameters, a rich input schema, and an output schema, the description is nearly complete: it identifies the source and the returned metric categories. The main missing piece is explicit routing guidance versus siblings, which was already penalized under usage guidelines.

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 description coverage is 100% and the start_date/end_date parameters have detailed descriptions including format, defaults, and the ~10-year restriction. The tool description itself adds no parameter-level information, so the baseline of 3 applies.

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 the specific verb 'Read' with a clear resource, 'daily health metrics from the local database', and lists the exact metrics included. This differentiates it from the write/delete siblings log_daily_metric and clear_metric.

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?

The description gives no explicit guidance on when to choose this tool over its siblings, such as 'use for retrieving metrics as opposed to logging or clearing them.' Although the name implies a read operation, no when-to-use or exclusion criteria are stated.

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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.4
    • Addedclear_metric
    • Addedlog_daily_metric
  2. 2 tool updatesv1.0.3
    • Removedread_finance_data
    • Changedread_health_data1 field changed
      • changedInput schema / properties / start_date / description
        Previous value: -"First day to include, formatted YYYY-MM-DD.\n        Defaults to 30 days before end_date."New value: +"First day to include, formatted YYYY-MM-DD.\nDefaults to 30 days before end_date. Ranges over ~10 years are rejected."
  3. 1 tool updatev1.0.1
    • Changedread_finance_data1 field changed
      • changedInput schema / properties / category / description
        Previous value: -"Optional category name to filter to (case-insensitive,\n      exact match — e.g. \"Groceries\"). Omit to include all categories."New value: +"Optional category name to filter to (case-insensitive,\n      exact match — e.g. \"Groceries\"). A category with no matching\n      rows returns an empty \"transactions\" list, not an error — this\n      usually means a typo or a category that isn't in the ledger.\n      Omit to include all categories."
  4. 2 tool updatesv1.0.0
    • First observedread_finance_data
    • First observedread_health_data

TDQS

A4.1/5.0
Disambiguation5/5

Each tool maps to a distinct operation: reading, logging, and clearing metrics. There is no overlap or ambiguity between them.

Naming Consistency4/5

All tool names are snake_case and follow a verb-first pattern. The object names vary slightly ('health_data' vs 'daily_metric' vs 'metric'), but the intent remains clear.

Tool Count5/5

Three tools is well-scoped for a simple quantified-self server: read, log, and clear. Each tool serves a necessary purpose without redundancy.

Completeness4/5

Core workflow coverage is solid: read metrics, write metrics, and undo mistakes. Minor gaps exist, such as no way to delete an entire day or list supported metric types, but these are workable limitations.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Turns a personal-finance SQLite database into typed, schema-validated tools that an AI assistant can call directly, letting you manage accounts, transactions, budgets, debts, investments, tax estimates, and goals through natural language.
    47
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables querying personal data synced from services like Lunch Money and Strava using SQL via Claude.
    15
    1
    MIT

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/Thecimal/quantified-self-mcp'

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