MCP servers for product data, before anyone asked

I spotted that models could answer questions about product data and support bundles directly, built MCP server prototypes for both, and demoed them to the team ahead of any roadmap item. Then put agents to work writing and running tests on AWS Bedrock.

client
Anchore
role
Principal DevOps Engineer
when
2024 to present
drawn by
Jesse Tamburino
identified independently · demoed before any roadmap itemengineerLLM clientasks in plain EnglishMCPEnterprise MCPproduct data, queriedby the model01Support-bundle MCPsupport artifacts,queried by the model02Anchore Enterpriseproduct dataSupport bundlesdiagnostic artifactsAWS BEDROCK · AI TEST-AGENT PIPELINE03agent writes testspipeline executestest results
Plain English in, product data and support artifacts out.Hover a step below to find it on the sheet. Scroll sideways on small screens.
2MCP servers prototyped
0roadmap items waited on
AIagents write + run tests

the problem

Product data and support bundles are where a lot of engineering and support time goes, and both are read by humans one file at a time. Large language models are good at exactly that kind of reading, if they have a clean way in.

Constraints

  • Nobody had asked for it. A prototype had to make the case on its own.
  • The surface a model gets has to be useful and narrow at the same time.
  • Generated tests are only worth something if a pipeline actually runs them.

Stack

Model Context ProtocolAWS BedrockLLM agentsAnchore Enterprise

how it is built

  1. 01

    Enterprise MCP server

    A Model Context Protocol server for Anchore Enterprise, so an LLM client can query product data in plain English.

  2. 02

    Support-bundle MCP server

    The same idea pointed at support artifacts, the bundles engineers otherwise read by hand.

  3. 03

    Bedrock test agents

    AI test-agent pipelines on AWS Bedrock that write tests and execute them.

calls I made

Why it looks like this.

01

Prototype beats proposal

Identified the opportunity independently and showed it working. A live demo answers "is this useful?" faster than a design doc.

02

Point models at what humans already read

Product data and support bundles were chosen because people were already spending time reading them.

03

Agents inside a pipeline

Test-writing agents run in a pipeline that executes their output, so the result is a pass or a fail, not a suggestion.

Want the longer version, with the parts that went wrong?

Ask me about it