list_content

Vehicle data · Read-only

List content summaries — maintenance, labor times, TSBs, specifications — for a resolved vehicle.

Usage

Eleven content families are available (see the contentType enum). Paging is handled server-side; prefer searchTerm to narrow large sets before they reach your context window. The search matches generously — "A/C" can also surface ABS records — so discard obvious mismatches rather than treating them as data quality issues.

If the result carries needsConfiguration, the alternatives hinge on one unknown vehicle attribute. Ask the user that one question and re-call with configuration set; do not present both alternatives and do not pick one.

Parameters

Parameter	Type	Required	Description
`baseVehicleId`	positive integer	Yes	The baseVehicleId field from a resolve_vehicle result. NOT the vehicleId (rejected with 400.110052). Example: 22124
`contentType`	"EstimatedWorkTimes" \| "Specifications" \| "TechnicalServiceBulletins" \| "DiagnosticTroubleCodes" \| "ServiceProcedures" \| "WiringDiagrams" \| "Fluids" \| "Parts" \| "MaintenanceSchedules" \| "ComponentLocations" \| "PartVectorIllustrations"	Yes	Which MOTOR content family to query. Example: "TechnicalServiceBulletins"
`searchTerm`	string	No	Server-side semantic search — recommended for large sets. Matches generously ("A/C" can also match ABS records; discard obvious mismatches). Example: "A/C"
`keyword`	string	No	Client-side substring filter applied after fetch. Example: "refrigerant"
`configuration`	object	No	Known vehicle configuration. Rows whose qualifiers contradict it are filtered out; unknown attributes that materially change the answer come back as one targeted question under needsConfiguration. Engine and trim auto-populate in service_advisor_lookup. Example: {"transmission": "automatic"}
`configuration.transmission`	"automatic" \| "manual"	No	Transmission type, once the user has confirmed it. Example: "automatic"
`configuration.drivetrain`	"fwd" \| "rwd" \| "awd" \| "4wd"	No	Drivetrain, once known. Example: "fwd"
`configuration.bodyStyle`	"sedan" \| "coupe" \| "hatchback" \| "wagon"	No	Body style, once known. Example: "sedan"
`configuration.engine`	string	No	Engine displacement or designation. Auto-populated from resolution in service_advisor_lookup — only pass it to list_content. Example: "1.8L"
`configuration.trim`	string	No	Trim/submodel, case-insensitive. Omit to see all candidates when unsure. Example: "LX"
`configuration.rearBrakes`	"disc" \| "drum"	No	Rear brake type, once the advisor has confirmed it — VIN resolution cannot determine it, and brake work-time variants (e.g. rear pads vs shoes) hinge on it. Example: "disc"
`configuration.options`	array of string	No	Option packages present on the vehicle (presence-only assertions). Example: ["Sunroof"]

Description advertised to clients

The exact description a fully entitled MCP client discovers — the workflow contracts travel with the tool, so a client with no system prompt still uses it correctly. An account missing a licence for content this tool reaches sees the same text behind a [Licensed content — not enabled on this account] or [Partially available] notice:

List content summaries (maintenance schedules, labor times, technical service bulletins, specifications, ...) for a resolved vehicle. The baseVehicleId parameter MUST be the baseVehicleId field from a resolve_vehicle result. It is NOT the vehicleId — passing a vehicleId is rejected by MOTOR with error 400.110052. Paging is handled internally; prefer searchTerm to narrow large result sets server-side. Returns {items, needsConfiguration?}. Pass configuration (transmission, engine, trim, ...) once known — rows contradicting it are filtered out. A needsConfiguration entry means alternatives hinge on ONE unknown attribute: ask the user that one question and re-call with the answer set — do NOT present both alternatives and do NOT pick one. The evaluation sandbox covers model years 2010, 2015, and 2016 ONLY. Empty results for other vehicles are correct behaviour, not an error — tell the user the vehicle is not covered rather than retrying.

Example — Search technical service bulletins

Captured from the live server, 2026-08-20. Item list truncated to the first three of seven.

Request

{
  "baseVehicleId": 22124,
  "contentType": "TechnicalServiceBulletins",
  "searchTerm": "A/C"
}

Response

{
  "items": [
    {
      "applicationId": 474099311,
      "applicationIds": [
        474099311,
        474099314,
        474099326
      ],
      "name": "A/C Leak Detection"
    },
    {
      "applicationId": 475287901,
      "applicationIds": [
        475287901,
        475287902,
        475287903
      ],
      "name": "Air Conditioning Refrigerant and PAG/POE Oil for Warranty Repair Claims"
    },
    {
      "applicationId": 468452808,
      "applicationIds": [
        468452808,
        468452813,
        468684318
      ],
      "name": "Air Conditioning System Performance Test"
    }
  ]
}

applicationId feeds get_content_detail. The same search also returned an ATF cooler bulletin — generous matching in practice.