The readme is so thick with breathless LLMisms that it makes one wonder what is the point.
That's a bit sad because the book's website and blog appear interesting, the author can write.
Still: shall I spend 10 bucks by buying and reading the book, or by consuming tokens on LLMs that read it?
> the book's website and blog appear interesting, the author can write
I'll take the compliment!
README was 100% intended for robots, not humans (book is 100% for humans, FWIW). I'd be impressed if you can spend $10 on tokens interacting with the MCP. That's one reason why I went with an MCP over a skill. A lot of the logic is offline/token free.
This has been very inspiring for a MCP design novice like me; I can now implement executable tools, reference knowledge, and user workflows in my own MCP.
This was my first "real" MCP server (previously I made an MCP server to control a Furby for GitHub Universe) and I learned a lot. A few things I learned (not an expert):
* Tool vs. Resource: Does it compute or does it serve
* Prompts -> Tools
* Deterministic vs. Probabilistic is a choice per tool
Fixed rubric. It works on regex matching across interpersonal tension, active incident, sensitivity, and ambiguity. If a pattern matches, it weights sync over async.
The "book as an MCP server" framing is the part that interests me. I run a small MCP server myself (semantic search over government documents), and the thing I keep noticing is that the interface changes what people ask — nobody asks a PDF "what should I do in my situation," but they'll ask a tool that. Shipping specialized tools (draft_decision_doc etc.) over one generic ask_the_book tool also seems like the right call — clearer intent per call, less context spent on tool descriptions. I noticed you went with keyword search over a summary corpus plus citations rather than embedding the full text — curious whether that was a licensing decision (keeping the manuscript out of the package) or you found summaries-with-citations just work better for this kind of prescriptive content than semantic retrieval over the full prose?
Partially licensing, but also tokens + efficiency. As noted above, the book is written for humans (anecdotes, examples, etc.). Robots just need the facts and can extrapolate. If I were building a hosted service, a custom LLM with embeddings would probably beat both approaches.
The readme is so thick with breathless LLMisms that it makes one wonder what is the point. That's a bit sad because the book's website and blog appear interesting, the author can write. Still: shall I spend 10 bucks by buying and reading the book, or by consuming tokens on LLMs that read it?
> the book's website and blog appear interesting, the author can write
I'll take the compliment!
README was 100% intended for robots, not humans (book is 100% for humans, FWIW). I'd be impressed if you can spend $10 on tokens interacting with the MCP. That's one reason why I went with an MCP over a skill. A lot of the logic is offline/token free.
This has been very inspiring for a MCP design novice like me; I can now implement executable tools, reference knowledge, and user workflows in my own MCP.
This was my first "real" MCP server (previously I made an MCP server to control a Furby for GitHub Universe) and I learned a lot. A few things I learned (not an expert):
* Tool vs. Resource: Does it compute or does it serve * Prompts -> Tools * Deterministic vs. Probabilistic is a choice per tool
How does `triage_sync_vs_async` handle team-specific norms — fixed rubric, or does it lean on the model's judgment from context?
Fixed rubric. It works on regex matching across interpersonal tension, active incident, sensitivity, and ambiguity. If a pattern matches, it weights sync over async.
So nice to see a new library written in JavaScript instead of TypeScript.
The "book as an MCP server" framing is the part that interests me. I run a small MCP server myself (semantic search over government documents), and the thing I keep noticing is that the interface changes what people ask — nobody asks a PDF "what should I do in my situation," but they'll ask a tool that. Shipping specialized tools (draft_decision_doc etc.) over one generic ask_the_book tool also seems like the right call — clearer intent per call, less context spent on tool descriptions. I noticed you went with keyword search over a summary corpus plus citations rather than embedding the full text — curious whether that was a licensing decision (keeping the manuscript out of the package) or you found summaries-with-citations just work better for this kind of prescriptive content than semantic retrieval over the full prose?
Partially licensing, but also tokens + efficiency. As noted above, the book is written for humans (anecdotes, examples, etc.). Robots just need the facts and can extrapolate. If I were building a hosted service, a custom LLM with embeddings would probably beat both approaches.
[flagged]
[flagged]
[flagged]
[dead]