This server turns Claude into a race engineer for Assetto Corsa: it records telemetry, analyzes laps and setups, and communicates with the driver through an in-game overlay.
Record telemetry sessions – start/stop recording; laps are stored automatically as they complete.
Check recording status – see whether recording is active, which session, lap count, and errors.
Get live car/session state – car, track, session status, tyre pressures/temps, fuel, and last/best lap times.
List sessions and laps – browse recorded sessions and laps, with lap IDs for deeper analysis.
Get engineer-grade lap summaries – lap time, throttle/brake/coast split, tyre data, per-corner min speeds, brake points, and understeer/oversteer slip balance.
Compare laps – corner-by-corner min speed and brake point deltas to evaluate setup changes.
Read/write setups – save setup files that appear in the in-game setup menu; values are clamped to legal ranges when known.
List/read saved setups – for a given car and track.
Read driver complaint notes – understeer/oversteer/braking/traction tags recorded in-game, with spline position for correlation to corners.
Send driver messages – show notes on the in-game Race Engineer overlay.
Check bridge health – verify the HTTP bridge between the in-game app and the server is working.
Suspension analysis – damper histograms, ride height, rake, roll balance, and plank wear, with capture-tier awareness.
Supports an in-game Lua app (via CSP) that provides driver complaint tagging, status overlay, and message display from Claude.
Example car reference (ks_mazda_mx5_cup.ini) used to demonstrate setup range clamping with setup.ini files.
Provides the runtime environment for the MCP server, with tools for managing Python execution paths and packages.
Stores lap telemetry data persistently, allowing lap storage, retrieval, and comparison for analysis.
Assetto Corsa is distributed via Steam; the server integrates with the game's installation directory and shared memory telemetry.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ac-race-engineer read my current telemetry and tell me if I'm oversteering in T3"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Turn an AI assistant into a race engineer for Assetto Corsa.
Drive a few laps, then ask it what the car is doing. It reads AC's live telemetry, stores every lap, reduces them to the numbers an engineer actually reasons about — corner minimum speeds, brake points, tyre pressures and temps, understeer/oversteer balance, damper behaviour — and writes revised setups that appear straight in your in-game setup menu.
Then you drive again, and it tells you whether the change actually worked or whether you just had a good lap.
Runs on the Windows PC that runs Assetto Corsa. Original AC only — it uses the
acpmf_*shared memory layout, not ACC's.
Assetto Corsa on Windows, with Custom Shaders Patch (you already have it if you use Content Manager with CSP enabled)
An MCP client — anything that can launch a local stdio MCP server: Claude Desktop, Claude Code, ChatGPT Desktop, Cursor, Windsurf, VS Code with Copilot, or LM Studio if you'd rather run the model locally too. This is a standard MCP server and doesn't care which one you use.
Python 3.10 or newer from python.org — on the installer's first screen, tick "Add python.exe to PATH". Don't use the Microsoft Store build; its sandboxing breaks shared-memory access.
Related MCP server: fastf1-mcp-server
In this folder: right-click install-windows.bat → Open (or just
double-click it).
The installer finds Python, installs the package, locates your Assetto Corsa
install, copies the in-game app into place, and registers the server with
Claude Desktop — merging with any MCP servers you already have, and taking
a backup first. Re-run it any time after a git pull; it updates in place.
Then fully quit your client and reopen it. For Claude Desktop, closing the
window isn't enough — right-click the tray icon (bottom right, possibly hidden
under the ^ arrow) and choose Quit.
Using a different client? Add -SkipClientConfig. Everything else installs
the same way, and the installer prints the two lines you need to paste into
your client's config:
install-windows.bat -SkipClientConfigdocs/INSTALL.md has the config snippet for each client.
Other flags: -AcPath "D:\Games\steamapps\common\assettocorsa" if it can't
find the game, -SkipLuaApp, -Uninstall.
Prefer to do the whole thing by hand? Also docs/INSTALL.md.
Something went wrong? Run diagnose.bat, then see
docs/TROUBLESHOOTING.md.
Recording starts by itself and waits for the game, so there is nothing to remember to switch on.
1. Get on track and check the assistant can see you.
"Confirm you can see my session."
2. Drive 3–5 laps. They store as they complete — every lap, including out-laps and the one that ended in the barrier. Each is flagged for what it is, so a lap whose time isn't a lap time can't poison your best-lap numbers.
3. Ask what the car is doing.
"Summarize my last lap and read my current setup."
You'll get per-corner minimum speed and brake points, tyre pressures and temperatures, ride height and damper behaviour, and a slip-balance number — positive means understeer, negative means oversteer.
4. Talk it through, and have it write a setup.
"It pushes on entry at the second-to-last corner. Try something and save it as
claude_v1."
Values are clamped to what your car will actually accept, so the game can't silently ignore them. Two things it will refuse rather than do quietly: reusing an existing setup name, and writing at all when it has no ranges for the car — which is what happens if the in-game app has never seen the setup screen.
It'll also tell you what each value reads as on the setup screen, which is often a different number from the stored one — or say it doesn't know, rather than guessing. Read a couple off the screen for it and it won't have to ask again:
"At minimum front toe shows 0.40, at maximum -0.40."
Details: docs/SETUP-RANGES.md.
5. Pit, load the setup — then say you loaded it.
"I've loaded claude_v1."
This step matters. Nothing in shared memory reveals which setup is on the car, so this is the only way laps get labelled correctly. It applies to laps from here on; the baseline you already drove keeps whatever it had, including nothing.
If you realise afterwards that some stored laps were on a setup nobody
recorded, say which ones — "laps 41 to 44 were on baseline". It only fills
laps that have no setup yet, and only the ones you name.
6. Drive again, and ask whether it worked.
"Compare my best lap on the new setup against lap 14."
Corner-by-corner deltas in minimum speed and brake point. For more than one lap a side, ask it to compare the two runs — it judges the change against your own lap-to-lap spread, so "faster" has to beat "you were just quicker that lap".
7. Ask where you actually drove.
"Where was my line different between those two laps?"
The in-game app (right edge of the screen → apps sidebar) gives you:
Four complaint buttons — Understeer, Oversteer, Braking, Traction — each bindable to a wheel button in the app's Settings window. Press one the moment you feel it and it records exactly where on track you were. Those get correlated with the telemetry: "you flagged understeer twice at the same corner — that's where front slip exceeds rear by 0.09."
A status overlay — recording state and laps stored, so you never alt-tab to check. If laps are finishing and none are landing, it says so plainly rather than repeating whatever the server claims.
Messages back from the assistant — "claude_v2 saved — pit and load it."
Everything stays on your machine. It's a SQLite file at
~/.assetto-mcp/telemetry.db, the in-game app talks to the server over
localhost only, and nothing is uploaded anywhere.
While recording, at 25 Hz:
Car state — speed, throttle, brake, steering, gear, RPM, lateral and longitudinal acceleration
Tyres — per-wheel slip, pressure, core temperature and wear
Chassis — front and rear ride height, world position, heading, pitch and roll, how many tyres are off track, and bodywork damage
Electronics — whether TC and ABS are actually intervening
From the in-game app — suspension travel, wheel loads and plank wear, at up to 333 Hz. Only the last 20 laps of a session are kept; these are by far the biggest rows in the database.
Every lap is kept, including the ones that don't count: out-laps, laps with a pit stop, laps that ran wide, and laps that ended in the barrier. Each is flagged for what it is rather than thrown away — a lap that ran wide still has real corner speeds and brake points on it, and the lap that ended in the wall is often the one you most want to look at. What the flags do is stop a lap whose time isn't a lap time from being ranked or averaged.
Per session it also stores the car, track and layout, tyre compound, air and road temperature, track length, the car's fuel consumption and tank size, the setup name you gave it, and a copy of every setup value currently on the car — that copy is what lets it work out later which setup a lap was driven on. Per lap: the time, and whether it counted.
Two things worth knowing:
Complaint tags record which button you pressed, where on track, on which lap, and at what speed.
Other cars on track are logged too — car index, driver name, car model, lap times, and speed/gear/throttle/brake traces — because that's what makes "compare me to the car ahead" work. This covers AI opponents as well as multiplayer, so in an online session other people's names end up in your local database.
Setup files are read from and written to your normal Assetto Corsa setup
folder. Only files whose name you ask for are written, and reusing the name of
an existing setup is refused unless you say to overwrite it — in which case the
old file is kept alongside as <name>.ini.bak-<timestamp>.
About 0.4 MB per lap, so roughly 12 MB per hour of driving.
No lap is ever deleted, and neither is anything derived from one — lap times, setups and the off-track evidence stay exactly as recorded. When the database passes its size budget (2 GB by default), the oldest sessions' traces are thinned instead: every 2nd sample, then 4th, and so on. An old lap gets coarser, never absent.
Two things that are dropped outright, from older sessions only: the traces of other cars on track, and the high-rate suspension samples. Both answer questions about the session they were recorded in and not much after it.
Because lap rows are kept forever, the budget is a target rather than a hard
ceiling — a database of nothing but fully-thinned laps still grows, slowly.
Ask for a storage report to see where you are. ASSETTO_MCP_MAX_DB_BYTES
changes the budget; 0 turns off budget-driven thinning entirely (the
per-session cap on suspension samples stays either way).
diagnose.bat writes a report that redacts other MCP servers' secrets on a
best-effort basis, but still contains your username and absolute paths. Skim it
before sharing it.
Manual install, config file locations, environment variables, upgrading from | |
When your client shows no tools, when laps stop landing, and the rest | |
How setup values are clamped, why AC's spinner isn't a grid | |
Corner detection, data-quality flags, driving line, suspension capture tiers | |
Running the tests, CI, schema changes | |
What's known to be broken, worst first, with where it bit |
Read lap validity from the game. Track limits are now scored from recorded wheels-off evidence rather than guessed at, and no lap is dropped from a comparison for it — but it's still inference. CSP will hand the game's own verdict to a physics worker, which is a thing this already runs, so this is wiring rather than research. Single-player only.
Entry-phase corner metrics — trail braking, rotation and steering between the brake point and the apex. That's where most spins live, and nothing currently measures it.
Detect a change in consistency, not just a change in mean pace. A setup that stops you spinning may not move your average lap time at all, and the current statistics call that "within noise".
Use the channels already being recorded — tyre wear across a stint, TC and ABS intervention, body roll. All logged, none read yet.
Fill in the display registry. It no longer guesses what your setup screen shows — it says "unknown" and asks — but it only knows a car once you've read a couple of values off the screen for it.
Per-track corner names, so advice reads "T3 / Variante" rather than "the corner at 0.34".
This is built by one driver against two cars and three circuits, so the places it's wrong are mostly the places it hasn't been. If a number disagrees with what you feel in the car, that's worth reporting — the driver has been right about that more often than the tooling has.
Please open an issue for anything that surprised you: a lap marked invalid that shouldn't have been, a setup value that didn't stick, a car whose ranges come out wrong, an analysis that said "within noise" about a change you're certain you felt. Say which car and track, and include the lap numbers if you have them.
Pull requests are very welcome. python run_tests.py needs no dependencies
and runs everywhere — no Windows and no Assetto Corsa required, because the
collector is driven through a fake shared-memory source and the in-game app runs
against a stubbed CSP API. See docs/DEVELOPMENT.md, and
BACKLOG.md if you'd like somewhere to start.
Support for another MCP client is a particularly welcome PR: the server itself
is client-agnostic, and install-claude-desktop.ps1 is the only file that knows
about a specific one.
MIT. Not affiliated with Kunos Simulazioni, Assetto Corsa, or the Custom Shaders Patch project.
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. Dates show when Glama detected each change.
v0.1.0bridge_statuscompare_lapsget_driver_noteslap_summarylist_lapslist_sessionslist_setupslive_snapshotread_setuprecording_statussend_driver_messagestart_recordingstop_recordingwrite_setupEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
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.
Give Claude only the Google Drive files you choose. Every action logged.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mishan/assetto-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
