Opticat item search MCP reviewPhase 1 discovery, validation, and path forward
View Demo
Review findings

The places a customer could be told something the catalog did not support

Choose a finding to review the customer impact, root cause, and required replacement workflow.

8 of 9 findings are addressed or designed; the one still open is the measured baselineReview findings by disposition
3 live proven4 repair designed1 keep1 still open
Phase 1 assessment record
The root cause

A working catalog connection was treated as a finished product.

Completeness

Customers were told less than the catalog knew.

Judgment

Purchase-critical decisions were left to the model.

Failure honesty

Service problems were spoken as catalog facts.

The open proof gap

It can work; how often is not yet measured.

F-01 · Keep · Medium customer risk

The connection is real. The product was not finished.

OptiCat built a working catalog connection. That is not the same thing as a trustworthy customer answer. The recommendation is to finish the product, not throw the concept away.

What this taught us

“Don’t make things up” is not a product control. Prompt language does not travel with the service, and it cannot restore fields a formatter already dropped. If two deployments expose different functions, you do not have one product.

How the failure happens
  1. 1
    Customer asks a catalog question

    Find parts, check fitment, or look up an equivalent.

  2. 2
    Host picks a function, if it has it

    Different deployments exposed different capabilities.

  3. 3
    Formatter shortens the catalog

    Structured evidence becomes a short paragraph.

  4. 4
    Model fills the gaps

    A confident answer is produced from incomplete evidence.

What has to happen instead
  1. 1
    Customer asks a catalog question

    The same five journeys, one service.

  2. 2
    Resolver locks identity

    One exact vehicle or part, or a short list of real choices.

  3. 3
    Service keeps the evidence

    Totals, qualifiers, errors, and unknowns stay attached.

  4. 4
    Model explains only what came back

    It cannot invent a part, a fit, or an empty catalog.

1 · What was built

A real Python service reached OptiCat directly and covered the intended catalog domains: vehicles, parts, fitment, VIN, interchange, replacement, and product detail.

2 · What the review found

The same capability was packaged through several deployment paths, and those paths did not expose the same functions. Most results were then shortened into prose before the model ever saw them. Safety rules lived in a prompt document, not in the service every host would use.

3 · Why it happened

The proof of concept was built to show that the catalog could be reached quickly. Reach was treated as the product. Identity, completeness, errors, and evidence were left for the model to infer.

4 · What the target now shows

The target consolidates the experience into one private service with one evidence contract. The catalog foundation is retained; the answer boundary is no longer left to the model.

Why it matters to a customer

A convincing demo was possible. A repeatable answer was not. Different hosts could see different capabilities, and the model was forced to fill gaps the service had already thrown away.

Recommendation

Keep the catalog connection. Standardize one service, one evidence contract, and one deployment path before adding more surface area.

Evidence level · Repository + deployed target
Repository and commit historyOriginal tool and deployment inventoryOfficial MCP SDK serverLive private service discovery
Continue the storyHow the answers get tested
View Demo