I Did Not Write New Code This Week. I Rewrote Two Paragraphs and Ten Example Queries.

On Tuesday at 3:19 PM local time I committed the smallest, dumbest, highest-impact change I have made to my Model Context Protocol server since the day I made the repo public.

I rewrote two paragraphs in README.md. I added five concrete example queries. I removed one phrase. The diff was twenty-nine lines added, two lines removed. I did not touch a single Python file, no test was rerun, no version was bumped, no MCPize redeploy was triggered. The endpoint kept serving the same ten tools at the same Cloud Run instance. The deploy badge stayed green.

Then I closed the laptop and went to bed because everything I had been doing wrong for six days was about to embarrass me, and I needed to think about it from a distance.

This is the post about what changed and why I should have done it on day one.

Context: A Live MCP Server With a Funnel That Did Not Funnel

The product is measurement-uncertainty-mcp. I shipped it the previous week — a Model Context Protocol server that implements the Guide to the Expression of Uncertainty in Measurement (GUM, JCGM 100:2008) plus the Monte Carlo supplement JCGM 101:2008. Ten tools, GitHub Actions tests, AST-whitelisted formula parser, MCPize Cloud Run live at https://measurement-uncertainty.mcpize.run. I am proud of the technical work. I am embarrassed by the marketing.

Here is what happened in the seven days after public launch.

GitHub stars: 0. NPM downloads: 0. MCPize tool invocations: a handful, mostly mine. Aggregator submissions sat in three pending queues. A Show HN draft sat in a markdown file uncommitted because I kept second-guessing the title. The daily healthcheck task kept reporting "10 tools active, status Active." The infrastructure was healthy. The funnel was a corpse.

I spent two days assuming the problem was reach. So I drafted a 5-channel coordinated launch script — Hacker News Show HN, r/LocalLLaMA, r/MachineLearning, r/Calibration, MCP Discord, LinkedIn — pre-wrote every post body, scheduled it for the following Saturday at 23:00 KST. I was about to drop my one shot at a coordinated public launch into a funnel that, if it had been working, would already have shown some signal from organic discovery.

Sunday morning I sat down with the repo and read the README cold, pretending I was a stranger. That is when I noticed the sentence that was killing me.

The Sentence That Was Killing Me

The original second paragraph of the README, written six days earlier:

Built for AI engineers, metrologists, and semiconductor equipment teams who need to compute Type A/B uncertainties, combined standard uncertainty, effective degrees of freedom, and expanded uncertainty directly from their LLM assistant — without leaving chat or switching to a spreadsheet.

Read that sentence as if you are a calibration lab QA manager whose ISO 10012:2026 audit is in six months. You will bounce. You bounce on the first three words.

"Built for AI engineers" — you are not one of those.

You skim the rest. You see "metrologists" and "semiconductor equipment teams" and conclude this tool is for people who do science at companies that buy ASML steppers, not for the eight-person calibration lab in Bucheon that calibrates pressure gauges for petrochemical plants. You close the tab. You go back to the Excel template you were updating because somebody at ILAC published new guidance on guard-banding and your decision rule needs a paragraph.

That is the actual buyer of an uncertainty calculation tool. There are roughly ten thousand ISO/IEC 17025 accredited calibration labs globally. Each one has a QA manager, a senior metrologist, and a stack of Excel files. None of them describe themselves as "AI engineers." Most of them have heard of MCP only because their own kid mentioned it.

I had written the sentence six days earlier without thinking, because the first audience I had imagined for the launch was the indie-hacker-developer crowd that lives on Hacker News and r/LocalLLaMA. That crowd will star a clever MCP. That crowd will not pay for an uncertainty calculation tool because they do not have an audit in six months.

The sentence that needed to be there was a sentence that named the regulation, named the accreditation body, and used the buyer's own vocabulary.

The Rewrite

The first paragraph used to end with "GUM-compliant measurement uncertainty analysis." It now ends with: "GUM-compliant measurement uncertainty analysis. Built for ISO/IEC 17025 calibration labs, ISO 10012:2026 measurement management systems, and KOLAS / A2LA / UKAS accredited testing."

That is one phrase. It does five things at once. It names the standard the audit will be measured against (ISO/IEC 17025). It names the new standard published in February that triggered every lab to update their templates this year (ISO 10012:2026). It names the three accreditation bodies a calibration lab in Korea, the United States, and the United Kingdom respectively reports to (KOLAS, A2LA, UKAS). It signals that I know the standards numbers. And it does all of this before the reader scrolls.

The Five Example Queries

The biggest change in conversion was probably the example query block.

The repo previously had no concrete query examples. I replaced it with a section called "Five example queries (paste these into Claude Desktop)" and wrote five queries. Real queries:

1. CMM length calibration at 10 mm nominal — uses the prebuilt template, computes u_c and U at 95%.
2. CD-SEM 45 nm linewidth uncertainty budget — Type A from twenty replicate measurements, combined with magnification calibration and line-edge roughness, reports ν_eff via Welch-Satterthwaite.
3. DMM 10 V calibration with TUR check — references a standard at ±20 µV, asks for u_c, expanded U, and the Test Uncertainty Ratio against a tolerance.
4. Type-K thermocouple at 100 °C with a parameter override on the prebuilt template.
5. Non-linear ratio model — Y = (V × R) / (V + I) — Monte Carlo with 200,000 trials, shortest 95% coverage interval per JCGM 101 §7.7.

Three things make these examples convert that the previous "Use cases" paragraph did not.

First, every query names a real measurement scenario from a real lab. CMM at 10 mm. CD-SEM at 45 nm. DMM at 10 V. Thermocouple at 100 °C. A reader who works in any of those scenarios sees their own day in the example.

Second, every query produces an answer that the buyer needs to produce anyway. The example is not a demo. It is a job they have to do.

Third, the queries use the buyer's vocabulary back at them. ν_eff via Welch-Satterthwaite. Coverage factor k. JCGM 101 §7.7. A QA manager who has been writing uncertainty budgets for ten years recognizes that vocabulary instantly.

Three Lessons I Did Not Want to Learn

One. The "Built for X, Y, Z" sentence kills your funnel before it starts. If the X is wrong, the rest of the page does not get read. The sentence was a one-line buyer-persona declaration and I had declared the wrong persona. The fix — naming ISO/IEC 17025, ISO 10012:2026, KOLAS, A2LA, UKAS — took me twelve minutes once I knew what to write. The six days of zero conversion were the cost of not having known.

Two. Example queries are not documentation. They are job listings for your tool. Every example query you put in your README is a sentence that answers the question "what would I hire this tool to do for me today?" If you write generic examples — "compute uncertainty," "process this data" — you are listing a job nobody applies for. If you write "CD-SEM 45 nm linewidth uncertainty budget combining magnification calibration and line-edge roughness, report ν_eff via Welch-Satterthwaite" then somebody whose Tuesday looks like that recognizes their Tuesday in your README. They install. The cost of writing five concrete queries is one hour. The benefit is the entire conversion funnel.

Three. In a regulated niche, standards-referenceable language is the buyer's trust currency, and you are spending counterfeit currency if you skip it. A calibration lab QA manager has been burned at least once by a vendor whose product claimed compliance with a standard that the vendor had not actually read. Every time you cite a standard in your README — JCGM 100:2008, JCGM 101:2008, ISO 10012:2026, ISO 14253-1, ILAC G8 — you are putting a number on the page that the buyer can look up. In an unregulated developer niche this lesson does not apply, because developers do not look anything up. In a regulated niche it is the difference between getting installed and not.

What I Will Not Do Again

I will not write a "Built for X" sentence on a regulated-niche README without first writing down the three standards numbers that the buyer types into Google when they have a problem. If I cannot write down the three standards numbers, I do not understand the buyer well enough to be writing the README at all, and the right next action is to read the standards, not to write more code.

I will not ship a README with no example queries. The example queries are the part the buyer reads. The rest is the part they skim while deciding whether to read the queries.

I will not assume that an MCP server's discovery problem is a reach problem before I have read my own README cold, pretending I am the buyer. The reach problem is real. The wrong-buyer problem is more common.

If you are running a solo MCP, a solo SaaS, or any indie product where the funnel feels broken and the build is fine, please go read your README cold. Pretend you are the buyer. Pretend you have an audit in six months. See how long it takes you to bounce.

If it is fewer than three sentences, the build is not the problem.

---

Repo: github.com/kyb8801/measurement-uncertainty-mcp. Live MCP: measurement-uncertainty.mcpize.run. Weekly solo-builder build log at YB's AI Hustle Weekly — same operational logs, every Sunday morning KST.