This article is part of OpenBOM BOM Excel MCP building in public. For the next few weeks, we are going to share our story of building a BOM Excel AI Agent.
At OpenBOM, we’ve always taken an incremental approach to building software. Monthly releases, continuous feedback loops with customers, and expanding functionality step by step. Over time, this process has taken us from initial multi-tenant architecture with graph based models, CAD integrations, real-time collaboration, procurement workflows, xBOM services, and the foundation of a digital thread.
Now we’re starting a new initiative: building BOM Excel MCP (Model Context Protocol) in public.
This isn’t a polished feature announcement. It’s an experiment, and what we’re showing today is the first working version—the “super MVP.”
Why Start With Excel?
Anyone who has worked in engineering or manufacturing knows that Excel is still the default system of record for many teams. BOMs live in dozens of messy spreadsheets across desktops and shared drives. They have inconsistent headers, ad hoc naming conventions, and conflicting part numbers. They’re ubiquitous, but unreliable.
Our objective with BOM Excel MCP is to make those spreadsheets usable in a structured environment, then expose them through MCP so they can be queried and acted on by intelligent agents. In other words, connect the old world (spreadsheets) with the new (structured product data + agentic AI).
The super MVP is our first test: can we take unstructured BOM spreadsheets, bring them into OpenBOM, and make them accessible through MCP with simple queries?
Step 1: MCP Server With the First Tools
The foundation is a working MCP server. At this stage it’s intentionally minimal: a small set of tools, just enough to demonstrate the pipeline.
You can think of it as a translation layer. Excel data is messy and inconsistent. MCP provides a way to normalize it into structured, machine-readable product data that agents can work with. It’s not “production ready” in the enterprise sense—it’s closer to a prototype toolkit—but that’s the point of building in public.
By keeping it small, we’re able to validate the key interactions without being distracted by the complexity of edge cases.
Step 2: Registering an OpenBOM Account
The next requirement is simply having an OpenBOM account.
We wanted the setup to be accessible- just sign up and get inside a multi-tenant environment where product data can be stored and queried.
From an engineering perspective, this matters because it gives to customers a real-time OpenBOM account with actual muti-tenant infrastructure. But this is a separate development stack which is not exposed to the customer multi-tenant environment.
In the future, once BOM Excel MCP will be available in production, the functionality will be deployed to production infrastructure.
Step 3: Importing a Few Excel Spreadsheets
The core of the MVP is ingestion of data.
We used typical Excel files – spreadsheets with columns, quantities, custom headers, misaligned part numbers, and all the typical problems that show up in day-to-day engineering files. (Note: contact us and share your files for testing – we would love to do it together with you).
OpenBOM already provides robust Excel import capabilities. In the context of MCP, we extended this into a unified BOM import:
- Rows are converted into items.
- Columns are mapped into properties.
- Hierarchies and assemblies are recognized and built into structured relationships.
What comes out is a normalized product structure (BOM) representation, backed by OpenBOM’s graph-based data model. The difference from raw Excel is that the information is now queryable, linkable, and available for higher-level operations.
Step 4: First Exploration — “Where Is a Part Used?”
Once the data is loaded, the natural first query is simple: where is this part used?
In Excel, this is painful. You’d need to filter across multiple sheets, scroll through hundreds of rows, or write macros. The result is fragile and error-prone. With OpenBOM, the query is direct. The system returns all the assemblies where the part appears. With MCP, it will be even easier – chat based.
It’s a small example, but it demonstrates the value of the pipeline: once the data is structured, even a basic query highlights the efficiency gain. What used to take manual effort is reduced to a single machine-driven operation.
For us, this was the point where the experiment became tangible. The Excel chaos had been translated into something that both humans and agents could reason about.
Step 5: OpenBOM Appearance vs. Agentic Appearance
One interesting demo of the MVP is comparing how the same data looks in two different contexts.
OpenBOM view: a structured, table-driven interface. Items, BOMs, and relationships are displayed in a way engineers are already familiar with.
MCP view: the same data, but surfaced through an agentic interface. Instead of navigating menus, you issue queries such as:
- “Show me where Part 100-123 is used.”
- “List assemblies missing vendor assignments.”
The distinction is clear. The OpenBOM view is optimized for user experience and visualization. The BOM MCP view is optimized for interaction and automation. Both are valid. Together, they demonstrate how traditional product data management can coexist with AI-driven exploration.
Why This Matters
From the outside, the super MVP may look trivial:
- A lightweight MCP server.
- A basic OpenBOM account.
- A handful of messy Excel spreadsheets.
- A single query answered correctly.
But for technical teams, the implications are significant.
- Proven pipeline: unstructured Excel data can be reliably imported, normalized, and queried.
- Graph foundation: once in OpenBOM, the data inherits the advantages of a graph-based model—relationships, traceability, and multi-perspective views.
- Agentic extension: MCP provides a bridge to AI-driven workflows, enabling interactions beyond what the UI alone supports.
The key is not the scale of the MVP, but the fact that the end-to-end flow works. Data comes in, gets structured, and can be queried by both humans and agents.
What’s Next?
In the next blog update, we are going to give you some video demos and share more technical information about how we build an MCP server and connect it to OpenBOM multi-tenant architecture.
What is important is to understand how simple it is to create an OpenBOM account, pull a large number of Excel files and make analysis [ I will talk more about it in the future ]
This is an opening move, not a finished product. The roadmap from here includes:
- Expanding the range of supported queries.
- Adding more agentic actions (beyond “where used”).
- Integrating MCP with product memory for persistent knowledge across sessions.
- Handling larger and more complex Excel datasets.
The engineering effort is ongoing. By building in public, we can validate assumptions faster and gather real feedback from people who deal with these problems every day.
If you have a messy Excel BOM lying around, we’d like to see it. Run it through MCP with us and test how the system handles it.
Conclusion
The super MVP isn’t flashy. It’s intentionally small, technical, and practical. But it proves a point: Excel chaos can be converted into structured product knowledge, and MCP can make that knowledge actionable in new ways.
For engineers, this should feel familiar. Most good systems start this way – strip down the problem, build the smallest possible end-to-end version, and iterate. That’s exactly what we’re doing here.
This is only the first step. But it’s a step that demonstrates the direction: from disconnected spreadsheets to structured graphs, from manual filtering to intelligent queries, from static data to agentic workflows.
We’ll keep sharing progress as we go.
Want to learn more about how OpenBOM can help you today? REGISTER FOR FREE and check this out.
Want to join our BOM Excel MCP experiment? Contact our support – we would be happy to talk.
Best, Oleg
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
