Battery Figures: used Tesla battery health by VIN
Server Details
Used Tesla battery health (SoH) by VIN: pack, original kWh, typical capacity left. Model S, 3, X, Y.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 1 tool
There is only one tool, so there is no possible misselection between overlapping operations. Its purpose (free VIN-based battery preview) is clearly stated and unmistakable within this server.
The single name 'preview_vin' follows a readable verb_object snake_case style, consistent with common conventions. The object is an identifier field ('vin') rather than the resource noun ('battery'), a minor deviation that would matter more in a larger set.
A one-tool surface is very thin for a server whose stated domain includes retrieving battery health figures and monetizing them. Effectively the server exposes only a teaser, so the surface feels under-scoped rather than deliberately minimal.
Only a free preview is callable; the actual paid figure retrieval is punted to an external next.url, so an agent cannot complete the core job through MCP. No lookup-by-VIN detail, batch, or error/refresh path exists, which will cause dead ends for real workflows.
Available Tools
1 toolpreview_vinARead-onlyInspect
Free preview of a used Tesla’s battery by VIN. Never calls Tesla. Returns the pack, its original capacity, the normal capacity left at this age and next.url where the user buys Tesla’s own figure for this exact car.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | The 17-character VIN of the used Tesla. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, and the description usefully reinforces this by stating it never calls Tesla and is free, so no external side effects or cost. It also discloses the return contents, which matters because there is no output schema. It does not explain the non-idempotent hint or any rate limits/quota on the free preview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose and value proposition, with no filler. The final clause about next.url is slightly convoluted but still carries real information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description supplies the return shape and the key side-effect guarantee, which is what an agent needs. Gaps remain around error behavior for bad VINs and any limits on the free preview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 100% schema description coverage, so the schema already defines the 17-character VIN. The description adds no further meaning about VIN format, validation, or regional/model coverage, matching the baseline for fully documented params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: a free battery preview for a used Tesla identified by VIN, and it names the concrete outputs (pack, original capacity, remaining normal capacity, next.url). No siblings exist to differentiate from, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'Free preview' plus the pointer to next.url where the user buys Tesla's own figure suggests this is a teaser step before a paid lookup. There is no explicit statement of when to call it, when not to, or what to do for invalid/unsupported VINs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
preview_vin
Related MCP Connectors
Vehicle data for AI: VIN decoder, automotive specs, stolen checks, valuation and way more.
Washington State DMV MCP — the Department of Licensing's VIN-level electric-vehicle population…
VIN decoding and European vehicle data for automotive workflows.
Mechanic-grade used-car listing verdicts: risk score, failure points, repair costs, fair price.
Related MCP Servers
- AlicenseBqualityBmaintenanceMaterial, cell, pack, and supply-chain management with real-time6MIT
- AlicenseNot gradedqualityDmaintenanceProvides intelligent Tesla vehicle analytics and control through the Tessie API, including real-time status monitoring, charging cost optimization, efficiency trend analysis, trip planning, and predictive insights for Tesla owners.MIT
- FlicenseNot gradedqualityBmaintenanceAn AI-powered EV Digital Twin platform for battery health monitoring, predictive maintenance, fleet analytics, and intelligent decision support using MCP tools for SOH prediction and RUL estimation.4-
- AlicenseAqualityAmaintenanceDecode VINs, look up specs, history, recalls, market value, and OBD codes. Recognize license plates and VINs from images. Access comprehensive vehicle data by year, make, and model to power automotive workflows.121MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.