元のAssetto Corsa向けにClaudeをレースエンジニアに変身させるMCPサーバーです。 ACの共有メモリテレメトリを読み取り、ラップをSQLiteに保存し、エンジニア級のサマリーに圧縮し、ゲーム内のセットアップメニューに直接表示されるセットアップファイルの読み書きができます。
Assetto Corsaを実行しているWindowsマシン上で動作します。オリジナルのACのみ（acpmf_* 共有メモリレイアウトを使用、ACCではありません）。
前提条件: python.org からPython 3.10以上。インストーラーの最初の画面で 「Add python.exe to PATH」 にチェックを入れてください。Microsoft Store版は使用しないでください — サンドボックス化により共有メモリアクセスができなくなります。
その後、このフォルダ内で: install-windows.bat を右クリック → 開く（またはダブルクリックするだけ）。
以上です。インストーラがPythonを見つけ、パッケージをインストールし、Claude Desktopの設定を書き込み（既存のMCPサーバーとマージし、事前にバックアップを取ります）、Assetto Corsaのインストール先を特定し、ゲーム内Luaアプリを適切な場所にコピーします。git pull 後にいつでも再実行可能です。その場で更新されます。
Assetto Corsaが見つからない場合は、場所を教えてください。フラグは .bat に指定し、.ps1 には指定しないでください — Windowsはデフォルトの実行ポリシーで .ps1 ファイルの直接実行をブロックしており、.bat はその回避策として存在します:
install-windows.bat -AcPath "D:\Games\steamapps\common\assettocorsa"その他のフラグ: -SkipLuaApp、-Uninstall。
インストール後、Claude Desktopを完全に終了してから再度開いてください。 ウィンドウを閉じるだけでは不十分です — システムトレイ（右下、^ 矢印の下に隠れている可能性あり）のClaudeアイコンを右クリックし、「Quit」を選択してください。
Related MCP server: fastf1-mcp
python -m pip install -e .次に、サーバーを claude_desktop_config.json に追加します。このファイルを開く最も速い方法は Claude Desktop → Settings → Developer → Edit Config です。これにより、ファイルが存在しない場合は作成され、含まれているフォルダが開きます — ファイルシステムの探索は不要です。
%APPDATA% はリテラルパスではなく、環境変数 です。これは C:\Users\<あなた>\AppData\Roaming に展開されます — そして AppData は 隠し フォルダであるため、エクスプローラで参照しても表示されず、表示 → 隠しファイルを有効にする必要があります。
さらに大きな落とし穴: %VAR% は cmd.exe の構文です。Windows Terminalのデフォルトは PowerShell であり、同じ変数は $env:VAR と表記されます。したがって:
場所 | 入力する内容 |
PowerShell / Windows Terminal |
|
cmd.exe |
|
エクスプローラのアドレスバー |
|
Win+R（ファイル名を指定して実行） |
|
フォルダを開くには、PowerShellで explorer $env:APPDATA\Claude を使用します。
{
"mcpServers": {
"ac-race-engineer": {
"command": "C:\\Users\\<you>\\AppData\\Local\\Programs\\Python\\Python312\\python.exe",
"args": ["-m", "ac_race_engineer.server"]
}
}
}python.exe への絶対パスを使用し、裸の "python" は使用しないでください。Claude Desktopはシェルの PATH なしでMCPサーバーを起動するため、裸のコマンドは頻繁にサイレントで失敗します。正しいパスは以下で取得:
py -c "import sys; print(sys.executable)"(Get-Command python).Source は使用しないでください — 標準のWindowsでは、多くの場合 ...\WindowsApps\python.exe、つまりMicrosoft Storeエイリアススタブが返され、これは誤った答えです。JSONではバックスラッシュを二重にする必要があることを忘れないでください (\\)。
（Claude Codeを使用する場合の代替:
claude mcp add ac-race-engineer -- python -m ac_race_engineer.server）
オプションの環境変数オーバーライド:
AC_DOCS_DIR — ACのドキュメントフォルダ（デフォルト ~/Documents/Assetto Corsa）
AC_ENGINEER_DATA — DB + 範囲の場所（デフォルト ~/.ac-race-engineer）
AC_ENGINEER_BRIDGE_PORT — ゲーム内アプリブリッジポート（デフォルト 9666）
Claudeにツールが表示されない。 Claude Desktopを完全に終了してから再度開いたことを確認してください（トレイアイコン → Quit）。次にサーバーログを読んでください:
notepad $env:APPDATA\Claude\logs\mcp-server-ac-race-engineer.logpython と入力するとMicrosoft Storeが開く（または「認識されていません」と表示される）。Windowsには %LOCALAPPDATA%\Microsoft\WindowsApps\python.exe にアプリ実行エイリアススタブが付属しており、実際のPythonが PATH にない場合に名前を乗っ取ります。python.orgからPythonをインストールし、「Add python.exe to PATH」にチェックを入れるか、py ランチャーを使用してください（py -3 -m pip install -e .） — python.orgインストーラはデフォルトでこれを設定します。また、設定 → アプリ → 詳細なアプリ設定 → アプリ実行エイリアスでスタブを無効にすることもできます。
インストーラはすでに WindowsApps 以下のものを無視するため、手動インストールの場合のみ問題になります。
.ps1 cannot be loaded because running scripts is disabled。 それが実行ポリシーです。代わりに install-windows.bat を使用してください — システム設定を変更せずに、そのスクリプトのみポリシーをバイパスします。
セットアップの値がゲーム内で反映されない。 車の法的範囲外の値を書き込んでおり、ACが静かに無視しています — 次のセクションを参照してください。
ACを起動し、コースに出ます。
Claudeに伝えます: 「録音を開始して、セッションを確認できるか教えて」 (start_recording、live_snapshot)。
3〜5周走行します。ラップは完了すると自動的に保存されます。コースアウト（2タイヤ以上がコース外）はラップを無効としてマークします。
「最後のラップを要約して、現在のセットアップを読み取って」 (list_laps、lap_summary、read_setup)。サマリーには、コーナーごとの最低速度、ブレーキポイント、タイヤ圧力/温度、およびスリップバランス指標（正 = アンダーステア、負 = オーバーステア）が含まれます。
車の挙動について話し合い、Claudeが write_setup で改訂されたセットアップを書き込みます（例: claude_v1 として）。
ピットインし、セットアップ画面から claude_v1 を読み込み、再び走行します。
「新しいセットアップでのベストラップをラップNと比較して」 (compare_laps) — コーナーごとの最低速度とブレーキポイントの差分により、変更が実際に機能したかどうかがわかります。
ACは、車の setup.ini（data.acd 内）で定義された範囲外のセットアップ値を静かに無視します。サーバーが各車の法的な最小/最大/ステップに値をクランプしてスナップできるようにするには:
Content Managerで: 車のページ → データを展開（またはQuickBMSを使用）。
車の setup.ini を範囲フォルダにコピーし、車のフォルダ名にちなんで名前を付けます — 例: ks_mazda_mx5_cup.ini。
そのフォルダを開くには（インストーラがすでに作成しています）:
explorer $env:USERPROFILE\.ac-race-engineer\ranges(cmd.exe: explorer %USERPROFILE%\.ac-race-engineer\ranges)
範囲ファイルがない場合、書き込みは依然として機能しますが、警告が返され、セットアップ画面で値を確認する必要があります。
install-windows.bat はこれを自動的にコピーします。手動で行うには、lua_app/race_engineer/ を assettocorsa/apps/lua/race_engineer/ にコピーします（Custom Shaders Patchが必要。Content ManagerをCSP有効で使用している場合はすでにインストールされています）。ゲーム内のアプリサイドバーから有効にします — セッション中にマウスを画面の右端に移動します。
Assetto Corsaがどこにインストールされているかわかりませんか？ SteamでAssetto Corsaを右クリック → 管理 → ローカルファイルを閲覧。
機能:
走行中の苦情タグ — Understeer / Oversteer / Braking / Traction ボタン。それぞれアプリの設定ウィンドウからホイールボタンに割り当て可能（CSPコントロールバインディングとして表示されます）。押すと、正確なスプライン位置、ラップ、速度が記録されます。Claudeは get_driver_notes でこれらを読み取り、コーナーテレメトリと関連付けます:「スプライン0.34で2回アンダーステアをフラグしました — フロントスリップがリアを0.09上回るコーナーです」。
ステータスオーバーレイ — 録音インジケーター + 保存済みラップ数。Alt-Tabで確認する必要はありません。
Claudeからのメッセージ — send_driver_message でオーバーレイにメモを表示（「claude_v2 を保存しました — ピットインして読み込んでください」）。OKで消去。
アプリはサーバーのHTTPブリッジと 127.0.0.1:9666 で通信します（AC_ENGINEER_BRIDGE_PORT で変更可能。Luaの BASE もそれに合わせて編集）。ブリッジはlocalhostのみにバインドされます。
ac_race_engineer/
sim_info.py shared memory structs (physics / graphics / static)
collector.py background sampler -> SQLite, lap boundary detection
db.py schema + storage
analysis.py corner detection, lap summaries, lap comparison
setups.py setup INI read/write, range clamping
bridge.py localhost HTTP bridge for the in-game app
server.py MCP tools
lua_app/
race_engineer/ CSP Lua in-game app (copy to apps/lua/)
install-windows.ps1 one-shot Windows installer
install-windows.bat double-clickable wrapper for the aboveサンプリングレートは25Hz — DBを小さく保ちながらセットアップ作業には十分です。より細かいトレースが必要な場合は、collector.pyの TARGET_HZ を上げてください。
アウトラップ（有効ラップタイムなし）は自動的にスキップされます。
コーナー検出は汎用的（速度の最小値）。コーナー名マップをトラックごとに持てば、Claudeのアドバイスがより読みやすくなります（「T3/Variante」 vs 「コーナー0.34」）。
CSP/Luaは、ダンパー速度やストック共有メモリよりも多くのチャンネルを公開できるため、より深いサスペンション作業が必要な場合に役立ちます — Telemetrickのソースが良い参考になります。
Health of the HTTP bridge the in-game app connects to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'Health' without specifying whether the operation is read-only, fast, requires authentication, or what happens if the bridge is unreachable. The agent cannot infer safety or side effects from this minimal text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, which is very concise. It front-loads the key information. However, it could be slightly expanded to include output or usage context without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having zero parameters and an output schema, the description does not explain what the health status encompasses (e.g., boolean, string, error details). The agent is left guessing the return structure. For a health-check tool, this is a significant omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond the schema, which is acceptable given no parameters exist. No improvement needed, but also no value added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Health of the HTTP bridge the in-game app connects to', which clearly identifies the resource (HTTP bridge) and implies the action is to retrieve its health status. It is distinct from sibling tools that deal with recording, sessions, laps, or setups, so purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases (e.g., before making bridge-dependent calls), or when not to use it. This is a gap for a health-check tool that could inform agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Corner-by-corner comparison of two laps on the same track: min speed deltas, brake point deltas, and slip balance changes. Use to evaluate whether a setup change actually helped.
| Name | Required | Description | Default |
|---|---|---|---|
| lap_id_a | Yes | ||
| lap_id_b | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the analysis scope and output categories, which is helpful. However, it does not mention whether the tool is read-only, whether lap data must be from the same session/driver, or what happens if laps are incompatible. A 3 is fair given the lack of annotations and moderate behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads purpose, and wastes no words. Every sentence serves a function: the first defines what the tool does, the second gives usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 simple integer parameters, an output schema is present, and no nested objects), the description is complete. With an output schema, the return value explanation is covered, and the description provides sufficient behavioral and usage context. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that lap_id_a and lap_id_b represent two laps on the same track, adding semantic meaning beyond the integer type. It does not define acceptable value ranges or format, but the purpose is clear enough for an agent to infer usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('compare') and resource ('two laps on the same track'), and lists concrete outputs ('min speed deltas, brake point deltas, and slip balance changes'), making the purpose entirely clear and distinct from sibling tools like lap_summary or list_laps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use to evaluate whether a setup change actually helped.' This provides strong guidance on the intended context and decision-making scenario, making it easy for an agent to select it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complaint tags the driver pressed in-game while driving (understeer, oversteer, braking, traction, note). Each has a spline position (0..1) directly comparable to corner apex_pos values from lap_summary, plus the lap_count when pressed (current lap = lap_count + 1). Correlate these with telemetry to know which corners the driver is unhappy with.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It explains the data structure (spline position comparable to apex_pos, lap_count behavior with +1 offset) and hints at the correlation use case. However, it omits details like default sorting, pagination, read-only guarantee, or effect of session_id parameter. It adds some behavioral context but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, gets straight to the point about what the tool returns and how the data relates to other tools. It is front-loaded with key information. The only flaw is the omission of parameter explanations, which would improve completeness without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two optional parameters and a complex output schema (context confirms output schema exists). The description explains the output's conceptual meaning (spline position mapping, lap count) very well, which is valuable. However, it completely ignores the input parameters (limit, session_id), leaving the agent without guidance on how to control the query. This is a significant gap in usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema has no descriptions for limit or session_id. The description does not mention these parameters at all, leaving their purpose and effects entirely undocumented. The description fails to compensate for the zero coverage, providing zero added meaning for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves 'complaint tags' pressed by drivers, listing types (understeer, oversteer, etc.) and providing spline position and lap count. The verb 'get' and resource 'driver notes' are explicit. It differentiates from siblings like lap_summary and compare_laps by focusing on subjective driver feedback rather than raw telemetry or lap comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for correlating driver complaints with telemetry corners, but it does not contrast with siblings like send_driver_message (for sending messages) or lap_summary (for objective data). An agent would have to infer usage from context rather than being directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Engineer's summary of one lap: lap time, throttle/brake/coast split, tyre pressures and core temps, per-corner min speed, brake points, and a front/rear slip balance metric (positive = understeer tendency, negative = oversteer tendency).
| Name | Required | Description | Default |
|---|---|---|---|
| lap_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses that the tool returns a summary with specific metrics, and notably explains the slip balance metric's meaning (positive = understeer, negative = oversteer). However, it does not mention whether the tool is read-only, what happens if lap_id is invalid, or if it triggers side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's purpose ('Engineer's summary of one lap') and then lists specific metrics in a clear, comma-separated format. Every element adds value, with the slip balance interpretation parenthetically added for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context signals indicate 'Has output schema: true'), the description does not need to explain return format. It covers the key categories of data (time, driving splits, tyre info, corner details, balance metric) comprehensively enough for an engineer to know what to expect. Minor gap: no mention of units or data types, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter (lap_id) with no description, and schema coverage is 0%. The description compensates by not needing to detail lap_id further, as its purpose is obvious (identifies a lap). The description's primary value lies in detailing what the tool returns, which is beyond the schema's scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an engineer's summary of one lap, enumerating specific metrics like lap time, throttle/brake/coast split, tyre pressures, min speed, brake points, and slip balance. It distinguishes itself from sibling tools that list laps (list_laps) or compare laps (compare_laps) by emphasizing a detailed engineering summary of a single lap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an engineer needs per-lap details for analysis, but it does not explicitly state when to use this tool versus alternatives like compare_laps or list_laps. No guidance on prerequisites (e.g., lap must exist) or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recorded laps (most recent first), optionally for one session. Returns lap ids to use with lap_summary / compare_laps.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination (limit parameter), default ordering (most recent first), and that it returns IDs for downstream tools. However, it does not disclose whether the tool is read-only, whether authentication is required, or what the response structure looks like (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states what the tool does and its ordering behavior. The second explains the output's purpose (to get lap IDs for other tools). Every part is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no required parameters, a simple output schema, and only two parameters, the description is fairly complete. It explains the ordering, optional filtering, and intended use. The only gap is potential edge cases: what happens if no laps exist for the session or if session_id is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by noting the session_id is for optional session filtering, and the limit parameter is implied by the 'most recent first' ordering. However, it does not explain the default of 20 or the range/format of these parameters, leaving the schema to carry the rest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists recorded laps sorted most recent first, and optionally filtered by session. It also specifies that the returned lap IDs are meant for use with lap_summary and compare_laps, distinguishing it from sibling tools like lap_summary and compare_laps which consume rather than list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to get lap IDs for other tools) but provides no guidance on when not to use it or how it compares to alternatives like list_sessions. It doesn't mention ordering behavior beyond 'most recent first' or that session_id is optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recorded sessions with car, track, lap count and best time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates this is a read-only operation that lists sessions with specific data fields. However, no annotations are provided, and the description does not disclose any potential side effects, performance implications, or what happens if no sessions exist. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the tool's purpose and the information it provides. It is concise and front-loaded, though it could be slightly more informative about data format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists (reducing need to detail return values), the description is nearly complete. It lacks guidance on usage context but covers the basic purpose. Adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (no parameters), but there are no parameters to explain. The description adds value by listing the output fields, which compensates for the lack of parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recorded sessions and the data fields included: car, track, lap count, and best time. It is specific and distinguishes the tool from siblings like list_laps or lap_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus others like list_laps or compare_laps. The description does not mention prerequisites (e.g., recording must exist) or when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved setup names for a car/track combo. Use the internal car folder name (e.g. 'ks_mazda_mx5_cup') and track folder name.
| Name | Required | Description | Default |
|---|---|---|---|
| car | Yes | ||
| track | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only operation via the verb 'List', and adds the requirement for internal folder names. However, it does not mention potential errors, empty results, or other side effects, leaving the full burden partially unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every word adds value. The example is concrete and immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists to describe return values. The description adequately communicates the tool's function and the critical parameter format. It could mention behaviors like empty lists or invalid combos, but these are not essential for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining that both 'car' and 'track' parameters require internal folder names, and gives an example ('ks_mazda_mx5_cup'). This adds meaning beyond the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List saved setup names' with a specific scope ('for a car/track combo'). This distinguishes it from sibling tools like read_setup and write_setup, which operate on individual setup files rather than listing names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter usage guidance (use internal folder names), but does not explain when to use list_setups versus alternatives like read_setup or write_setup. There is no explicit when-to-use or when-not-to-use guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current instantaneous state from shared memory: car, track, session status, tyre pressures/temps right now, fuel, last/best lap times. Useful to confirm AC is running and see conditions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the source ('shared memory'), the instantaneous nature, and the data categories. It doesn't mention error states (e.g., if AC is not running) or update frequency, but for a snapshot tool with zero parameters, the key behaviors are sufficiently covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence lists the data categories, and the second provides a use case. Every sentence earns its place, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no annotations, the description is quite complete. It explains what data is returned and when to use it. It could optionally mention error handling (e.g., if AC is not running), but this is a minor gap for a simple snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters and schema description coverage is 100%, so the schema provides no ambiguity. The description adds meaning beyond the schema by explaining what the output contains (car, track, session, tyre data, etc.), effectively documenting the return structure since no output schema details are known.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'current instantaneous state from shared memory' and explicitly lists the data categories (car, track, session status, tyre pressures/temps, fuel, lap times). This specific verb-resource pairing ('live snapshot' -> current state) distinguishes it from sibling tools like list_sessions or lap_summary, which return historical or derived data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance with 'Useful to confirm AC is running and see conditions,' which implies immediate, low-latency reads. While it doesn't explicitly contrast with siblings, the 'live' nature and data categories hint that this is for real-time monitoring, not historical analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a saved setup file. Returns each setting section and its value (e.g. PRESSURE_LF: 26).
| Name | Required | Description | Default |
|---|---|---|---|
| car | Yes | ||
| name | Yes | ||
| track | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It describes the read operation and return format (sections with values). However, it does not disclose read-only nature, potential side effects, or authorization needs. The example is helpful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with an example are efficient and front-loaded. No wasted words, but the lack of parameter descriptions slightly reduces completeness for the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no enum constraints, and an output schema exists, the description is adequate but not thorough. It covers purpose and return format, but leaves parameter semantics and usage context unaddressed. Completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the tool reads a saved file and returns settings, but does not describe what the three parameters (car, track, name) represent or how they identify the setup. The baseline is 4 due to zero coverage, but the description lacks specificity, making 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a saved setup file and returns settings. It is distinct from siblings like write_setup, list_setups, and other operations. The example output adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like list_setups or write_setup. No mention of prerequisites or that it requires previously saved setups. The description is purely functional without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check collector state: whether it's recording, which session, how many laps stored so far, and any error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately describes a read-only operation without side effects, listing the specific data points returned. This is sufficient transparency for a status check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently covers all key behaviors without wasted words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently explains what the tool does and what it returns. No gaps are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description correctly explains what the tool returns without needing parameter details. No additional parameter info is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks collector state, listing specific aspects like recording status, session, laps stored, and errors. It distinguishes itself from sibling tools by focusing on status rather than actions or queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving current state information, but does not explicitly state when to use it vs. alternatives like bridge_status or live_snapshot. No guidance is given on prerequisites or timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a short message on the driver's in-game Race Engineer overlay (e.g. 'claude_v2 saved: softer front ARB, +0.5psi rears - pit and load it'). Keep it to a sentence or two; the driver is driving. The message stays up until dismissed, and is replaced by any newer message.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes key behaviors: message display location (overlay), persistence ('stays up until dismissed'), and replacement behavior. Since no annotations are provided, the description carries the full burden; it adequately covers the non-destructive, ephemeral nature. Missing details on error handling or prerequisites, but acceptable for a simple messaging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and an example. Every sentence adds critical information—purpose, length constraint, persistence behavior. No fluff or repetition. The example is illustrative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no nested objects), the description covers the essential aspects: what the tool does, how to format the message, and the display/dismissal behavior. An output schema exists but is not described—acceptable since the agent can derive return type from the schema. Could mention potential failure modes (e.g., if the driver is in a menu), but the description is complete enough for regular use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter ('text') with no description (0% coverage). The description compensates by explaining that the text should be a short message, providing an example, and advising conciseness ('keep it to a sentence or two'). This adds meaningful usage guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: showing a short message on the driver's in-game Race Engineer overlay. It includes a concrete example, leaving no ambiguity about the tool's purpose. Among sibling tools (recording, snapshot, setups), it stands out uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to keep the message to a sentence or two because 'the driver is driving.' It also notes that the message persists until dismissed or replaced. However, it does not explicitly state when not to use this tool or contrast with alternatives (e.g., get_driver_notes), though such contrast is not strictly necessary given the unique function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start recording telemetry from the running Assetto Corsa session. Laps are stored automatically as they complete. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It discloses idempotency and automatic lap storage, but it does not specify what happens if a session is not running or if recording is already active. While idempotent implies safe re-call, the behavioral description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences (including the idempotent note). Every sentence adds value: purpose, side-effect, and behavioral trait. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is largely complete. It covers purpose, key behavior (idempotent), and a side effect (lap storage). It implicitly requires a running session. A brief mention of prerequisites or error cases would raise this further, but for a simple tool it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters and 100% schema coverage, giving a baseline of 4 per the rules. The description adds no parameter-level detail because none is needed, but the context provided (idempotent, automatic storage) indirectly informs behavior around parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the exact action: 'Start recording telemetry from the running Assetto Corsa session.' It uses a specific verb and resource, and the mention of automatic lap storage further distinguishes this tool from siblings like stop_recording or live_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referring to 'the running Assetto Corsa session.' It does not explicitly contrast with siblings (e.g., when to use stop_recording instead) but the purpose is clear. The idempotent hint suggests safe multiple calls, which is helpful but not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the telemetry collector.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action ('stop') without revealing whether it is idempotent, what happens if no recording is active, what side effects occur (e.g., data flush), or what the output contains. The presence of an output schema mitigates this slightly, but the description adds no behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the essential action. Every word is necessary; there is no filler or redundancy. For a simple stop tool, this is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, clear action) and the existence of an output schema, the description is minimally adequate. However, it lacks context about when to call (e.g., 'only when recording is active') and what the output signifies. For a tool that could be called inappropriately, this gap reduces completeness from optimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so the description does not need to add param meaning. The baseline score of 4 applies because the schema already fully documents the parameter structure. The description does not need to elaborate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop the telemetry collector' uses a specific verb ('Stop') and resource ('telemetry collector'), clearly distinguishing it from sibling tools like 'start_recording' (which starts) and 'recording_status' (which reports status). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that a recording must be active), nor does it explain when calling it would be ineffective or harmful. The sibling tool names imply context, but the description itself offers no explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a new setup file the user can load from the in-game setup menu.
values_json: JSON object of {SECTION: number}, e.g. {"PRESSURE_LF": 25, "PRESSURE_RF": 25, "ARB_FRONT": 4} base_setup: optional existing setup name to start from; unspecified sections are carried over unchanged.
If a ranges file exists for the car, values are clamped and snapped to the car's legal min/max/step; otherwise they're written as-is with a warning (AC silently ignores out-of-range values).
| Name | Required | Description | Default |
|---|---|---|---|
| car | Yes | ||
| name | Yes | ||
| track | Yes | ||
| base_setup | No | ||
| values_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It does explain clamping/snapping when ranges exist and a warning otherwise. However, it does not clarify whether an existing setup with the same name is overwritten, nor what the return value is. This leaves notable gaps, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose sentence, followed by parameter explanations and a key behavioral note. Every sentence adds value, including the example and ranges behavior. It is nearly perfect but could be slightly tighter (e.g., merging parentheses).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, the description covers the main functionality and an important edge case (ranges). However, it omits what the output schema contains, whether the tool can overwrite existing setups, and any prerequisites (e.g., valid car/track names). It is adequate but leaves several gaps for a tool with these signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains values_json with a clear example and describes base_setup's purpose. However, the required parameters car, track, and name are not described, leaving their semantics implied. Partial compensation keeps this at a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'write' and identifies the resource as 'setup file'. It clearly states the purpose: creating a new setup the user can load from the in-game setup menu. This distinguishes it from siblings like read_setup (read) and list_setups (list), earning a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating or modifying a setup (via base_setup), but does not explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned. The guidance is present only by implication, which is adequate but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0bridge_statuscompare_lapsget_driver_noteslap_summarylist_lapslist_sessionslist_setupslive_snapshotread_setuprecording_statussend_driver_messagestart_recordingstop_recordingwrite_setupScored across 14 tools
Each tool targets a distinct function: recording control, live data, session/lap listing, lap analysis, driver notes/messages, and setup management. No two tools overlap in purpose, making it easy for an agent to select the correct one.
Most tools follow a verb_noun pattern (start_recording, list_sessions, write_setup), but a few like recording_status, live_snapshot, and bridge_status deviate. This minor inconsistency does not hinder readability.
With 14 tools, the server is well-scoped for a race engineer domain. Each tool covers a necessary operation without redundancy or unnecessary bloat, fitting the expected complexity.
The tool surface covers recording, analysis, communication, and setup management. Minor gaps exist (e.g., no tool to delete sessions or view raw telemetry), but the core workflow for a race engineer is fully supported.
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
Manage racing sessions, telemetry, tracks, vehicles, teams, and licensed cloud features.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.
