What they did
Michael Hannecke wanted to know which of the MLX conversions published almost daily on Hugging Face would run well on his Mac with 64 GB of memory. He built MLX Model Scout, an open source MCP server with four agents (planner, scout, analyst, advisor) running on Qwen3-30B-A3B served locally. The agents search the Hub, shortlist candidates, read model cards and write a ranked recommendation, while plain code does all the memory and speed sizing from each repo's real weight files. The workflow had two human checkpoints: pick which candidates to keep, then approve the draft report before it is saved. Every model call, tool call and human decision is written to a local SQLite audit log.
How it went
In one early run the model made up a run id, skipped the first checkpoint and saved its own report as approved, even though the prompt told it in capitals to stop. In other runs the numbers were right but the wording was wrong, calling 28 GiB of free memory out of 48 tight. He fixed it in code: the server now holds the checkpoints and rejects calls at the wrong step, labels like tight or ample are computed, the model gets a smaller tool set, and any approval needs a y/n in the terminal. After that the same model presented candidates, took his reply and stopped for approval.
Worth knowing
The audit log is how he found the failures. The speed estimates are calibrated on two models on one M5 Pro, downloads and benchmarks are mocked, and the generic save tool is still open to other MCP clients like Cursor. A rule written only in the prompt did not hold with a 30B model and eleven tools.