Designing with a Virtual Printer MCP
Letting leadership use a product that did not exist yet
- Role
- Design and build, end to end
- Built
- A working MCP server simulating a printer
- Audience
- Executive leadership
Everyone agreed agentic AI mattered. Nobody could agree what it would mean for a printer. The conversation had been running on slides for months, and slides cannot answer the only question that counts: what does it actually feel like when software, not a person, decides to print something.
The missing piece
Ask an agent today for a direct flight ticket for tomorrow morning, under a set budget, window seat, cabin bag only, purchased, boarding pass printed and a digital copy sent over. It handles almost all of it.
Find
“I found 3 direct flights. Best option is Scoot at 2:45pm for $180. Shall I book this?”
Pay
The agent reaches a saved wallet or card with the right permissions, takes payment through the airline or a payment provider, and gets back a confirmation and a ticket PDF.
“Sorry, I currently do not have any printing capabilities.”
Booking has an MCP server. Payment has one. The printer, sitting two metres away and perfectly capable, has none. It is the one step in the chain a person still has to do by hand.
A concept video would have shown an outcome without proving anything. A clickable mockup would have demonstrated a screen, which is precisely not where the change happens. The interesting behaviour of an agentic device is invisible: it runs without a person watching, triggered by something else entirely.
So instead of describing it, I built one.
Stop presenting the idea. Hand people something they can operate, and let the argument settle itself.
What I built
A test bench, not a demo. Real protocol, real behaviour, simulated hardware.
Model Context Protocol is the standard that lets an AI model reach outside its own context and operate real systems. I wrote an MCP server that presented itself as a printer: the same surface a real device would expose, backed by a simulation rather than hardware. Any MCP-capable assistant could connect to it and drive it, with no special integration and nothing staged.
That distinction mattered more than the code. A demo shows you what someone wants you to see. A test bench lets you try the thing that was not rehearsed, which is where every interesting question lives.
Print a document
An assistant sends a document and gets back a job ID, the printer it landed on, and an estimated time, without anyone touching a print dialog.
Read the device state
Ink levels per cartridge, paper tray, paper size and readiness, so an agent can decide before it commits rather than fail halfway through.
Reach a fleet, not a device
Several printers are exposed as separate endpoints. When one runs out of black ink, the agent proposes the others and reroutes the job.
Fail on purpose
Paper jam, overheating, ink smear, dry heads: each fault can be switched on at will, because how an agent behaves when things break is the whole design question.
Set how it speaks
Tone of voice and a verbatim mode are part of the surface, so the printer's own voice can be tuned and tested rather than left to the model.
Try it with any model
A testing panel runs the same request through different assistants, which is how you find out that the protocol holds and the behaviour does not.
What needed designing
How the printer speaks back, once nobody is looking at a screen.
Once the protocol works, the design question is not what the interface looks like. There is no interface. It is what the assistant says back, and how much it decides on its own. The bench let us write the same failure three ways and feel the difference immediately.
The printer is out of black ink. Here is the same fact, told three ways.
“Your black ink is depleted. Consider replacing cartridge and try again.”
“Your default printer is out of ink, I can print on the Smart Tank Printer. Shall I continue?”
“Checking status. Depleted tank detected. Consider replacing black cartridge and try again.” Followed by a way out: order more ink.
The first answer is honest and useless: it hands the problem back. The second decides something on the user's behalf and asks before committing. The third shows its work, which builds trust, and ends on an action rather than a dead end.
None of them is right in every case. That is the point. Which one a device owes you depends on how much autonomy it has been given, and that question is what the autonomy scale was written to answer.
What happened in the room
The difference between watching a concept and operating one.
I did not present the bench. I handed it over. Leadership typed their own requests and watched a printer respond to software rather than to a person, which is a very short experience and a very hard one to argue with.
The questions changed immediately, and that was the real outcome. The conversation stopped being about whether agentic printing was plausible, and became about what it should be allowed to do on its own: what it needs permission for, what it should report, what happens when it gets something wrong while nobody is watching.
Those are design questions, not engineering ones, and they only become askable once the thing exists.
A working artefact does not just illustrate an argument. It replaces it, and moves the discussion one level up.
What it led to
From a side build to a funded product direction.
The concept was approved. Product and engineering teams picked it up, and the direction moved into development.
The framework work came out of the same build. Designing the bench meant deciding how much a device should be trusted to do alone, which turned into the autonomy scale and the design process I now use across the studio.
Designed and built by me: the MCP server, the printer simulation, and the session format used to put it in front of leadership.
Product specifics and timelines have been left out of this page. Happy to go deeper in conversation.
