信雄吉行

71,929 to 581 tokens is a brutal number to see once someone actually measures it — the "silent context tax" framing is exactly right, because most people (myself included, before reading this) assume the cost only shows up when a tool actually executes, not on every single idle turn just for the model to know the tool exists. To answer your question: I've been connecting MCP servers across a few different agent contexts recently — registry-based discovery for agent payment/commerce tools (x402-adjacent work) and some coding-agent workflow tooling. The config-silo problem you describe is real even outside Cursor/Claude Code specifically — anywhere a tool definition needs to be declared once but consumed by multiple clients with different expected schemas, you get the same duplicate-JSON-files failure mode. I hadn't quantified the idle-turn token cost before, so seeing it benchmarked this concretely is genuinely useful. One thing I'm curious about on the lazy-hydration side: when the gateway swaps a compact name for the full schema on tool selection, how does it handle a server whose tool schema actually changes between the name-index being cached and the moment of selection (e.g. a server that's mid-deploy, or a remote SSE endpoint that updates its own tool list)? Does the gateway re-validate against the live server at hydration time, or is there a risk of the model selecting a tool by a name whose underlying contract has already drifted? On the project itself — since mcptoon is sitting at ~200 stars and solving a problem basically everyone with a multi-tool setup will eventually hit, there's a reasonably clear monetization path if you wanted to pursue it: keep the local sync/CLI free and open, but offer a small hosted tier for teams — shared server declarations across a whole team's machines, audit logging of what got hydrated when, or managed name-index caching for larger toolchains than a solo dev would hit. That's roughly the open-core shape a few other dev-tooling projects in this space have taken, and the "single source of truth synced to every client" pitch sells itself to a team lead who's tired of onboarding new hires onto 4 different JSON configs by hand. Solid writeup — going to look at mcptoon for my own setup.

This is a genuinely useful reframe — "treat your publishing site like a software product" is the right mental model, and the honest-disqualification point is the part most affiliate/review sites get backwards. Readers can tell within a paragraph whether a site is optimizing for their trust or for a click, and the disqualification examples you gave (pricing tier jumps, who shouldn't buy) are exactly the signal that's missing from 95% of "best X" content. I build RAG/LLM pipelines and scraping/automation systems for a living, so the data-aggregation section is close to my daily work. One thing I'd add to the requests/BeautifulSoup/pandas pipeline you described: once you're structuring scraped spec/pricing data into tables, that same structured store is a natural fit for a lightweight RAG layer on top — instead of just generating comparison matrices once, you can let an LLM answer specific long-tail questions directly against your own verified data ("does X support Y at this price tier") rather than writing a page for every possible query combination in advance. That compounds well with your high-intent/long-tail point, since it lets you cover the long tail of questions you didn't anticipate, grounded in data you've actually verified rather than the model guessing. On the revenue side, since you're already treating this as a software product: the scraping+structuring pipeline itself is a sellable asset independent of the content site. Once it reliably tracks pricing/spec changes for a niche, a small paid API or data feed for that niche (other publishers, affinity marketers, or even the vendors themselves wanting competitive tracking) is a second revenue line that doesn't depend on search rankings at all — which fits neatly with your "own your distribution" point, since it's revenue that isn't exposed to a core algorithm update either. Solid piece — the framing of content-as-engineering-problem is the right one, and more people writing in this space should think in these terms.