1. Impeccable (github.com/pbakaus/impeccable) — a CLI that scans HTML/CSS/JSX for 59 deterministic anti-pattern rules. It catches the actual visual tells: zero-offset dark glows on text, 1px borders paired with 40px shadow blur, Inter/Roboto/Geist as the default "tasteful" font.... etc.. I wont list all 59 here.

2.Taste Skill (github.com/Leonxlnx/taste-skill) — preventive rather than detective. It's a set of SKILL.md files you load into your coding agent (Cursor, Claude Code, etc.) before generation so the slop never gets created in the first place.

---

everyone knows about Em-dash overuse, but there are other tells like the dark background offset glow, thick boarders, flat display style, over use of techy color schemes like navy blue (especially with gradients) and emojis in headers as large style iconography. there are like 5 common fonts ai's use etc.. the key is, your llm is going to reason that these are all good safe choices and even when you tell them to be different they will give you great sounding logic as to why to use them... which is exactly the problem. every llm 'reasons' themselves into using the same choices so the sites all look the same.

I used to have: $200 Claude-max $10 github copilot $20 chatgpt $20 Cursor

---

then, I spent roughly $5000 in tokens for a project which turned out to be a dud. Figured, inference wasn't going anywhere as its now 80% of my day. So, I built a 4x DGX Spark cluster and put GLM5.2 on it. Then put a few qwen models for vision and embedding purposes on my original DGX Spark and completely went local. Tron, my Hermes agent, uses agent storming to orchestrate openCode agents and hermes subagents to handle most of my daily tasks.

For fun, I reworked a public Github vLLM Dashboard to track my usage and cloud cost avoided. original dashboard was by github.com/niklasfrick but I extended it. github.com/Wpnx330/spark-dashboard

---

For my day job I spend about $1000 + $20 a month in cursor costs.

We don't need large collections of assorted tools in one MCP server. Not trying to detract from the effort OP made... but we need a mechanism for finding, installing and managing our MCP servers effectively. Then monolithic collections aren't needed.

I believe collection servers are a band aide for the real problem. Useful for the individuals who built them, and often times not for too many others..... which is why I am building management tools for MCP servers. Hopefully to minimize the need for doing this. Because OP has filled a gap in the path available to them.