Skip to main content
Glama

CarGene

by com.car-gene
OverviewDiscussionsAdmin

Get relationships between generations

get_vehicle_relationships
Read-onlyIdempotent

Get the relationships between generations (succession, sibling, derivation, spiritual successor). A series_id returns the relations of the whole series; a model_id returns only the relations that have that generation at either end. Returns {series_id, url, total, relations, next_offset}, plus model_id when given: each relation has kind and kind_name, kind_directed, from_model and to_model (each with id, name, chassis_code, start_year, end_year, series_name and public page url), and where the source requires one, source_url with the verbatim source_excerpt; rationale is filled for spiritual successors. When kind_directed is false the two ends are interchangeable, so treat the relation as belonging to both generations. Relations are cut to fit the response size; when next_offset is not null, call again with offset set to it. An empty relations list means not researched yet, never that the car has no relatives.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoWhere to start in the list; pass next_offset from the previous response. Omit to start from the beginning.
model_idNoGeneration (model) id (a UUID from search_vehicles). Takes precedence over series_id when both are given.
series_idNoSeries id (a UUID from search_vehicles).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Where to start in the list; pass next_offset from the previous response. Omit to start from the beginning.",
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnly and idempotent annotations by explaining pagination behavior ('Relations are cut to fit the response size'), the meaning of next_offset, and the important semantic that an empty relations list means 'not researched yet' rather than 'no relatives'. It also details how kind_directed=false affects interpretation, which is genuinely useful behavioral context.

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?

Every sentence in the description earns its place: purpose, parameter scoping, return shape, directionality semantics, pagination, and empty-list meaning are all covered without redundant filler. The most important scoping information comes first, and complex details are packed efficiently.

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?

Because there is no output schema, the description carries the full burden of explaining the return value, and it does so thoroughly: field names, nested relation structure, source_url, rationale, directionality handling, pagination, and empty-list semantics. The operation is read-only and idempotent per annotations, so no additional safety caveats are needed.

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 is 3, but the description adds meaningful semantics beyond the schema: it explains that series_id scopes to the whole series and model_id scopes to relations with that generation at either end. It reinforces the offset contract by telling the caller to pass next_offset from the previous response. This exceeds the baseline.

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 a specific action and resource: 'Get the relationships between generations' and enumerates relationship types (succession, sibling, derivation, spiritual successor). It clearly distinguishes the series-level versus model-level scope, and its domain is obviously different from the sibling tools (sales, vehicle details, search).

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 clear context for choosing between series_id and model_id: series_id returns relations for the whole series, while model_id returns only relations involving that generation. It does not explicitly name alternatives or exclusions relative to sibling tools, but the parameter-selection guidance is strong and the tool's purpose is distinct enough that this is a minor gap.

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

All CarGene toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources