Servidor MCP que convierte a Claude en un ingeniero de carrera para el Assetto Corsa original. Lee la telemetría de memoria compartida de AC, almacena vueltas en SQLite, las reduce a resúmenes de nivel de ingeniero, y puede leer/escribir archivos de configuración que aparecen directamente en el menú de configuración del juego.
Se ejecuta en la máquina Windows que ejecuta Assetto Corsa. Solo AC original (usa el
layout de memoria compartida acpmf_*, no el de ACC).
Requisito previo: Python 3.10+ desde python.org. En la primera pantalla del instalador marca "Add python.exe to PATH". No uses la compilación de Microsoft Store — su espacio aislado rompe el acceso a la memoria compartida.
Luego, en esta carpeta: haz clic derecho en install-windows.bat → Abrir (o simplemente
haz doble clic en él).
Eso es todo. El instalador encuentra Python, instala el paquete, escribe la configuración
de Claude Desktop (fusionándola con cualquier servidor MCP que ya tengas, y haciendo
una copia de seguridad primero), localiza tu instalación de Assetto Corsa y copia
la aplicación Lua del juego en su lugar. Vuelve a ejecutarlo en cualquier momento después de un git pull; se actualiza en el sitio.
Si no puede encontrar Assetto Corsa, indícale dónde buscarlo. Las banderas van en el .bat,
no en el .ps1 — Windows bloquea la ejecución directa de archivos .ps1 bajo la
política de ejecución predeterminada, y el .bat existe precisamente para solucionar eso:
install-windows.bat -AcPath "D:\Games\steamapps\common\assettocorsa"Otras banderas: -SkipLuaApp, -Uninstall.
Después de instalar, cierra completamente Claude Desktop y vuélvelo a abrir.
Cerrar la ventana no es suficiente — haz clic derecho en el icono de Claude en la bandeja del sistema
(abajo a la derecha, posiblemente oculto bajo la flecha ^) y elige Salir.
Related MCP server: fastf1-mcp
python -m pip install -e .Luego añade el servidor a claude_desktop_config.json. La forma más rápida de abrir
ese archivo es Claude Desktop → Configuración → Desarrollador → Editar Config, que
lo crea si falta y abre la carpeta contenedora — sin necesidad de arqueología del sistema de archivos.
%APPDATA% es una variable de entorno, no una ruta literal. Se expande a
C:\Users\<tu_usuario>\AppData\Roaming — y AppData es una carpeta oculta, por lo que
navegar hasta ella en el Explorador no muestra nada a menos que actives Ver → Elementos ocultos.
El problema más grande: %VAR% es sintaxis de cmd.exe. Windows Terminal usa
PowerShell por defecto, donde la misma variable se escribe $env:VAR. Así que:
Dónde | Qué escribir |
PowerShell / Windows Terminal |
|
cmd.exe |
|
Barra de direcciones de Explorer |
|
Win+R (diálogo Ejecutar) |
|
Para abrir la carpeta en lugarr del archivo, usa explorer $env:APPData\Claude
en PowerShell.
{
"mcpServers": {
"ac-race-engineer": {
"command": "C:\\Users\\<you>\\AppData\\Local\\Programs\\Python\\Python312\\python.exe",
"args": ["-m", "ac_race_engineer.server"]
}
}
}Usa la ruta absoluta a python.exe, no solo "python". Claude Desktop
inicia los servidores MCP sin el PATH de tu shell, por lo que un comando simple
falla frecuentemente en silencio. Obten la ruta correcta con:
py -c "import sys; print(sys.executable)"No uses (Get-Command python).Source — en Windows estándar eso a menudo devuelve
...\WindowsApps\python.exe, el alias stub de Microsoft Store, que es la
respuesta incorrecta. Recuerda qu eJSON necesita las barras invertidas duplicadas (\\).
(Si usas Claude Code en su lugar:
claude mcp add ac-race-engineer -- python -m ac_race_engineer.server)
Anulaciones opcionales del entorno:
AC_DOCS_DIR — carpeta de document osde AC (por defecto ~/Documnts/Asetto Corsa)
AC_ENGINER_DAA — ubicación de la BD + rangos (por defecto ~/.ac-race-engineer)
AC_ENGINEER_BRIDGE_PORT — puerto del puente de la aplicación en el juego (por defecto 9666)
Claude no lista las herramientas. Confirma que cerraste y reabriste completamente Claude Desktop (icono de la bandeja → Salir). Luego le e el log del servidor:
notepad $env:APPDATA\Claude\logs\mcp-server-ac-race-engineer.logEscribir python abr e la Tienda Microsoft (o dice "no reconocido").
Windows incluye un alias de ejecución de aplicación en
%LOCALAPPDTA%\Microsoft\WindowsApps\python.exe que secuestra el nombre cuando no hay
Python real en PATH. Instala Python desde python.org con "Add python.exe to
PATH" marcado, o usa el lanzador py (py -3 -m pip install -e .) — el
instalador de python.org configura eso por defecto. También puedes matar el stub en
Configuración → Aplicaciones → Configuración avanzada de aplicaciones → Alias de ejecución de aplicaciones.
El instalador ya ignora todo lo que está bajo WindowsApps, así que esto solo te
afecta en una instalación manual.
**.ps1 no se puede cargar porque la ejecución de scripts está deshabilitada.**Esa es la política de ejecución. Usa install-windows.bat en su lugar — elude la política
para ese script en particular sin cambar ninguna configuración del sistema.
Los valores de configuración no se mantienen en el juego. Estás escribiendo fuera del rango legal del coche y AC los está ignorando en silencio — consulta la siguiente seción.
Inicia AC, sal a la pista.
Dile a Claude: "empieza a grabar y confirma que puedes ver la sesión"
(start_recording, live_snapshot).
a. Conduce 3–5 vueltas. Las vueltas se almancen automáticamente al completarse; las
excursiones fuea de pista (>2 neumáticos fuea) maran una vuelt como inválida.4. "Resume mi última vuelt y lee mi configuración actual"
(list_laps, lap_sumary, read_setup). El resumen inclu ye por cada curva
velocidad mínima, puntos de frenado, presiones/temperaturas de neumáticos, y una métrica de
balance de derape (positivo = subviracón, negativ = sobrviracón).5. Discute lo que está haciendo el coche; Claude escrib una configuración revisada con
write_setup (por ejemp lo, como claude_v1).6. Entra en boxes, carga claude_l desde la pantalla de configuración, vuele a conducir.7. "Compara mi mejor vuelt con la nueva configuración contra la vuelt N" (compare_laps) —
los deltas de velocidad mínima y punto de frenado por curva muestran si el cambio
realmente funcionó.
AC ignora en silencio los valores de configuración fuera de los rangos definidos en el
setup.ini del coche (dentro de data.acd). Para permitir que el servidor limite y ajuste
los valores al mínimo/máximo/paso legal de cada coche:
En Content Manager: página del coche → descomprimir datos (o usa QuickBMS).
Copia el setup.ini del coche en la carpeta de rangos, nombrado según el nombre de la
carpeta del coche — por ejemplo, ks_mazda_mx5_cup.ini.
Para abrir esa carpeta (el instalador ya la creó):
explorer $env:USERPROFILE\.ac-race-engineer\ranges(cmd.exe: explorer %USERPROFILE%\.ac-race-engineer\ranges)
Sin un archivo de rangos, las escrituras aún funcionan pero devuelven una advertencia, y deberías verificar los valores en la pantalla de configuración.
install-windows.bat copia esto por ti. Para hacerlo a mano, copia
lua_app/race_engineer/ a assettocorsa/apps/lua/race_engineer/ (requiere
Custom Shaders Patch; ya lo tienes si usas Content Manager con CSP habilitado). Actívalo desde
la barra lateral de aplicaciones en el juego — mueve el ratón al borde derecho de la pantalla
mientras estés en una sesión.
¿No estás seguro de dónde está instalado Assetto Corsa? En Steam, haz clic derecho en Assetto Corsa → Administrar → Examinar archivos locales.n Lo que hace:
Etiquetas de queja mientras conduces — Botones de Subviraje / Sobreviraje / Frenado /
Tracción, cada uno asignable a un botón del volante a través de la ventana de Configuración
de la aplicación (aparecen como enlaces de control de CSP). Pulsar uno registra tu
posición exacta en la spline, vuelta y velocidad. Claude los lee con
get_driver_notes y los correlaciona con la telemetría de la curva: "marcaste
subviraje dos veces en la spline 0.34 — esa es la curva donde el deslizamiento delantero
supera al trasero en 0.09".
Superposición de estado — indicador de grabación + vueltas almacenadas, para que nunca tengas que hacer Alt+Tab para comprobarlo.
Mensajes de Claude — send_driver_message pone una nota en la
superposición ("claude_v2 guardado — entra en boxes y cárgalo"); descartar con OK.
La aplicación se comunica con el puente HTTP del servidor en 127.0.0.1:9666 (cambia con
AC_ENGINEER_BRIDGE_PORT, y edita BASE en el Lua para que coincida). El puente
se vincula solo a 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 aboveEl muestreo es de 25 Hz — suficiente para trabajo de configuración mientras mantiene la BD
pequeña. Aumenta TARGE_HZ en collector.py si quieres trazas más finas.
Las vueltas de salida (sin tiempo válido) se saltan automáticamente.
La detección de curvas es genérica (mínimos de velocidad); un mapa de nombres de curvas por pista haría que los consejos de Claude se leyeran mejor ("T3/Variante" vs "curva en 0.34").
CSP/Lua podría exponer velocidades de amortiguación y más canales que la memoria compartida estándar si alguna vez quieres un trabajo de suspensión más profundo — el código fuente de Telemetrick es una buena referencia.
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.
