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 power, torque, weight, dimensions or prices, use get_vehicle_specs. For the engineers 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

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.4/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds substantial edge-case semantics beyond annotations: null = still on sale, empty lists mean not researched rather than none, null link_source_url means unverified, and unknown ids raise an error instead of returning empty.

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?

Front-loaded with the return shape and the primary/secondary mode, then caveats and sibling routing. It is dense and somewhat long, but nearly every clause carries distinct operational meaning; minor redundancy between the opening sentence and the 'Returns {...}' sentence.

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 no output schema, the description fully specifies the return payload, per-entry fields, null semantics, and error behavior, so an agent can call it and interpret results correctly without further documentation.

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% and already documents both UUID parameters and precedence. The description reinforces this and adds meaning about what each mode returns (series-level list always whole series vs. single-generation detail), giving the agent more than the schema alone.

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?

States a specific verb and resource (get one series with its generations/models and sources) and explicitly scopes the model_id variant to a detailed single generation. It distinguishes itself from get_vehicle_specs by naming what that sibling covers instead.

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?

Explicitly routes the agent: 'For power, torque, weight, dimensions or prices, use get_vehicle_specs' and 'For the engineers of several generations, call once per model_id.' It also states the exactly-one-of series_id/model_id constraint and that model_id takes precedence.

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