Skip to main content
Glama
deenesjakoruzh
Thecimal

Quantified Self MCP Server

by Thecimal
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Quantified Self MCPサーバー

ローカルのModel Context Protocol(MCP)サーバーで、LLM(例: Claude Desktop)があなたの個人の健康・財務データを照会できるようにします。すべては2つのローカルSQLiteファイルに保存され、あなたが制御するPythonプロセスがディスクから直接読み取ります。クラウドデータベースも、ダッシュボードも、サードパーティのサービスもありません。

含まれるもの

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

init_db.pyを実行すると、server.pyの隣にdata/フォルダが作成され、health.dbとfinance.dbが含まれます。このフォルダはここには含まれていません。あなた自身のデータからあなたのマシン上で生成されるためです。

Related MCP server: apple-health-mcp

公開されているツール

ツール

戻り値

パラメータ(すべて任意)

read_health_data

毎日の歩数、睡眠時間、安静時心拍数

start_date、end_date(ISO YYYY-MM-DD; デフォルトは過去30日間)

read_finance_data

カテゴリ別の支出台帳、合計付き

start_date、end_date、category(デフォルトは過去90日間、すべてのカテゴリ)

どちらのツールも、一致する行に加えて計算されたサマリー(健康の平均/最小/最大、財務のカテゴリ別合計)を返すため、モデルが多数の行にわたって独自の集計を行う必要はありません。

1. 環境のセットアップ

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. データの読み込み

同梱のサンプルですぐに試せます:

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

自分のデータを使うには、以下の列でCSVにエクスポートし、同じコマンドを自分のファイルに対して実行してください:

  • health CSV: date, steps, sleep_hours, resting_heart_rate

  • finance CSV: date, category, amount, description(descriptionは任意)

日付はISO形式(2026-08-23)にしてください。MM/DD/YYYYも受け付けられ、変換されます。金額/数値には$と,を含めることができます(例: $1,234.56)— これらは自動的に削除されます。問題のある行(不正な日付、非数値の金額、カテゴリ欠落など)はインポート全体を中断するのではなく、警告付きでスキップされます。最後に表示される行は、常に読み込まれた行数とスキップされた行数を示します。

init_db.py healthを再度実行すると、日付でアップサートされます(日を追加しても安全に再実行できます)。init_db.py financeは毎回新しい行を追加します。台帳には自然な一意キーがないためです。どちらのコマンドにも--replaceを追加すると、代わりにテーブルを最初に削除します。

3.(任意)単独でテストする

クライアントに組み込む前に、MCP Inspectorを開いてブラウザでツールを直接呼び出すことができます:

fastmcp dev inspector server.py

4. Claude Desktopに接続する

Claude Desktopは、ローカルのMCPサーバーをサブプロセスとして起動し、JSON設定ファイルに基づいてstdioで通信します:

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

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

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

アプリから直接ジャンプできます: 設定 → 開発者 → 設定ファイルを編集。

mcpServersの下にエントリを追加し、絶対パスを使用してください。重要なのは、commandを作成した仮想環境内のPythonインタープリタに向けることで、裸のpythonではなく、ということです。Claude Desktopはサーバーを最小限の環境で実行するため、シェルのPATHやアクティブなvenvを確実に継承しません。そのため、裸の"python"はしばしば誤ったインタープリタ(またはまったくないもの)に解決され、サーバーは静かに起動に失敗します。

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

Windowsでは、通常次のようになります:

{
  "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"]
    }
  }
}

ファイルを保存し、Claude Desktopを完全に終了して再起動します(ウィンドウを閉じるだけでは不十分—設定変更を読み込むには再起動が必要です)。チャットボックスのハンマー/ツールアイコンを探して、quantified-selfが接続されていることを確認します。

FastMCPには、このファイルを編集するCLIショートカットも同梱されています— fastmcp install claude-desktop server.py --name "Quantified Self" — 試す価値があります(現在のフラグはfastmcp install claude-desktop --helpを実行)。ただし、上記の手動JSONは常に機能し、何か問題があればデバッグしやすいです。Anthropicには、ローカルMCPサーバー用の新しいワンクリック「デスクトップ拡張機能」パッケージ形式もあります。このような個人利用には必要ありませんが、JSON編集に不慣れな人とサーバーを共有したい場合に知っておくとよいでしょう。

5.(任意)Dockerで実行 / Glamaでホスト

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

Dockerfileが同梱されており、ローカルvenvの代わりにコンテナで実行したい人向けです。Glamaでのホスティングも含みます。Glamaは、リポジトリにDockerfileがあると、そこから直接ビルドします。

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

イメージはPythonのみです(python:3.12-slim + pip install -r requirements.txt)。このプロジェクトにはNode.jsはどこにもありません。HEALTH_DB_PATHとFINANCE_DB_PATHは、コンテナ内の/data/health.dbと/data/finance.dbにデフォルト設定されるため、マウントされたボリューム(例: Glamaの/dataマウント)が再デプロイ後もデータベースを永続化します。上書きするには、server.pyの上部にある設定セクションを参照してください。

glama.jsonは意図的に最小限です— 単にGlamaにこのリポジトリを指すだけです。Dockerfileが、イメージのビルドと起動方法(python server.py、stdio経由)の実際のソースです。以前のバージョンのglama.jsonは、Dockerfileを使用する代わりに、汎用ビルドパック(裸のdebian:trixie-slimベースイメージと手動のpip installビルドステップとcmdArguments)を手動設定しようとしました。そのイメージにはPythonインタープリタが確実にプロビジョニングされておらず、プラットフォームはこのリポジトリに存在しないNode.jsエントリポイントの実行にフォールバックしました(Cannot find module '/app/server.js')。Dockerfileを同梱することで、その曖昧さは解消されます。

プライバシーモデル — 「ローカル」が実際に意味するもの

これについては正確にしておく価値があります。これがプロジェクトの要点だからです:

  • 両方のSQLiteデータベースは、このプロジェクトのdata/フォルダ内の、あなたのディスク上にのみ存在します。サーバーはネットワーク呼び出しを行わず、テレメトリもなく、どこにも同期しません。

  • server.pyは、SQLiteの読み取り専用モードで両方のデータベースを開きます(単に「書き込みを発行しない」だけでなく、接続は物理的に不可能です)。バグのあるプロンプトや悪意のあるプロンプトでも、どちらのツールもあなたのデータを変更できません。ターミナルからあなたが実行するinit_db.pyだけが、書き込みを行います。

  • MCPクライアントがこれらのツールのいずれかを呼び出すと、そのクエリに対して返された特定の行が、応答しているモデルに送信される会話の一部になります。これがMCPがモデルに情報を提供するメカニズムです。Claude Desktopをホスト型モデルで使用している場合、あなたが尋ねたデータのスライスは、そのターンでAnthropicに送信されることを意味します。チャットに入力する他のものと同様です。

  • つまり、ここでの「ローカル」とは、あなたの完全なデータセットがサードパーティのデータベースに保存または同期されることは決してなく、ツールが実際に呼び出されない限り何も送信されない— そしてその場合でも、その特定の呼び出しが返す行のみが送信され、データベース全体ではありません。完全にオフラインのエンドツーエンドを意味するものではありません。そのためには、MCP互換クライアントと組み合わせた完全にローカルなモデルランタイム(例: Ollama)が必要です。

トラブルシューティング

  • サーバーがClaude Desktopに表示されない: commandとargsが絶対パスを使用しているか、venvのPythonパスが実際に存在するか、アプリを完全に終了して再起動したかを確認してください。ログは~/Library/Logs/Claude(macOS)または%APPDATA%\Claude\logs(Windows)にあります。mcp-server-quantified-self.logに、このサーバー固有のstderrが表示されます。

  • ツールから「No health/finance database found」: そのデータセットに対して先にinit_db.pyを実行してください。ツールは意図的に空のデータベースを自動生成しないため、静かに空の回答が返ることはありません。

  • server.pyの編集が反映されていないように見える: Claude Desktopを再起動してください。サーバープロセスはメッセージごとではなく、アプリセッションごとに1回起動されます。

  • GlamaでのホスティングがCannot find module '/app/server.js'で失敗する: これは、デプロイがPythonではなくNode.jsランタイムにフォールバックしたことを意味します。このリポジトリにはserver.jsはありません。プラットフォームが確実にpython server.pyを実行するように、汎用ビルドパック設定ではなく、同梱のDockerfile(上記の「Dockerで実行 / Glamaでホスト」を参照)からビルドしてください。

拡張

自然な次のステップをいくつか紹介します。どれもまだビルドされていませんが、パターンが示す方向性です:

  • エントリをCSV/SQLの代わりにLLMを通じて追加できるように、ツール(log_expense、log_daily_metric)を書く。

  • より多くのメトリクス— 体重、ワークアウト、気分、水分摂取量— それぞれが別のテーブルと別の読み取りツールになります。

  • 予算対実績ツール。read_finance_dataの合計を、あなたが定義した目標と比較します。

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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Resources

Related MCP Connectors

Related MCP Servers

  • Finance MCP Server

    PavelKosik
    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

  • mydata

    bibekg
    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