Skip to main content
Glama

Get a series with its generations

get_vehicle
Read-onlyIdempotent

Get one series with the list of its generations (models) and the cited sources, and with a model_id also that generation in detail. Returns {series, maker, models, sources}, plus model when a model_id is given. Each entry in models has id, name, chassis_code, start_year, end_year (null = still on sale), description, source_url and its public page url; the list is always the whole series. model is the named generation with drivetrains, displacements (engine displacement in cc, one row per engine), and engineers (each with role_name, source_url citing the person's own career, and link_source_url citing that person's work on this very generation; a null link_source_url means not researched yet, so do not read source_url as evidence for this generation). sources are the cited references for the descriptions (url, title, publisher, accessed_on, and model_id: null for the series overview, otherwise the generation whose description it supports); a generation's own sources come only with its model_id. For the engineers or specs of several generations, call once per model_id. An empty drivetrains, displacements, engineers, or sources list means not researched yet, never none. Unknown ids are an error, not an empty result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the operation as read-only, idempotent, and non-destructive, and the description adds substantial behavior beyond that: null end_year means still on sale, empty lists mean 'not researched yet' rather than absence, null link_source_url must not be treated as source evidence, unknown IDs are errors, and source ownership is generation-specific. This is exactly the kind of contextual behavior an agent needs.

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?

While long, the description is densely packed and every sentence carries essential semantics: return shape, null conventions, empty-list conventions, source scoping, and error behavior. The main purpose is front-loaded, and the supporting details are organized logically rather than padded.

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?

For a tool with no output schema, the description fully covers return values, field meanings, edge-case conventions, and error handling. It also addresses multi-call behavior for several generations, leaving no critical gap for an agent deciding whether and how to invoke the tool.

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 coverage is 100% and the schema already documents both series_id and model_id, including precedence. The description enhances parameter meaning by explaining how model_id changes the returned payload, how per-generation source lists only appear with model_id, and that repeated calls per model_id are needed for multi-generation specs.

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 names a specific operation ('Get one series') plus the optional detail path via model_id, and spells out the exact return shape {series, maker, models, sources}. This clearly distinguishes it from sibling tools like get_vehicle_relationships or get_sales_figures without needing their schemas.

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 gives clear context for when to use the tool, such as retrieving a series with generations or a single generation in detail, and explicitly advises calling once per model_id for engineers or specs of several generations. It does not explicitly compare against sibling tools, but the scoping is clear enough that an agent can infer the right context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources