MCP and datasheets: giving an AI assistant your embedded project context
The problem is not that the model does not know your hardware. It is that it does not know it does not know, and produces a confident answer from what it saw elsewhere. The whole context question comes down to replacing that approximate memory with reading, controlled and traceable.
What MCP changes
The Model Context Protocol is an open protocol standardising how an assistant reaches external resources. Three primitives are enough to see why it matters in embedded work.
Resources are data the model can read: an indexed reference manual, the project source tree, an SVD register definition file.
Tools are actions it can trigger: build, run static analysis, query a tracer, read a register on target through a probe.
Prompts are reusable templates: "review this driver against our in-house rules".
The practical effect is direct. An assistant that can read your microcontroller's SVD can no longer invent a register: it no longer needs to guess. An assistant that can compile sees its own errors and fixes them before answering you.
Making a datasheet usable
A microcontroller reference manual commonly runs to 2,000 or 3,500 pages. Feeding it whole into the context is impossible and, where the window technically allows it, counterproductive: accuracy degrades when the context is saturated with irrelevant pages.
The approaches that work, in order of effectiveness.
The SVD file or the component header. This is the structured, exact description of registers, bit fields and reset values. A few hundred kilobytes of unambiguous data, vastly more useful than the corresponding PDF.
Targeted section extraction. Supplying the chapter for the peripheral concerned rather than the manual. A per-peripheral index, built once, lets you serve the right section on demand.
Vector indexing of the manual. Useful for open questions, but watch it: register tables chunk badly, and an answer drawn from a truncated chunk is worse than no answer. Always check that kind of answer against the source.
The point to keep: structured data beats a document, every time. Look for the SVD, the board description file, the generated header, before reaching for the PDF.
Designing an agent that earns its place
An agent is an assistant given a loop: act, observe the result, correct. In embedded work that loop is only worth something if the observation is real.
A useful loop looks like this: write the code, compile, read the errors, fix, rerun static analysis, run the test bench on simulator or target, read the trace.
Two guardrails are essential. An iteration bound, otherwise an agent spins forever on an error it cannot solve, burning time and tokens. And a strict split between reading and writing: an agent may build, analyse and read registers, but should never flash a board or push to a shared branch without human validation.
The classic mistake is giving the agent tools that fail silently. A build tool returning exit code zero on error turns the loop into a generator of confident, wrong code.
Reusable configuration
Retyping project constraints in every conversation is the main waste of time observed. Stable constraints deserve to be written once, in a versioned file in the repository: coding rules, stack size, no dynamic allocation, naming conventions, peripherals in use.
Two properties follow. They apply to the whole team, so results are consistent. And they evolve through code review like everything else: when a rule changes, it changes for everyone and the history shows it.
Intellectual property, to settle before the first trial
This is what most often blocks enterprise adoption, and it is resolved through explicit decisions rather than a blanket ban.
Where the data goes. A hosted service receives everything you put in the context, including code under NDA and licensed manual excerpts. A model running on your own infrastructure avoids that, at the cost of lower quality on complex tasks.
What the contract says. Business offerings generally exclude training on your data, unlike consumer ones. That is a clause to verify, not to assume.
The status of generated code. Generated code is not necessarily protectable by copyright in every jurisdiction, which matters if your value lies in the firmware.
Licence contamination. A model can reproduce fragments close to GPL code seen during training. On proprietary firmware that justifies running software composition analysis on generated code, exactly as on third-party dependencies.
The practical rule: classify what may leave and what may not, before opening the tool. A repository-level configuration file can also forbid sending specific directories.
What it looks like in practice
| Without context | With structured context |
|---|---|
| Plausible but non-existent registers | Registers read from the SVD |
| Style inconsistent from file to file | Project conventions applied |
| Errors found at manual build time | Fixed inside the agent loop |
| Constraints retyped every session | Written once, versioned |
| Confidential code sent with no decision | Scope decided and enforced |
References
- Model Context Protocol specification, resources, tools and prompts
- CMSIS, System View Description, SVD
- Open-CMSIS-Pack, structured component and board description
- OWASP, Top 10 for LLM Applications, data leakage and context handling
Going further
Setting this up means choosing the tools, writing the context servers suited to your hardware, and defining the validation loop. That is precisely the content of our AI-Assisted Embedded Development course, covering IDE and CLI assistants, manual ingestion, MCP, agent design and validation of generated code.