Show HN: Assemble Labs – Hardware Brain for LLMs/IDEs

19 points

8 months ago

Hi HN friends, we're Nima (nimabanai) and Craig (cbschind) from Assemble Labs (https://assemblelabs.co) building the hardware context layer for AI to help you write better firmware faster. We’ve built an MCP server that plugs into any AI tool you’re using (Cursor, Claude Code, Gemini, etc.) and brings complete hardware context (schematics, datasheets, etc.) to your existing environment (new app fatigue is real...) with accuracy and in real time. Our goal is to make writing and debugging firmware on custom hardware faster and easier.

Try out the free beta release: https://app.assemblelabs.co and email me ([email protected]) or Craig ([email protected]) for any bugs, issues, suggestions, or anything else. Feedback is the most important thing for us right now and we’re only announcing this on HN. So only the free beta tier is available at the moment with no MCP call cap, please ignore the cap text on the website.

We've spent our careers building hardware and consistently faced the same limitations with any AI tool we tried:

  - Generic answers: they lack knowledge of our specific board designs and hallucinate when there’s a knowledge gap.
  - Limited context: Windows max out after just a few datasheets, app notes, or SDK docs.
  - Poor technical comprehension: OCR fails on tables/diagrams, causing inconsistent answers which is unacceptable for complex board bring-up.

We need a persistent hardware knowledge base that any agent, editor, or CLI can query for fast, accurate, repeatable answers.

Our MCP ingests your schematics (must be KiCad for now, we’re working on native Altium and Cadence), datasheets for primary BOM components, and any additional documents (app notes, user manuals, etc.), then provides an MCP key you can plug into any AI tool.

To be upfront about our free beta limitations:

  - KiCad only for native schematic parsing. Other EDA tool support coming soon. No firmware repo integration yet.
  - FastMCP backend (https://github.com/jlowin/fastmcp) with manual upload to AWS S3. On-prem/air-gapped/local/your-cloud options coming. Zero training on uploaded docs, even in beta.
  - No SOC 2/ISO27001 yet. In progress.

We're building in public and want the community’s feedback on features, roadmap, and concerns so we can iterate quickly. Our long-term goal is to enable electrical engineers to write low-level firmware, and for software engineers to debug hardware issues. We want to be useful at the hardware-software interface: generating firmware→deploying it on board→running tests→debugging results→regenerating firmware.

What do you guys think? Feedback, suggestions, concerns, harsh criticisms, feature requests, everything is welcome! For the firmware application of our tool:

  - What chipsets do you want to see supported? What peripherals are giving you headaches in bring-up? 
  - What other functions should the MCP expose in addition to the ones we’ve built in?
  - Do you see other applications of our “hardware brain” outside of firmware development that seem interesting?

We're shipping early and building this with you out in the open. Help us make the tool you actually want.

- Generic answers: they lack knowledge of our specific board designs and hallucinate when there’s a knowledge gap. - Limited context: Windows max out after just a few datasheets, app notes, or SDK docs. - Poor technical comprehension: OCR fails on tables/diagrams, causing inconsistent answers which is unacceptable for complex board bring-up.

- KiCad only for native schematic parsing. Other EDA tool support coming soon. No firmware repo integration yet. - FastMCP backend (https://github.com/jlowin/fastmcp) with manual upload to AWS S3. On-prem/air-gapped/local/your-cloud options coming. Zero training on uploaded docs, even in beta. - No SOC 2/ISO27001 yet. In progress.

- What chipsets do you want to see supported? What peripherals are giving you headaches in bring-up? - What other functions should the MCP expose in addition to the ones we’ve built in? - Do you see other applications of our “hardware brain” outside of firmware development that seem interesting?