pitwall-mcp

ローカル

github.com地図・旅行04 週間前に更新

pitwall-mcp について

pitwall-mcpは、CarDataを有効にしたBMWオーナー向けのローカルな読み取り専用MCPサーバーです。メンテナンス、タイヤ、バッテリー、燃料の情報を公開し、SQLiteの履歴から傾向や予測を示しながら、API利用量を管理します。

主な機能

01メンテナンス情報とCBS警告の取得
02タイヤ、バッテリー、燃料データの確認
03SQLiteへの読み取り履歴の保存
04故障コードの追加・解消の比較
05履歴に基づくメンテナンス時期の予測
06リクエストのキャッシュとAPI枠の追跡

活用シーン

01期限が近いメンテナンス項目の確認
02タイヤ空気圧の推移の追跡
03読み取り間の故障メモリーの変化の確認
04給油履歴と実燃費の分析

MCP 対応

ローカルMCPサーバーとして、アシスタントに読み取り専用の車両データツールを提供します。APIリクエストはキャッシュとローカルの利用枠カウントを通り、車両への書き込みや操作は行いません。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定

{
  "mcpServers": {
    "sergioprats-pitwall": {
      "command": "uvx",
      "args": [
        "pitwall-mcp"
      ],
      "env": {
        "PITWALL_CLIENT_ID": "<PITWALL_CLIENT_ID>",
        "PITWALL_VIN": "<PITWALL_VIN>",
        "PITWALL_CONTAINER_ID": "<PITWALL_CONTAINER_ID>",
        "PITWALL_TOKEN_FILE": "<PITWALL_TOKEN_FILE>",
        "PITWALL_DB_PATH": "<PITWALL_DB_PATH>",
        "PITWALL_DAILY_QUOTA": "<PITWALL_DAILY_QUOTA>",
        "PITWALL_LOG_LEVEL": "<PITWALL_LOG_LEVEL>"
      }
    }
  }
}

起動コマンドuvx pitwall-mcp

設定が必要な環境変数

PITWALL_CLIENT_IDシークレットClient id de tu aplicacion BMW CarData, creada en https://bmw-cardata.bmwgroup.com. Se obtiene en el portal; no lo comparte nadie contigo.

PITWALL_VINシークレットVIN del vehiculo, 17 caracteres. Debe estar mapeado como PRIMARY en la cuenta.

PITWALL_CONTAINER_IDId del contenedor telematico creado por scripts/bootstrap_containers.py. El servidor solo lo consume: nunca crea ni borra contenedores.

PITWALL_TOKEN_FILEシークレットRuta del fichero de tokens OAuth. Por defecto ~/.config/pitwall-mcp/tokens.json, con permisos 600 y fuera del repositorio.

PITWALL_DB_PATHRuta de la base SQLite con la cache, el registro de cuota y el historico. Por defecto ~/.local/share/pitwall-mcp/pitwall.db.

PITWALL_DAILY_QUOTATope duro de peticiones REST al dia. BMW permite 50 cada 24 h por cuenta; el valor por defecto es 20 para dejar margen. Nunca puede superar 50.

PITWALL_LOG_LEVELDEBUG, INFO, WARNING o ERROR. Los logs van a stderr: stdout es el canal MCP.

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ

pypipitwall-mcp0.1.1stdio

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

pitwall-mcp

BMW X1 sDrive18i（U11、ガソリン、スペイン）のBMW CarData APIを利用する、読み取り専用のローカルMCPサーバーです。

BMW AGとは無関係のプロジェクトです。「BMW」と「CarData」は、それぞれの所有者の商標です。このプロジェクトはBMWの承認、後援、レビューを受けていません。

アシスタントが車のメンテナンスデータ（走行距離、CBS警告、タイヤ空気圧、12 Vバッテリー）を参照できるようにします。車両には一切操作を加えず、APIの日次利用上限も使い切りません。

使い心地

アシスタントに「車の次の整備はいつ？」と尋ねると、次のように答えます。2026年9月16日の実際の読み取り結果を抜粋したものです。

RESUMEN DE MANTENIMIENTO

Kilometraje: 48.731 km
Proximo servicio en: 13460 km
  OJO: hay partidas CBS que BMW ya no marca como OK; no te fies solo de la
  cifra global: Frenos delanteros [PENDING]: 1.600 km.

Partidas CBS: 5
  - Frenos delanteros [PENDING]: 1.600 km
  - Aceite de motor [OK]: 14.000 km, hasta 2027-07
  - Inspeccion tecnica (ITV) [OK]: hasta 2027-01
  conditionBasedServicesCount dice 9: es el maximo de avisos que este vehiculo
  puede transmitir, no los que tiene. El desglose trae 5, los transmitidos.

Prevision orientativa (calculo propio sobre los km de BMW, no un dato de BMW):
  Ritmo usado: 570 km/semana (media semanal que da BMW); tu historico local,
  8 dias: 420. Se usa el mayor para no quedarse corto.
  - Frenos delanteros: 1.600 km, unas 2,8 semanas, hacia el 05-10-2026.

Bateria de 12V:
  Voltaje: 13.92 V   (2026-09-14 13:49 UTC (hace 40 horas))

Dato mas antiguo utilizado: 2026-09-14 13:49 UTC (hace 40 horas).
Procedencia: cache local. Lectura realizada: 2026-09-16 06:09 UTC.

この回答が数値を示す以外に何をしているか注目してください。全体の数値だけでは緊急性の高い項目が隠れていることを知らせ、「1,600 km」を日付に置き換え、BMWの2つの数値に食い違いがあることを認めてどちらか一方を選ぶことはせず、使用したデータのうち最も古いものがいつのデータかも示しています。

あなたに向いていますか？

向いています。CarDataを有効にしたBMWを所有していて、時間とともに何が変わるかを知りたい場合です。各項目が実際にいつ期限を迎えるか、タイヤの空気が抜けていないか、前回以降にどの故障コードが現れたかを確認できます。
向いていません。故障コードの翻訳や消去、車の設定変更をしたい場合です。それにはOBD診断を使う必要があり、このAPIの対象外です。
ご注意ください。これはたまに使うためのものです。生データは車載ディスプレイですでに確認できます。ここで追加されるのは、時系列、予測、変化に関する情報です。

できること／できないこと

できること：

テレマティクスデータ、車両の基本データ、タイヤ診断データを、常にキャッシュ経由で読み取ります。
ローカルのSQLiteに履歴を保存し、単発のスナップショットではなく、時系列に基づいて判断できます。
各データの取得元を示します。BMWのタイムスタンプ、読み取り時のタイムスタンプ、API、キャッシュ、履歴のいずれかを明記します。
データが存在しない場合は、その理由を説明します。

できないこと／今後も対応しないこと：

車に対して書き込み、送信、起動を行うツールや、そうした操作ができるかのように示唆するツールはありません。CarDataは読み取り専用APIです。
コンテナを作成または削除するツールはありません。それらの操作は手動で実行するスクリプトで行います。
get_software_version はありません。そのデスクリプターはBMWのカタログに存在しません。利用できるのは製品の更新ステップを示す puStep のみです。

APIの利用上限を守る

CarData REST APIの上限は、アカウントあたり24時間に50リクエストです。上限を超えると翌日まで 403 CU-429 が返されます。カウンターはBMW側で管理され、同じアカウントを使うほかのアプリケーションによるリクエストも含まれます。

そのため、次のようになっています。

すべてのリクエストは、必ずキャッシュとローカルカウンターを経由します。
ローカルのデフォルト上限は1日あたり20リクエストで、余裕を確保します。
メンテナンスコンテナのTTLが12時間の場合、通常の利用では1日2リクエストです。
search_descriptors と get_api_quota は利用上限を一切消費しません。

リクエストを続けて実行する前に get_api_quota を確認してください。

データ	TTL
`/telematicData`（メンテナンスコンテナ）	12 h
`/smartMaintenanceTyreDiagnosis`	7 días
`/basicData`	30 días
`/mappings`	30 días

公式アプリではなく、これを使う理由

アプリで確認できるのは今日の状態です。こちらは読み取りのたびに保存するため、比較できます。そこから分かる具体的なことを、この車で確認した例から4つ紹介します。

単に残量だけでなく、いつかが分かります。 アプリには「フロントブレーキ、1,600 km」と表示されます。サマリーでは、実際の使用ペースで約2.8週間後、10月5日ごろと示し、日付より先に走行距離で期限を迎える項目があれば警告します。
全体の数値だけでは不十分だと分かります。 ブレーキが1,900 kmでPENDINGのとき、serviceDistance.nextは13,560を示していました。その数値だけを見ていたら、唯一の緊急事項を見落としていたでしょう。そのため、BMWがOKと判定していない項目はすべて、個別に警告を表示します。
タイヤの熱を空気漏れと混同しません。 BMWの目標空気圧は一定ではありません。冷間時は250 kPa、タイヤが温まった状態では290 kPaの例が確認されています。今日の空気圧を別のタイミングの目標値と比較すると、差が実際より大きく見えてしまいます。そのため、各ホイールを同じ読み取り時点の同じ車軸にあるホイールと比較します。温度と荷重が共通だからです。
故障メモリの変化が分かります。 9月18日、2回の読み取りの間に11個のコードが追加され、別の11個が消えました。コントロールユニットが丸ごと1つ現れ、3つが消えました。前回の読み取りを保存していなければ、こうした変化はどこにも表示されません。

誤解のないように、できないことも説明します。

故障コードを翻訳しません。 その意味はBMWのカタログに載っていないため、推測するくらいなら表示しないほうがましです。その用途にはBimmerLinkのようなOBD診断ツールがあります。コードを説明付きで読み取れるほか、消去もできます。
何も書き込みません。 コーディングも、リセットも、車への指示も一切行いません。こうした操作には、車の前でBimmerCodeとOBDアダプターを使う必要があります。
受信していない情報を作りません。 データが欠落している場合、存在するものの値が空の場合、-NA-の場合は、それぞれ別の状態です。ツールはこれらを区別し、ゼロとして表示することはありません。コンテナの42個のディスクリプターのうち、前回の読み取りで値が届いたのは28個、空だったのは14個でした。

ツール

ツール	利用枠を消費	状態
`search_descriptors(query, limit, include_electric)`	いいえ	動作します
`get_api_quota()`	いいえ	動作します
`list_vehicles()`	はい（キャッシュありで月1回）	動作します
`get_vehicle_basic_data()`	はい（キャッシュありで月1回）	動作します
`report_product_update_step()`	はい（`basicData` とキャッシュを共有）	動作しますが、この車両は `puStep` を返しません
`get_telematic_data()`	はい（キャッシュありで1日2回）	動作します
`get_vehicle_status()`	はい（キャッシュを共有）	動作します
`get_tyre_diagnosis()`	はい（キャッシュありで週1回）	動作しますが、この車両は空の構造を返します
`get_maintenance_summary()`	はい（複合）	動作します
`diagnose_software_update()`	はい（複合、キャッシュを共有）	動作しますが、判定には限界があります
`get_fuel_status()`	はい（キャッシュを共有）	動作します
`get_fault_memory()`	はい（キャッシュを共有）	動作します。コードは翻訳しません

留保事項が記載された2つのツールは、動作し、データがないことを明示します。値がない箇所をゼロやもっともらしい値で埋めることはありません。この車両では /basicData に puStep が含まれず、タイヤ診断は測定値ではないラベルと埋め草のゼロを返します。

get_vehicle_status() と get_maintenance_summary() では、Check Control の警告も表示され、CBS の項目のいずれかが OK 以外になると OJO の行が追加されます。次回サービスまでの総距離だけでは不十分です。前輪ブレーキが1,900 km後に PENDING となっていたとき、総距離は13,560 kmと表示されていました。

get_maintenance_summary() ではさらに、リクエストを消費せずに、週単位と日付による予測、および車軸ごとの空気圧の傾向が追加されます。どちらもローカルの履歴をもとにしており、それぞれの理由については公式アプリではなく、これを使う理由をご覧ください。予測には、BMW の週平均と履歴の週平均のうち大きい方を使って、見積もりが甘くならないようにします。また、ある項目が日付よりも走行距離で先に期限を迎える場合は警告します。

公式アプリには表示されないデータを扱うツールが、ほかに2つあります。

get_fuel_status()：燃料タンクと航続距離、履歴から検出した給油、および直近の給油後の実燃費を表示します。燃費は300 km以上走行した場合にのみ、必ず誤差の範囲とともに表示します。燃料計には最大6 Lのずれが生じる可能性があるためです。公認燃費（OBFCM）も表示しますが、これはこの車両では2024年10月以降変わっていない生涯の数値であり、現在の燃費ではないことを明示します。
get_fault_memory()：整備工場向けに車両が保存している故障メモリーを、制御ユニットごとにまとめて表示し、読み取り間でどのコードが現れたり消えたりしたかも示します。コードは一切翻訳しません。その意味は BMW のカタログに記載されておらず、翻訳するとでっち上げになってしまうためです。

diagnose_software_update() は、履歴の一連の記録をもとに判断し、ある時点のスナップショットだけでは判断しません。BMW がアップデートを提供しない条件として文書化している3つのうち、CarData で観察できるのは1つだけです。このツールは、残りの2つを確認済みであるかのように判断せず、NO OBSERVABLE POR CARDATA として示します。13.5 V以上の電圧はすべて対象外です。これはオルタネーターが充電中の状態であり、停車時のバッテリーについては何も分からないためです。停車時の観測が少なくとも2回残っていない場合は、判定なしと回答し、不足している情報を示します。また、isIgnitionOn は空で返されるため、電圧低下の一部はバッテリーの放電ではなく、エンジン作動中と停止中の違いによる可能性があることも通知します。

ローカルレポート

サーバーが保存する履歴はどこにも表示されません。ツールが返すのはその時点のスナップショットであり、時系列データではありません。時系列データを見るには、SQLite から手動で生成する HTML ページを使います。

.venv/Scripts/python.exe scripts/report.py              # captures/report-*.html
.venv/Scripts/python.exe scripts/report.py --full-vin   # con el VIN entero

リクエストは一切消費しません。 トークンを使わず、エンドポイントも呼び出さず、クォータカウンターにも触れません。ローカルデータベースを読み取るだけです。ページは JavaScript や外部依存関係のない単一ファイルで、きれいに印刷でき、VIN をマスキングした状態で .gitignore に登録されている captures/ に出力されます。

最初に表示されるのは数値ではなく、コンテナの 42 個の記述子のうち、実際に値があるものの数と、残りがどの 3 種類の空状態に該当するかです。

インストール

Python 3.12+ が必要です。

git clone https://github.com/sergioprats/pitwall-mcp
cd pitwall-mcp
python -m venv .venv
.venv/Scripts/python.exe -m pip install -e ".[dev]"   # Linux/macOS: .venv/bin/python
.venv/Scripts/python.exe scripts/refresh_catalogue.py

最後の手順は必須です。テレマティクスカタログは BMW の文書であり、このリポジトリでは再配布していないため、1 度ダウンロードする必要があります。これは zweckj/bmw-cardata（MIT）から取得するもので、CarData API から取得するわけではないため、クォータのリクエストは消費しません。詳細は spec/README.md にあります。

リポジトリをクローンせずにパッケージをインストールした場合は scripts/ がないため、実行ファイルには必要な機能として、カタログ用の --fetch-catalogue と認証用の --login が含まれています。リポジトリが引き続き必要なのは、テレマティクスコンテナの作成です。これは意図的な仕様で、この手順は BMW アカウントに書き込みを行うため、プロジェクトの方針によりサーバーには含まれていません。

pitwall-mcp --fetch-catalogue          # junto a la base de datos
pitwall-mcp --fetch-catalogue --out /otra/ruta.json

ダウンロードしたものがカタログでない場合（キャプティブポータルは HTML を 200 で返します）は、書き込みを拒否するため、問題のあるダウンロードによって正常に使えていたカタログが失われることはありません。

以下のコマンドでは、仮想環境のインタープリターを明示的に使用します（Windows では .venv/Scripts/python.exe、Linux および macOS では .venv/bin/python）。仮想環境を有効化した場合（.venv/Scripts/activate または source .venv/bin/activate）は、python だけで実行できます。有効化せずにシステムの python を使うと、ModuleNotFoundError: No module named 'bmw_cardata' で失敗します。

1. 設定

cp .env.example .env

PITWALL_CLIENT_ID に CarData クライアントの client id を設定します。お住まいの国の My BMW ウェブサイトで、車両のページ → BMW CarData → 「BMW CarData への技術アクセス」から作成できます（スペインの場合： bmw.es/es-es/mybmw/vehicle-overview）。別のポータルではありません。cardata:api:read スコープが必要です。ストリーミングを使用する場合は、cardata:streaming:read も必要です。

2. ログイン

pitwall-mcp --login                              # instalado con pip
.venv/Scripts/python.exe scripts/login.py        # o desde el repositorio: hace lo mismo

デバイスフローです。URL とコードが表示されるので、ブラウザーで認証します。トークンはリポジトリ外の ~/.config/pitwall-mcp/tokens.json に、権限 600 で保存されます。接続先は CarData API ではなく BMW の OAuth なので、クォータは消費しません。

リポジトリのスクリプトは同じコードを呼び出すラッパーにすぎません。フローの定義を 1 か所にまとめることで、pip でインストールしたユーザーも認証できます。

リフレッシュトークンの有効期間は 14 日間です。残り 3 日未満になるとサーバーが目立つ形で通知します。有効期限が切れた場合は、この手順を手動でやり直す必要があります。

3. コンテナ

.venv/Scripts/python.exe scripts/bootstrap_containers.py --dry-run   # muestra qué enviaría
.venv/Scripts/python.exe scripts/bootstrap_containers.py --create    # gasta 1 petición

生成された containerId を .env の PITWALL_CONTAINER_ID にコピーします。MCP サーバーはこの ID を使うだけで、コンテナの作成も削除もしません。

コンテナでは 42 個の記述子を要求します。メンテナンス情報に加えて、燃料タンク、航続距離、認定燃費、故障メモリー、エンジン温度が含まれます。基準車両では 3 個を除いてすべて取得できます。この拡張前に作成したコンテナを使っている場合は、同じスクリプトで作成し直してください。

4. 起動

.venv/Scripts/python.exe -m pitwall_mcp

トランスポートは stdio です。.env はサーバーを起動したディレクトリで検索され、見つからない場合はリポジトリのルートで検索されます。MCP クライアントは任意の作業ディレクトリからプロセスを起動するためです。.env が別の場所にある場合は、PITWALL_ENV_FILE で指定してください。

Claude Desktop または任意の MCP クライアントの場合：

{
  "mcpServers": {
    "pitwall": {
      "command": "/ruta/al/.venv/bin/python",
      "args": ["-m", "pitwall_mcp"],
      "env": { "PITWALL_CLIENT_ID": "...", "PITWALL_VIN": "...", "PITWALL_CONTAINER_ID": "..." }
    }
  }
}

5. ストリーミング（任意）

MQTT デーモンは、MCP サーバーが読み取るものと同じデータベースに書き込みます。クォータを消費しません。任意の機能です。有効にしなくても、1 日 2 回のスナップショットで同じように動作します。

.venv/Scripts/python.exe -m pitwall_mcp.streamd     # o: pitwall-streamd

起動する前に、自動化できない手順があります。BMW のポータルで Data Selection にアクセスし、受信したいディスクリプターを手動で選択します。このための API はありません。ストリームから何も届かない場合、まずデーモンのバグを疑うのではなく、このページを確認してください。

知っておくとよいことが 3 つあります。

BMW では、1 つのアカウントにつきストリーミング接続を 1 つしか利用できません。 デーモンはネットワークに接続する前にデータベースのロックを取得するため、2 つのインスタンスが競合することはありません。2 つ目のインスタンスは、接続を保持している PID と接続開始時刻を表示して終了します。ただし、このロックで検知できないのは、Home Assistant や evcc など別のクライアントです。この場合は、切断が続くという症状から検知されます。デーモンは原因を推測させるのではなく、そのクライアント名を表示します。
データが届かなくても正常な場合があります。 車が車庫に停められ、深いスリープ状態にあると、何週間もデータを送信しないことがあります。データが届かないことを理由にデーモンが再接続することはありません。また、get_api_quota は、正常に動作しているものの再起動を促すのではなく、「N 日間沈黙していますが、これは正常です」と伝えます。
REST API によるバッテリー診断の代わりにはなりません。 2 つの健康状態シグナル（serviceDemand.replace と .recharge）はストリーミングできず、今後もできるようにはなりません。ストリーミングで補えるのは、連続した電圧と充電量のデータです。これがこれまで不足していた情報です。健康状態の判定は引き続き 1 日 2 回取得されます。

デフォルトでは自動起動しません。意図的な設計です。利用可能な唯一の接続を使うため、利用するかどうかは自分で判断する必要があります。

開発

.venv/Scripts/python.exe -m pytest                              # ningún test toca la red
.venv/Scripts/python.exe scripts/refresh_catalogue.py --check   # ¿ha cambiado el catálogo?

実際の呼び出しを行うテストはありません。 すべて、Swagger スキーマをもとに手動で作成したフィクスチャを使います。クォータを消費するテストスイートはバグです。no_network フィクスチャによって、実際の接続を開こうとする処理はすべて失敗します。

このテストは、push と pull request のたびに、GitHub Actions 上で Python 3.12 および 3.13 を使用して Linux と Windows で実行されます。リポジトリではカタログを再配布していないため、ワークフローはまずカタログをダウンロードします。また、シークレットは一切不要です。テストが BMW API を呼び出そうとすると、失敗します。

さらに、誰も操作しなくても週に 1 回実行されます。単なる慣習ではありません。実行のたびにカタログをダウンロードするため、この週次実行によって、参照しているディスクリプターが元のカタログからなくなった場合に気づけます。その場合はテストが失敗し、数か月後にツールが予期しない動作をするのではなく、メールで通知されます。ただし、カタログのあらゆる変更を監視するわけではありません。何かを壊す変更だけが対象です。

状態

すべてのツールは、フィクスチャとして記録された実際の応答を使って実装されています。

フェーズ 2（ストリーミング MQTT デーモン）は実装済みで、現場で接続していますが、まだメッセージを 1 件も受信していません。車が停車中でも走行中でも同じです。BMW に接続したまま動作させて初めて答えが得られる 2 つの疑問のうち、1 つにはすでに答えが出ています。BMW は接続に使ったトークンの有効期限が切れるとセッションを終了し、デーモンは新しいトークンで自動的に再接続します。もう 1 つの疑問、つまりこの車が MQTT で何かを送信するのかは、まだ未解決です。まず確認すべきなのは、ポータルの Data Selection の設定です。SQLite スキーマには最初のコミットから source カラムと stream_state テーブルがあったため、移行は必要ありませんでした。

2026 年 9 月 7 日から 10 月 2 日までに実際の読み取りで確認できた、この車についての情報は次のとおりです。

コンテナの 42 個の記述子のうち 12 個は、イグニッションをオンにして車を走らせても、常に空です。バッテリーの充電状態、イグニッション、車が動いているかどうか、タイヤの温度などが該当します。読み取りに失敗しているわけではありません。この車はこれらの情報を送信していません。ほかの項目は、取得できたりできなかったりします。CBS の内訳は、項目が取得できることもあれば空のこともあり、ディープスリープは約 1 か月間空でしたが、10 月 2 日に初めて値が取得されました。
12 V バッテリーの電圧は、REST ではごくまれにしか更新されないグループに含まれています。15 日間で取得できた電圧は6 件です。14.39／14.35／14.77／13.92／14.80 V（いずれも 13.5 V のしきい値を超えるオルタネーター電圧）と、9 月 22 日のエンジン停止中の 12.73 Vです。ただし、その日は車が整備工場にあり、充電メンテナーや診断機器が接続されていた可能性があるため、安静時のクリーンな測定値とはみなせません。

通常の使用では、REST からはまだ安静時の電圧が 1 件も取得できておらず、ましてや連続した測定値はありません。 diagnose_software_update は引き続き SIN VEREDICTO です。これは正しい状態で、傾向を判断するには安静時の測定値が 2 点必要です。取得するには、ストリーミングが引き続き現実的な方法ですが、最初の現場テストでは車の走行中でさえ何も受信しませんでした。まずポータルの Data Selection の設定を確認する必要があります。
ほかに 3 つの点が未解決です。
- 故障メモリのヘッダーが何を示すのか。72、67、68、67 件のコードが通知されましたが、常に 44 件のエントリーが含まれています。CBS の警告カウンターが最大値だったように、44 が送信上限である可能性はありますが、まだ推測の域を出ません。
- BMW の 1 日あたりのクォータがどのタイムゾーンでリセットされるのか。
- Check Control の警告に付随する走行距離フィールドが何を示すのか。2 通りの解釈を試しましたが、どちらも正しくありませんでした。そのため、ツールでは加工せずに表示し、BMW がこの項目を文書化していないと明記しています。

ライセンス

BMW のドキュメントはここから再配布しません。 テレマティクスカタログも OpenAPI 仕様もバージョン管理には含まれていません。手元のマシンにダウンロードしてください。spec/ は .gitignore に含まれています。spec/README.md を参照してください。

BMW AG と無関係のプロジェクトです。「BMW」と「CarData」は、それぞれの所有者の商標です。

Markdown 対応

ログインしてコメント

基本情報

作者: sergioprats
言語: python
バージョン: 0.1.1
トランスポート: stdio
掲載日: 2026年9月22日
最終更新: 4 週間前
公式 Registry: io.github.sergioprats/pitwall-mcp

問題を報告

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

pitwall-mcp

pitwall-mcp について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

pitwall-mcp

使い心地

あなたに向いていますか？

できること／できないこと

APIの利用上限を守る

公式アプリではなく、これを使う理由

ツール

ローカルレポート

インストール

1. 設定

2. ログイン

3. コンテナ

4. 起動

5. ストリーミング（任意）

開発

状態

ライセンス

コメント

MCP は初めてですか？

MCP（Model Context Protocol）とは？

MCP サーバーとクライアントの違いは？

ローカルとリモート、どちらを選ぶべき？

Claude や Cursor にサーバーを導入するには？

掲載プロジェクトは審査されていますか？「認証済み」とは？

自分のプロジェクトが掲載されています。どう申請できますか？