OBDII-MCP on Github

Recently, I replaced my car’s battery on a hunch. It felt like the car was struggling to turn over on cold starts, but there was no clear sign because there were no fault codes. I consulted AI and it came to the same conclusion. But this made me think: why am I in the diagnostic loop here, providing indirect, second-hand evidence to the AI? Why can’t the model just talk directly to the car, read the actual voltage data and perform any required tests?

Unfortunately, I didn’t have the tech for that. So I decided to build it.

I decided to build an MCP server that would bridge the gap between the model and the hardware. I started with a cheap Bluetooth OBDII dongle (OBDII is the automotive standard which defines diagnostic services and modes), which provided the bottom of the stack. This would allow serial Bluetooth communication between my laptop and the vehicle, and would implement the low-level CAN framing and request/response for me out of the box. This in turn meant that I wouldn’t need to implement a driver; the ELM327 Bluetooth dongle is the driver, providing the interface with a known and documented command set. I did, however, notice at this stage that these chips have a somewhat limited bandwidth - which would limit how many parameters (and at what frequency) I would be able to stream at the same time, and would shape the architecture.

On top of the ELM327 transport layer, I built out a PID (parameter IDs, such as motor RPM, or battery voltage) querying layer, used by OBDII. I then built a service layer on top of this that would expose tools to the MCP server. “python-OBD” would have handled most of the bottom half, but I’d already written my own by the time I properly looked at it, and since mine worked and I understood it end to end, I kept it. (It’s also GPL, and I wanted this MIT-licensed).

So the architecture stack looked like this:

While building the MCP tools I came to the realisation that there would be no need to implement diagnostic taste or logic here. I watched the model chain PID reads and reason about them without any hardcoded logic from me. Instead of building something like “check_charging_system()”, I designed purposefully thin primitives such as read a PID, list supported PIDs, read DTCs, open a stream. I had answered my own question: the intelligence no longer belongs in the application, but belongs in the model. I just needed a safe toolset for the model, which I provided by building exclusively read-only commands into the PID layer.

In order to make the MCP server testable (without relying on having the hardware in the loop), I built a light Streamlit application which enabled streaming selected PIDs, and built a way to record the stream to a JSON file, then to replay from the stream. I used the streaming feature to visualise the battery voltage, and then applied an electrical load (winding down all four windows at once). I proved the end-to-end integration by seeing the battery voltage dip in the graph at the same time:

I also recorded a session driving around the block, to prove the ability to record and replay the diagnostic session - an invaluable feature for diagnosing actual dynamic driving data.

At this point the project had crossed an important threshold: the AI was no longer just helping me reason about the car from photos and descriptions. It had a structured, read-only, interface into the vehicle itself.

So now I had something that worked well for my specific car, and for the default list of PIDs that I had pulled from online. But to make this project useful for other car models and manufacturers, I thought it would be useful to implement a discovery functionality. Effectively I wanted the LLM to ask the car “which PIDs do you support?”. This would pair nicely with the general MCP design philosophy - allowing auto-discovery rather than hardcoding capability. OBDII already supports this with so called “Mode 01 PID discovery”. So I built support for this for both the MCP client and the Streamlit dashboard, enabling users to connect to the car, ask what PIDs are supported, and then select what they wanted to see from the dynamic list generated in the dashboard (or indeed the LLM could do this itself over MCP).

Clearly there are limitations to this approach - I won’t claim that this tool is the answer to all car troubleshooting: far from it. While working on this project I also had to replace the car’s rear windscreen wiper motor, and when doing so I needed to take physical voltage readings at different points in the wiring loom and feed these into the model. The car doesn’t expose this over OBD. Equally, performing a simple voltage under load test (especially without knowing the load current) doesn’t give you a complete battery health test. But had I had this tool I could certainly have made a much more informed decision, especially by doing a few variations of load tests (combined with AI’s ability to pull datasheets and infer specific load currents).

Reflecting on this build made it clear to me that the reasoning boundary has shifted, and will continue to do so. As AI models get more capable, what real value is there in hardcoding “diagnostic intelligence” into the application? The new approach should be to provide the model with the right tools and harnessing, and then to get out of its way.

I thought back to how early waves of frontier model releases killed early AI companies, which relied on products that were fundamentally little more than an AI wrapper. How should today’s applications be built to prevent them becoming obsolete in six months? One approach appears to be to build with the rate of change in mind, and to fully expect that most of the reasoning should be done in the LLM layer. Thus, if reasoning is no longer the competitive moat, then perhaps it is data, domain expertise, harnessing and tooling.

OBDII-MCP on Github

The corner problem. “What if we moved the gusset by 5mm towards the vertical member?” By this point I was struggling to keep up with visualising the complex 3D geometry in my head, and it took me a good 30 seconds to remember what a gusset was again… and suddenly the conversation had moved on and someone else was offering technical observations about why that particular solution wouldn’t work, receiving nods of understanding from the room. The issue was that I was only a few months into real engineering, and despite being the work package manager for the battery pack we were discussing, I wasn’t fluent enough in the technical concepts to contribute much of substance. I kept my mouth shut.

Over the past five years of my career, I’ve often been in rooms where I’ve been outmatched. It’s become clear to me that fluency - the ability to use the jargon - and deep understanding are not the same thing. Every time I thought I had a rock-solid mental model and could speak the jargon, some new concept would present itself that everyone else was seemingly already familiar with, and which meant little to me. This, as I have come to appreciate, is what it costs to have responsibility beyond your experience, alongside genuine experts. It’s how I’ve spent the last five years at Sunswap - the cleantech start-up I joined as one of the first employees - and it’s how I’ve developed the ability to learn and compress fast.

Being outmatched isn’t an overstatement. I’ve worked alongside engineers with decades more experience than me, and it’s a specific, daily, uncomfortable cognitive experience. A feeling of not being able to keep up, processing slower than everyone else, and often slight embarrassment at stalling the progress of discussion. And yet, as I’ve progressed in my career, I’ve come to a crucial realisation: this is exactly the room I want to be in - the one in which I’m outmatched.

That doesn’t necessarily mean being outmatched on every front. I’m a jack of all trades, master of some - but in the domain at hand, I’m outmatched. My thesis is simple: there is no greater motivational driver for learning than imposter syndrome. It’s a quality I see in all those I respect most: only those who are blind to their true ability have the complete confidence to never self-assess.

My solution: learn fast. Learning the language of the domain came first. In school, I would roll my eyes at having to rote learn terminology. There were more interesting things to be getting on with, but perhaps I wasn’t fully appreciating the power of compression (forgivable, in fairness, for a 14-year-old). Now that I work in AI there’s an obvious parallel: context window optimisation. Just like LLMs - which can only process a fixed number of tokens at once, with quality degrading as the context grows - people can only process so much information in one chunk. Being able to use precise and domain-specific language is effectively a context compression hack: the information conveyed is succinct and specific enough that the meaning carries through with very low cognitive load. Naming a concept allows you to refer back to it with ease, without convoluted explanations. I remember always being struck by one particular colleague who would focus hard on picking the right words, so much so that he actually spoke quite slowly. At the time I thought this was over the top, but I later came to realise that this is evidence of an incredibly valuable and rare skill: the art of concept compression in real time, and the ability to distil meaning into its purest form.

Another instrument is a mental model. Take the example of a “sacrificial element” - a purposefully weak link in a chain that allows you to control which section will fail first. We used this in the battery pack design with our fusing architecture. We knew the sacrificial fuse would fail first in an electrical fault, so we deliberately located it outside the main pack area, allowing the pack to stay serviceable without invasive repairs. By labelling the concept in two words, everyone conjures up the appropriate mental model, which means it occupies the minimal amount of “context tokens” possible and enables faster discussion. Or (to appropriately compress the idea): compression.

But labels only work if there’s something real underneath them. Mental models have to be discovered first, then labelled - not the other way round. They have to be earned, like achievements in a video game. A few years ago, having discovered Charlie Munger (who popularised the concept of mental models) and Farnam Street (an online community dedicated to the subject), I attempted to create a giant poster of the most common mental models, hung it on my staircase, and tried to memorise it - an effort that quickly proved unsuccessful. Mental models are like a one-way function: you can easily calculate the output from the input, but not vice versa. It’s the same reason why book summaries don’t work long term. Your brain is effective at compressing concepts, but only once the underlying understanding is there. Without the work, the label has nothing underneath to attach itself to. However, I’ve found mental models to compound and pop up across domains, which is what makes them so powerful.

Beyond language and models, there’s first-principles thinking. A truly deep understanding of the domain space. Things like: what really is voltage? Every engineer will claim to understand voltage. Few can explain what physically causes it: an imbalance of charge at the particle level. My cheat code for first-principles thinking has been YouTube. Channels like 3Blue1Brown, AlphaPhoenix and Ben Eater have been invaluable in refining my models over the years. The videos worth watching I watch three or four times. Now I share them with my team. First-principles thinking is compression at the foundation: knowing what a concept physically is, so everything above it can be rebuilt. After all, if you can’t explain it at a whiteboard, do you really understand it?

The good news I’ve found is that compression compounds. I first noticed this two years in. By year three, after a concerted effort to deepen my electrical knowledge, it took me by surprise how fast new domains were becoming accessible. Not only are concepts transferable across domains, but more deeply, the framework for operating in ambiguity and getting up to speed quickly becomes a powerful weapon. Over the past couple of years I’ve found the same with AI. Ultimately, everything is systems. The skill of moving fluidly between levels of model complexity transfers everywhere. Now I use AI the same way, as a tutor for whatever domain I’m currently outmatched in. The compression habit just found a new instrument.

So being outmatched is the formation I’d recommend, if you can tolerate the discomfort. Studying compression won’t make you a compressor. Being in a room where you are outmatched will. This is the signal I look for now - if I’m not outmatched, I’m not at the limit, and there’s no room to grow. Every new expert colleague who joins Sunswap is an opportunity to be outmatched, and to learn from the best. Compression compounds.