fastf1-mcp-server

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes targeting specific data types or analyses (e.g., get_lap_telemetry vs get_sector_times vs get_pit_stops). However, some overlap exists between get_schedule and list_events (both provide calendar information) and between get_session_results and get_race_results_historical (both provide race results), which could cause minor confusion.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout (e.g., get_driver_standings, compare_telemetry, clear_cache). All tools use snake_case with clear, descriptive names, making them predictable and easy to understand.
Tool Count3/5
With 21 tools, the count feels heavy for a single-domain server, though Formula 1 data is rich. Some tools could potentially be consolidated (e.g., get_schedule and list_events), but the breadth of coverage justifies many tools. It's borderline but manageable.
Completeness5/5
The toolset provides comprehensive coverage for Formula 1 data analysis, including historical data (via Ergast API), detailed session data (via FastF1 Live Timing), telemetry, standings, schedules, and caching utilities. There are no obvious gaps for core workflows, and tools support both high-level and granular analyses.
Average 4.4/5 across 21 of 21 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions the data source and historical coverage, but does not disclose potential side effects, auth requirements, or rate limits. It is partially transparent.
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 well-structured with sections (purpose, data source, args, returns, example) and is concise, though the example could be shorter. Every sentence adds value.
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?
For a simple tool with one parameter and no output schema, the description provides sufficient context including return format and an example. It covers the main aspects needed to use the 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?
The schema has 0% coverage, but the description adds meaning by stating the parameter 'year' refers to the season year and constraining it to 1950-present, which goes 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 tool gets 'the F1 race calendar for a season', specifying both the action (get) and resource (schedule). It distinguishes from sibling tools like get_circuit_info or get_driver_info.
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 does not provide guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites. It simply describes the tool's 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, the description carries the full burden. It discloses the data source and return fields, but does not detail behavior like rate limits, error handling, or performance characteristics.
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 well-structured with Args and Returns sections, front-loaded with the purpose, and every sentence adds value without redundancy.
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 (2 optional parameters) and the presence of an output schema, the description adequately covers purpose, parameters, and return fields, though it lacks error information.
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%, but the description provides meaningful parameter details with examples (e.g., 'monaco', 'silverstone') and explains the effect of each parameter, compensating well for the missing schema descriptions.
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 'Get circuit information' and provides specific examples of circuit IDs, distinguishing it from sibling tools that focus on drivers, sessions, or other data.
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 by explaining parameters and data source, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
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 present, so the description carries the full burden. It mentions data source and historical coverage, which is helpful. However, it does not disclose behavioral traits such as error handling, read-only nature (though implied), or performance characteristics.
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 structured with clear sections: main statement, data source, coverage, args, returns. Every sentence adds value, and there is no redundancy or wasted words.
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 complexity (simple read operation) and the presence of an output schema (mentioned in description), the description adequately covers inputs and output format. Minor gap: no behavioral context like rate limits or error handling, but overall complete for typical 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?
Schema description coverage is 0%, but the description adds meaningful context: 'year: Season year' and 'after_round: Standings after specific round (default: latest)'. This clarifies the purpose and default behavior beyond the schema's type definitions.
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 'Get constructor championship standings' with specific verb and resource. It distinguishes from sibling tools like get_driver_standings by focusing on constructors and provides coverage details (1958-present).
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 lists arguments and explains 'after_round' with default behavior, but does not explicitly state when to use this tool versus alternatives or provide any when-not guidance. The context is implied by the tool name and sibling differentiation.
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 provided, so description carries burden. It discloses data source (Ergast via FastF1) and coverage (1950-present) and return fields. Missing behavioral details like rate limits or error handling, but adequate given no annotations.
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?
Description is well-structured with sections, bullet points, and a clear note. About 10 lines, no redundancy, but could be slightly more compact.
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?
For a simple retrieval tool with 2 optional params and an output schema, the description covers data source, coverage, parameter semantics, return fields, and usage context. Complete for its complexity.
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?
With 0% schema description coverage, the description adds essential meaning: explains driver_id format with examples and behavior when None, and year filter purpose. This compensates well for missing schema descriptions.
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 retrieves driver biographical info, with specific verb 'Get' and resource 'driver information'. It distinguishes from siblings like 'get_session_results' (for codes) and 'list_drivers' (likely just names).
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 use 'get_session_results' first to find driver codes, then this tool for bio details. Also explains parameters and default behavior, but lacks explicit when-not-to-use examples.
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 provided, so description must cover behavior. It reveals data source and coverage, but does not address error handling, data freshness, or potential side effects (though likely none). Adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with headings for Args, Returns, and Example. No unnecessary words, every sentence provides value.
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 (2 params, no nested objects) and presence of an output schema, the description covers purpose, parameters, and output adequately. Lacks some behavioral details but overall complete for the context.
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%, and the description compensates with clear Args explanations ('year: Season year', 'after_round: Standings after specific round (default: latest)') and an example. Adds meaning beyond the schema's types.
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 'Get driver championship standings', specifies the data source and coverage (1950-present), and distinguishes from sibling tools like 'get_constructor_standings' and 'get_driver_info' by focusing on standings.
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 parameter details and an example, making it clear when to use (for driver standings). It lacks explicit when-not-to-use or alternatives, but the context with sibling tools allows inference.
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 fully disclose behavior. It mentions the data source and coverage, but does not explicitly state that the tool is read-only or any potential side effects. The example helps, but more transparency (e.g., idempotency, auth requirements) would improve the score.
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, uses clear sections (Args, Returns, Example, Note), and every sentence adds value. It is well-structured and easy to parse.
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 (one parameter, list output), the description covers the purpose, input, output, example, and relationship to sibling. It lacks only minor details like error handling or performance, but is complete enough for an agent to use correctly.
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 no description for the 'year' parameter. The tool description adds 'Season year (1950-present)' providing clear meaning and range. With only one parameter and full coverage via description, it adds significant value beyond 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 'List all events in a season' with a specific verb and resource. It also explicitly distinguishes itself from the sibling 'get_schedule' by calling itself a 'minimal version', providing clear differentiation.
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 notes the tool is 'useful for discovering valid event names to pass to other tools' and specifies the data source and coverage. It implicitly advises using 'get_schedule' for more detail, but does not explicitly list when not to use this tool. Overall clear usage context.
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?
The description discloses data source (FastF1 Live Timing), coverage (2018-present), duration calculation method, and filtering of implausible stops (>120s) as artifacts. This provides good behavioral context despite no annotations.
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 well-structured with sections for args, returns, and a note about filtering. It is concise but includes necessary details; could be slightly shorter but no wasted sentences.
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 output schema exists, the description provides comprehensive context: data source, coverage, parameter semantics, return field listing, example, and important behavioral notes about duration and filtering.
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?
With 0% schema description coverage, the description compensates fully by clearly explaining both parameters: year (2018+) and event (race name or round number). The example demonstrates 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 states 'Get all pit stops from a race' and specifies data source and coverage. It clearly differentiates from siblings like get_lap_times and get_fastest_laps which serve different purposes.
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 retrieving pit stop data with required year and event parameters, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
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?
Since no annotations are provided, the description carries the full burden. It discloses internal behavior ('Uses laps.split_qualifying_sessions()'), a key rule ('Drivers with no recorded lap time... are omitted'), and the return structure. However, it does not cover error behavior, rate limits, or permissions.
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 well-structured with clear sections (header, data source, args, returns, example, note). It is concise, front-loading purpose, and each sentence provides necessary detail without redundancy.
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 simplicity (2 parameters, no output schema structured but described in text), the description covers inputs, outputs, behavior, and a practical example. It is fully adequate for an agent to invoke correctly.
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 no descriptions (0% coverage), but the description's Args section adds meaning: 'year: Season year (2018+)' and 'event: Race name or round number', clarifying types and constraints beyond 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 immediately states 'Get qualifying results split by Q1/Q2/Q3', specifying the verb 'get', the resource 'qualifying breakdown', and the key aspect of splitting by sessions. This clearly distinguishes it from siblings like get_session_results (which returns overall session results) and get_lap_times (which returns lap times without qualifying-specific breakdown).
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 provides context about data source (FastF1 Live Timing) and coverage (2018-present), but does not explicitly state when to use this tool versus alternatives. It does not mention when not to use it or provide comparisons to siblings.
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, the description effectively discloses data source, coverage, and filter behavior (e.g., SC/VSC using track status '1', driver exclusion). It adds value beyond the bare parameters.
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 well-structured and front-loaded with purpose, but the Args section repeats defaults already in the schema. Still, every sentence adds value, and it is not overly verbose.
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 complexity (6 parameters, various filters) and lack of output schema, the description covers purpose, parameters, output structure, and behavioral notes comprehensively. The Returns block compensates for the missing output schema.
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 schema has 0% description coverage, but the description includes an Args section that explains each parameter with defaults and meaning, fully compensating for the lack of schema descriptions.
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 'Calculate average race pace for all drivers,' specifying the verb, resource, and scope. It distinguishes from siblings like get_lap_times or get_fastest_laps by focusing on average pace and listing unique filtering options.
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 provides some usage context through the Note and Returns block, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_lap_times, get_stint_analysis).
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 provided; description carries full burden. It discloses data source, coverage, and output format but does not explicitly state read-only nature, rate limits, or potential side effects. Adequate but not comprehensive.
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?
Well-structured with sections (Args, Returns, Example, Note) and front-loaded purpose. Slightly lengthy but efficient overall.
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?
With an output schema present, description provides example output and covers all parameters, data source, and usage constraints. References alternative tool, making it self-contained and complete for the tool's complexity.
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?
Schema has 0% description coverage, but the description fully explains each parameter: year (2018+), event (name/number), session (type abbreviations). Adds substantial meaning beyond 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 'Get session classification/results', specifies the domain (F1), data source, and coverage. It differentiates from sibling 'get_race_results_historical' by recommending it for historical queries.
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?
Explicitly notes the year constraint (2018+) and directs to an alternative for historical results. However, it does not elaborate on when to use this tool versus other session-specific tools like get_qualifying_breakdown or get_lap_times, though the session parameter clarifies scope.
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, the description covers data source, coverage, timeDelta calculation, alignment to driver1, and export behavior. Lacks discussion of error handling or performance characteristics.
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?
Well-organized with intro, usage, parameter doc, returns, example, and note. Slightly verbose but appropriate for the complexity.
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?
Covers purpose, parameters, return structure, and includes example. Lacks error handling or data availability information, but sufficient for an experienced agent.
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?
Despite 0% schema description coverage, the Args section provides detailed meaning, defaults, and options for all 8 parameters, including the export_path's custom path feature.
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?
Clearly states it compares telemetry between two drivers on the same session, specifies data source and coverage, and distinguishes from siblings like get_lap_telemetry.
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 on when to use export_path and mentions auto-export at default sample size. Could be improved by stating when NOT to use or comparing to siblings.
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?
While no annotations exist, the description discloses the data source (Ergast API via FastF1), coverage (1950-present), and return fields. It lacks details on rate limits or latency but adequately covers read behavior for a historical data 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 concise, front-loads the key purpose, and uses a clear structure with bullet points for parameters and returns. Every sentence adds value.
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 presence of an output schema, the description does not need to detail return values. It covers purpose, usage guidance, data source, and return field list, making it complete for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it merely lists parameter names (year, round_num) without adding semantics like valid ranges, formats, or constraints. This adds minimal value beyond 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 identifies the tool as retrieving historical race results (pre-2018 or when session data unavailable), distinguishes it from the sibling get_session_results, and specifies the data source and coverage period.
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 (pre-2018 races) and directs to the preferred alternative (get_session_results for 2018+), providing clear context for tool selection.
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?
In absence of annotations, description fully discloses behavior: returns one fastest lap per driver, includes only accurate laps, sorted by time. Provides example with return structure.
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?
Well-structured with clear sections (Args, Returns, Example) and no fluff. Slightly long but each sentence earns its place. Example adds significant value.
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 complexity and sibling context, the description is complete: specifies data source, coverage, parameters, return format with example. Output schema exists further reduces burden.
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?
Despite 0% schema description coverage, the description compensates fully by explaining each parameter (year, event, session, top_n) with defaults and an example, adding meaning 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?
Description clearly states the tool retrieves fastest laps per driver in a session, differentiating it from siblings like get_lap_times (all laps) or get_session_results (full race results).
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?
Description implies usage for fastest lap data with coverage details, but lacks explicit when-to-use or when-not-to-use compared to similar tools. However, the purpose is clear enough for selection.
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, the description carries full burden. It discloses data source (FastF1 Live Timing), coverage range (2018-present), and explains the meaning of negative gapSec. It does not mention error handling, rate limits, or destructive behavior (appropriate as it is read-only).
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 detailed but well-structured with sections for data source, parameters, return, example, and note. It is front-loaded with the main purpose. One could argue slight conciseness improvements, but it effectively uses its length.
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 5 parameters, no annotations, and an implicitly declared output schema, the description covers all necessary aspects: purpose, parameter usage (with defaults), return format (with example), and a note on gapSec. It is fully complete for an agent to call the tool correctly.
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?
Schema description coverage is 0%, so the description must fully explain parameters. It does so: year (2018+), event (name/round), session (with examples), driver (optional, default all), include_laps (default false, effect explained). This adds crucial meaning beyond 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 'Get best sector times and theoretical best lap for each driver,' which is a specific verb+resource. It distinguishes from sibling tools like get_lap_times by mentioning per-lap sector breakdowns via include_laps.
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 explicitly instructs when to set include_laps=True, providing an example query. However, it does not explicitly contrast this tool with alternatives like get_fastest_laps or get_lap_times, leaving some ambiguity about optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It fully discloses the return structure with an example, and notes the scope (in-memory only, disk cache reported separately). No side effects are mentioned, which is appropriate for a read-only operation.
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?
Description is efficient, with clear first sentence. The example and note add value without being overly verbose. Could be slightly more concise, but overall well-structured.
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 no parameters and an output schema (inferred from the description example), the description is fully complete. It explains what is returned and the scope of the cache.
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?
Tool has zero parameters, so baseline is 4. Description adds no param info, but none is needed. The return value example compensates for the lack of 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?
Description starts with a specific verb-resource pair: 'Check server in-memory session cache status.' This clearly distinguishes it from sibling tools like clear_cache which likely mutates the cache. No ambiguity.
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?
Description states it checks in-memory cache only, implicitly guiding when to use. However, it does not explicitly state when not to use (e.g., for raw timing data) or provide alternatives like clear_cache for clearing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses data source, coverage, sampling behavior, export side effects, and response structure changes. No contradictions.
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?
Well-structured with clear sections (purpose, data source, Args, Returns, Example, Note). Slightly verbose in some sentences but overall efficient.
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?
Fully covers the tool's behavior including sampling, export, summary, and response format. Comprehensive given complexity, 7 parameters, and output schema 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?
Despite 0% schema description coverage, the description's Args section explains each parameter, including defaults, types, and usage examples, adding significant meaning beyond the bare 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?
Clearly states 'Get telemetry data for a specific lap' with specific verb and resource. Distinguishes from siblings like compare_telemetry and get_fastest_laps by focusing on single lap telemetry.
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 on when to use export_path (data analysis, plotting, etc.) and mentions auto-export thresholds. Could more directly compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses data sources, coverage, fallback logic (from results to laps when columns are empty), and defines all returned fields. This is highly transparent.
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 well-structured with sections: intro, data source, args list, returns with JSON example, and a note. Every sentence adds value; no fluff or redundancy. Length is appropriate for the complexity.
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 presence of an output schema (JSON example effectively serves that role) and detailed behavioral notes, the description covers all necessary aspects: what it does, parameters, return structure, data sources, and edge cases (fallback). No gaps identified.
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?
Input schema describes parameters but none have descriptions (0% coverage). The description compensates by listing each parameter with context: year (2018+), event (race name or round number), session (R, Q, etc.). An example is provided, but additional guidance on valid string formats for event would improve clarity.
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 'Get speed trap and top-speed data for all drivers in a session', which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_lap_times or get_sector_times by focusing on speed trap and top-speed 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 context about data source (FastF1 Live Timing), coverage (2018-present), and includes an example call. It does not explicitly state when to use or when not to use, but the detail is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses data source, coverage, auto-export behavior, phantom stint filtering, and accurate lap inclusion. It explains the side effects of export_path and directory configuration, leaving no ambiguity.
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 well-structured with sections (purpose, data source, params, returns, notes) and front-loaded with key info. While thorough, it is slightly verbose but still concise for the detail provided.
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 no annotations and an output schema (partially described), the description covers all necessary aspects: parameters, return structure, edge cases (auto-export, phantom laps), and usage context. It is complete for the tool's complexity.
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?
Despite 0% schema description coverage, the description richly documents each parameter: year range, event flexibility, driver default, and export_path's boolean/string variants with detailed behavior. It adds significant value beyond the bare 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 'Analyze tire stints for a race,' using a specific verb and resource. It distinguishes this tool from siblings like get_race_pace and get_lap_times by focusing on stint-level analysis.
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 explicit guidance on when to set export_path, including user intents like data analysis or large responses. However, it does not explicitly state when to prefer this tool over alternatives, though the purpose clarity implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses data sources (Ergast API vs FastF1), coverage years, return fields, and the note about event requiring year>=2018. This is transparent about behavioral aspects.
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 structured with sections (Args, Returns, Example, Note) and each part adds value. It is somewhat verbose but not wasteful; all sentences contribute to clarity.
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 2 parameters, output schema, and sibling tools, the description is comprehensive. It covers purpose, parameters, return format, example, data sources, and limitation about event filter, leaving no obvious gaps.
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?
Schema has 0% description coverage, but the description fully explains year as season year and event as optional race name or round number. Example shows usage and output, making semantics clear.
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 all drivers in a season, optionally filtered by event, which is a specific verb+resource. It distinguishes from sibling tools like get_driver_info and get_session_results by focusing on driver listing rather than detailed info or session results.
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 when to use with/without event, and mentions data source limitations (1950-present for season, 2018-present for event filter). It does not explicitly list alternatives, but the context of sibling tools and the note about faster response without event gives implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 fully discloses behavioral traits: clears only in-memory LRU cache, preserves disk cache, returns a JSON with cleared and remaining counts, and parameter constraints (event requires year).
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 well-structured with Args, Returns, Example, and Note sections. Every sentence adds value, and the example clarifies expected usage. No wasted words.
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 no annotations and a complete input schema, the description provides all necessary context: clear action, parameter constraints, return format, and side effects (no effect on disk cache). The output schema exists but the description already explains return values.
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?
Schema description coverage is 0%, but the description compensates excellently. It explains each parameter's purpose ('year: Optional year filter', 'event: Optional event filter — requires year to be set') and provides example calls demonstrating 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 clearly states the tool's action: 'Clear cached sessions from in-memory storage.' It uses a specific verb (clear) and resource (cached sessions), and the note about disk cache distinguishes it from sibling tools like get_cache_status.
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 does not explicitly say when to use vs. alternatives, but it notes that the disk cache is preserved, which guides usage. It lacks explicit exclusion statements (e.g., 'use get_cache_status to view cache').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses data source (FastF1 Live Timing), coverage (2018-present), auto-export behavior, and the dual response format (with/without export). It explains that deleted laps are excluded by default and that summary provides aggregated info to avoid parsing the full array.
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 well-structured with clear sections (data source, coverage, usage hint, Args, Returns, Note). It is front-loaded with the core purpose and each sentence earns its place. Despite length, it remains focused and avoids redundancy.
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?
With six parameters, no annotations, and a detailed output schema documented inline, the description covers all necessary aspects: parameter explanations, behavior, return format, and edge cases (deleted laps, auto-export). It is fully complete for an agent to select and invoke the tool correctly.
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?
Schema description coverage is 0%, so the description must fully explain parameters. It does so for all six parameters: year, event, session, driver, include_deleted, and export_path. It provides types, defaults, and special behavior (e.g., export_path accepts custom directory or file path, auto-export threshold). This adds significant value beyond 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 states it retrieves all lap times for a driver in a session, specifying the verb (get), resource (lap times), and scope (per driver per session). It clearly distinguishes from sibling tools like get_fastest_laps (which gets only fastest laps) and get_sector_times (sector-level data).
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 provides explicit usage guidance: when to set export_path (e.g., data analysis, ML, save as CSV) and mentions auto-export for >50 laps. It also advises setting include_deleted to include deleted laps. While it does not explicitly contrast with siblings, the purpose is distinct enough that no further exclusions are needed.
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:

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

Score Badge

Copy to your README.md:

[![fastf1-mcp MCP server](https://glama.ai/mcp/servers/Surya96t/fastf1-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Surya96t/fastf1-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/Surya96t/fastf1-mcp'

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