Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

formula1_json_driver_assembly

Retrieves a Formula 1 driver's full editorial assembly payload by reference code or slug, including SEO copy, images, video stories, pull quote and related articles.

Instructions

One Formula 1 driver's editorial assembly. Returns one driver's full editorial assembly payload exactly as the API sends it: the driver reference and identifier, SEO copy, profile and logo images, shop link, results-archive CTA, pull quote, vertical video stories, gallery images and the related article/video assemblies. Use either reference (the alphanumeric driver code from formula1-json-drivers) or identifier (the driver slug), never both.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "formula1_json_driver_assembly"
  }
}

Input Schema

NameRequiredDescriptionDefault
referenceNoAlphanumeric driver reference from formula1-json-drivers, such as ALEALB01 example(ALEALB01)
identifierNoDriver identifier (lowercase letters and hyphens) such as alexander-albon example(alexander-albon)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It does well on what the response contains and notes the response is returned 'exactly as the API sends it', but it doesn't state what happens when neither selector is supplied (the schema marks both optional), nor anything about error behavior or read-only nature beyond the implicit 'returns' framing.

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 payload enumeration is front-loaded and the selector constraint comes last as an actionable rule. The long content list is dense but each item is a distinct part of the returned payload, so little is wasted; a slight trim of the enumeration would tighten it further.

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?

There is no output schema, so the description appropriately compensates by listing return contents in detail. The main remaining gap is the ambiguity around the zero-required-parameter schema versus the 'use either' instruction, which an agent may need to resolve at call time.

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 coverage is 100%, so the baseline would be 3, but the description adds the mutual-exclusivity rule ('never both') that the schema itself does not express, plus the provenance of each identifier. That is genuine meaning beyond the structured fields.

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 gives a specific verb and resource — returns one Formula 1 driver's full editorial assembly payload — and enumerates the payload contents (SEO copy, images, shop link, CTA, pull quote, video stories, gallery, related articles). This is clearly distinguishable from formula1_json_drivers, which it names as the source of the reference codes, though it does not explicitly contrast with formula1_json_editorial or formula1_driver.

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?

It supplies one concrete usage rule: pass either `reference` or `identifier`, never both, and it points to formula1-json-drivers as the origin of the reference code. However, it never states when an agent should prefer this tool over formula1_driver or formula1_json_editorial, so the routing guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools