These are the eight tools an AI assistant is allowed to call against OptiCat’s catalog — and the only ones. Every tool returns the same response format, which carries the answer together with its proof: what was asked, what the catalog returned, and how complete that evidence is.
The input schemas and the shared response format on this page are generated from the Python MCP server itself—not hand-copied. What you read here is what is registered.
Every diagram below is built from the same four elements. Here is what each one means, in plain language.
One of the eight actions an AI assistant is allowed to take against OptiCat’s catalog — and the only actions it can take. Each tool is shaped around a customer job, like “does this part fit my car?”, not around a raw API endpoint.
verify_part_fitmentA call to OptiCat’s AutoCare web service. 7 of the 9 documented operations are wired in; a single tool often makes several operation calls to answer one question.
getAutoCarePartApplicationsThe single response format every tool returns: the answer plus its proof — an outcome status, a completeness report, and a record of every upstream call made. The assistant can explain what is inside this response; it cannot add claims of its own. That is why we call it the evidence boundary.
17 fields · evidence per callOur current grade for each tool based on what has actually been demonstrated against the live catalog: live verified, live with a known boundary, or needs a live retest.
evaluated 2026-08-24The first OptiCat MCP server—sixteen tools returning free text—failed in specific, documented ways. This version is the post-mortem made executable: each rule on the right exists because the failure on its left actually happened.
The first server’s sixteen tools each returned a block of prose. Neither the assistant nor the host application could tell catalog data from narration, so nothing downstream could check an answer.
All eight tools return one structured format with a named outcome, the matching records, and an evidence entry for every upstream call. Answers are data that can be verified, not stories that must be trusted.
Hard caps trimmed result lists to the first ten or twenty rows with no signal that anything was missing. “Here are the parts” could quietly mean “here are some of the parts.”
Total found, number returned, whether the list was truncated, and how to fetch more ride on every response. A cut-off result is labeled partial — it can never impersonate a complete one.
The old fitment check answered “does NOT fit” whenever it found zero rows — even when the real cause was a truncated search or an access error. A missing answer became a confident wrong answer.
Fitment now returns four distinct states — yes, no, conditional, unverified — and “no” is only permitted when the full application set was retrieved and checked. Uncertainty is reported as uncertainty.
Ambiguous vehicles and part types were resolved by picking whichever candidate came back first, so a question about one car could be answered about another.
When more than one vehicle, part type, or product matches, the response is a clarification question carrying the real catalog choices. The system never guesses identity on the customer’s behalf.
Tools were shaped like the vendor API, not like customer questions, and multi-step jobs — supersession chains, part images — simply broke between them.
Each tool owns a complete job — find parts for a vehicle, verify a fitment, trace a replacement chain — and runs its own multi-step resolution pipeline internally, within a budgeted number of upstream calls (twenty by default).
Fitment qualifiers (“front axle only”), attribute units, and product lifecycle status were dropped on the way through — the exact details a parts professional needs to trust an answer.
ACES qualifiers, attribute values with units, lifecycle status, and asset links travel through the response as structured fields, so nothing that could change the answer is flattened away.
Every question travels the same seven stages. The assistant never talks to the catalog directly—it calls one of the eight tools, and the tool does the resolving, calling, and checking before anything comes back.
Search by what a customer is trying to do, filter by family or confidence, and hover a tool to light up the OptiCat operations it calls. Every path ends at the same CatalogResponse.
This tool has returned correct, evidence-backed answers from the production OptiCat catalog.
The tool works against the live catalog, but one documented limit remains — for example, the account returns only part of a large result set.
The behavior is implemented and covered by tests, and a fix has landed since the last live run. It keeps this status until an agreed live example passes end-to-end.
get_catalog_statusCatalog statusProve that OptiCat is reachable, classify access correctly, expose reference-data versions, and describe the configured key’s non-secret brand and VIN scope.
search_parts_for_vehicleVehicle searchResolve readable vehicle and part-type language to catalog identities, apply optional brand and attribute constraints, and return paged candidates without hiding fitment qualifiers.
get_part_fitmentsPart applicationsResolve one exact catalog product and fan out its paged ACES application rows with vehicle identity, quantity, notes, and qualifiers intact.
verify_part_fitmentVerify fitmentResolve the part and vehicle independently, retrieve filtered ACES applications, and return yes, no, conditional, or unverified without guessing through qualifier gaps.
lookup_part_interchangesInterchangesReturn only explicit PIES interchange relationships and validate a bounded candidate set through identity, category, product evidence, and vehicle-verification boundaries.
lookup_part_supersessionSupersessionResolve a starting product and traverse only replaces/replaced-by evidence through a bounded, cycle-safe chain while keeping interchange fallbacks distinctly labeled.
decode_vin_and_searchVIN searchValidate and decode a VIN, preserve every returned configuration detail, require selection when several vehicles resolve, and optionally bridge into the same bounded part taxonomy/search path.
get_part_detailsPart detailsResolve one exact product and expose the selected PIES record: identity, descriptions, unit-bearing attributes, lifecycle, origin, extended information, typed relationships, and classified assets.
getAutoCareVersion1 toolgetAutoCareBrandsLastUpdatedDates1 toolgetAutoCareVehiclesByVIN2 toolsgetAutoCareVehicleResults2 toolsgetAutoCareSearchResults7 toolsgetAutoCarePartApplications2 toolsgetAutoCarePartDetails4 toolsCatalogResponse17 top-level fieldsOutcome, completeness, domain records, clarification, warnings, errors, and an evidence record for every upstream call.
Open the schemaEvery tool answers in this format. Alongside the results it reports how complete they are, what clarification is still needed, and every upstream call that produced them. Expand any field to inspect its registered type.
statusResultStatusrequiredsummarystringrequiredreason_codeReasonCode | nullqueryobjectmetadataobjectcompletenessCompletenessstring | nulloptionalnullintegeroptional0none | page | cursor | capped | unknownoptional"none"5 allowed valuesintegeroptional0integer | nulloptionalnullbooleanoptionalfalsevehiclesVehicleIdentity[]partsPartRecord[]relationshipsRelationshipRecord[]relationship_outcomeRelationshipOutcome | nullfitmentFitmentDecision | nullinterchange_validationsInterchangeValidation[]clarificationClarification | nullpending_clarificationsClarification[]Every open clarification dimension in one round (clarification stays = the first). Ask them together instead of one round trip per dimension.
warningsstring[]errorCatalogError | nullevidenceEvidenceRecord[]Confidence is graded per tool against the live catalog, dated 2026-08-24. Nothing here is aspirational: the groups below are today's state, and the work that moves tools up is named.
This tool has returned correct, evidence-backed answers from the production OptiCat catalog.
You can rely on it today. The live example on its detail page is a real production result, not a fixture.The tool works against the live catalog, but one documented limit remains — for example, the account returns only part of a large result set.
You can rely on what it returns. When a boundary is hit, the response says so explicitly instead of pretending the answer is complete.The behavior is implemented and covered by tests, and a fix has landed since the last live run. It keeps this status until an agreed live example passes end-to-end.
Treat its answers as provisional for now. Each tool's detail page names the exact retest that will promote it.Every tool’s detail page lists its own known gaps, and each one is tracked in the optimization backlog. The highest-priority live retests on the promotion path:
Each tool page pairs its gaps with product concepts—ideas like a readiness history, an application heatmap, or a media and document viewer. Every concept is labeled “Product concept · not implemented” until it ships, so ideas never masquerade as features.
Deferred is a decision, not an omission: these operations stay out of the customer answer path until their entitlement and data-governance rules are approved—and each has a written reason.
getAutoCareVehicleAssetsReturns vehicle/application imagery; part imagery correctly comes from product details.
Add only when a customer journey needs vehicle diagrams or application assets.getSearchResultsCombines OptiCat and TecDoc data under separate entitlement and provenance rules.
Keep deferred until TecDoc scope, ranking, and data governance are approved.