ac-race-engineer

by mishan

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.8/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![assetto-mcp MCP server](https://glama.ai/mcp/servers/mishan/assetto-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mishan/assetto-mcp)

Score Badge

Copy to your README.md:

[![assetto-mcp MCP server](https://glama.ai/mcp/servers/mishan/assetto-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mishan/assetto-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mishan/assetto-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server