Skip to main content
Glama

Get Vehicle Information

get_vehicle_info
Read-onlyIdempotent

Fetch a vehicle's identity and energy snapshot by VIN or partial name, showing model, range, charging state, and online status.

Instructions

Get a vehicle's identity plus a quick energy snapshot: manufacturer, model, name, VIN, online/connection state, last-seen timestamp, electric range (km), charging flag, plug-connected flag. vehicle_id accepts a VIN or a partial, case-insensitive name -- the response's own vin/name confirm exactly which vehicle matched. {"error": "..."} means no vehicle matched vehicle_id; {"error": "server_unavailable", "error_type": ...} means the server itself needs attention instead (e.g. re-authorization). Cached for 5 minutes. Read-only -- no vehicle setting can be changed and nothing can be started or stopped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vehicle_idYesVehicle identifier (VIN or name, partial names allowed)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 readOnlyHint and idempotentHint annotations by disclosing caching behavior, read-only guarantees, partial-name case-insensitive matching, and detailed error semantics. It also clarifies that a server-side error means re-authorization may be needed.

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 contributes: scope, parameter matching semantics, response confirmation, error meanings, caching, and safety. The description is dense but not bloated, and it front-loads the core purpose before adding edge-case behavior.

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, the description does not need to enumerate return fields. It covers the one parameter's semantics, error cases, caching, and the read-only safety profile, making it fully actionable for an agent.

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 already documents vehicle_id as a VIN or partial name, so the description's baseline is 3. It adds value by noting case-insensitive matching and that the response's own vin/name fields confirm which vehicle matched, which is important when using a partial name.

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 verb ('Get') and resource ('vehicle info') and enumerates exactly what is returned: identity fields plus an energy snapshot. It clearly distinguishes itself from get_vehicles and get_charging_status by describing its combined identity-plus-energy scope.

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 clearly communicates how to use vehicle_id (VIN or partial case-insensitive name) and how to interpret the response as confirmation. It does not explicitly state when to prefer this over get_vehicles or get_charging_status, but the framing 'quick energy snapshot' implies it is not a full charging-status replacement.

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