You’ve seen the slick demos. The beautiful UI. The confident promise of a ‘theory engine’ that would finally give AI the musical brains it’s been missing. Maybe you even got excited.
I did. Until I actually tried to use it.
A music theory engine that can’t handle flats isn’t a theory engine. It’s a facade.
That’s the frustrating realization I had after digging into @playbykey/theory, a TypeScript library and MCP server that presents itself as a complete music theory solution for AI. The website is gorgeous. The concept is ambitious: build a deterministic rule-based engine that prevents AI from hallucinating musically nonsensical structures. But then you notice the gaping hole.
No flat keys. No ability to construct chords in flat keys. A system that claims to be a ‘theory engine’ but skips half the notational universe.
You know that feeling when a tool looks incredible on the outside but fails at the basics? That’s the state of AI music right now. And it’s exactly the kind of blind spot that makes the entire AI push into creative domains feel like a beautifully painted ship with no keel.
Let’s be honest: I’m not picking on this one library. The developer put real work into it, and the MCP integration idea—letting an AI agent query a central theory authority rather than guessing notes—is genuinely clever. But the missing flats expose a systemic problem.
AI doesn’t need more beautiful interfaces. It needs fewer blind spots.
The irony here runs deep. The whole argument for building a ‘theory engine’ is that AI needs guardrails—deterministic rules to prevent the hallucinations that plague generative music. But if your guardrail itself has fundamental gaps, then the AI will simply hallucinate through those holes. A flat key might seem like a small oversight, but for anyone who has ever tried to notate a piece in F minor, it’s like building a bridge and forgetting the middle span.
This pattern repeats across AI development: polished prototypes that crumble under domain-specific scrutiny. We see it in coding assistants that generate buggy code, in image generators that can’t render hands, in text-to-speech that flubs complex phonetics. The pattern is always the same: shallow breadth, deep ignorance.
What makes the music case especially painful is that music theory is famously rule-heavy. It’s the perfect candidate for a deterministic engine—if you actually implement all the rules. Leaving out flats isn’t a feature omission; it’s a statement about priorities. The team focused on the product’s surface while the intellectual foundation remained incomplete.
And that’s the real lesson here. Not just for music, but for every field where AI is supposed to ‘understand’ something. The next time someone shows you an AI tool that claims to master a domain, ask them one question: ‘Can it handle a flat?’
The answer will tell you everything about whether they’ve built a true understanding or just a really good demo.
Because, in the end, the gap between marketing and reality isn’t a bug—it’s a signal. A signal that we’re still prioritizing speed and polish over depth. And until we learn to value domain completeness as much as we value UI shine, we’ll keep building engines that look incredible but can’t play a simple scale.
So yes, this little theory engine is a disappointment. But if it forces us to ask harder questions about what ‘understanding’ really means for AI, then maybe its biggest failure will be its most important contribution.
FAQ
Q: Why is missing flats such a big deal?
A: Music theory is built on flats and sharps—they're not optional extras. A 'theory engine' that can't handle flat keys is like a math engine that can't handle negative numbers. It's not an edge case; it's a fundamental gap that invalidates the claim of comprehensive theory understanding.
Q: What's the practical implication for AI developers?
A: Domain completeness must come before UI polish. Every missing rule or omitted notational element will eventually cause subtle failures that compound into nonsense. AI agents relying on such a system will produce more coherent-sounding but theoretically wrong music. The lesson: test your guardrails against real-world edge cases, not just the sunny path.
Q: Isn't it unfair to judge an early-stage project like this?
A: The criticism isn't about the project's maturity—it's about the gap between its marketing and its actual capability. The website and MCP integration promise a 'theory engine' that solves a real AI problem. If the promise exceeds the delivery, that's fair game for critique. More importantly, this pattern is endemic across AI: hype first, substance later. Calling it out is the only way to raise the bar.