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…
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 I wrote on Tuesday — mcpize-health-daily, a Cowork scheduled task that pings the endpoint at 14:00 KST and counts the active tool list — 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, MCPize search, awesome-mcp-servers indexing, and the people who had clicked into the repo from my own X timeline.
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
Here is the diff in plain English.
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 second paragraph used to read like a vendor pitch — “Type A/B uncertainties, combined standard uncertainty, effective degrees of freedom, and expanded uncertainty.” Those terms are correct, but they read as features. I rewrote it to read like a checklist of audit-relevant primitives:
Compute Type A/B uncertainties, combined standard uncertainty u_c, effective degrees of freedom ν_eff via Welch-Satterthwaite, expanded uncertainty U with coverage factor k, Monte Carlo propagation per JCGM 101:2008, and apply pre-built KOLAS-ready uncertainty budgets — directly from Claude Desktop, Cursor, Windsurf, or any MCP client. No spreadsheet. No vendor lock-in. Standards-referenceable to JCGM 100:2008.
The two changes there are subtle. I added the JCGM 101:2008 reference next to Monte Carlo propagation, because that is the supplement number a metrologist will recognize and that an auditor will look up. I dropped “without leaving chat or switching to a spreadsheet” — which is a developer-tools selling point — and replaced it with “No spreadsheet. No vendor lock-in. Standards-referenceable to JCGM 100:2008.” A QA manager has had vendor lock-in burn them on uncertainty calculator software at least once. They know what those three sentences mean.
Then I added a section called “Why now — ISO 10012:2026” with two paragraphs explaining that the standard was published in February, that it is the first revision since 2003, that it adds practical guidance on Test Uncertainty Ratios and decision rules with guard-banding, and that this MCP is the only Model Context Protocol implementation that ships those primitives end-to-end. That section was sixty-three words. It is the only section a buyer needs to read to know whether to keep scrolling.
The Five Example Queries
The biggest change in conversion was probably the example query block.
The repo previously had no concrete query examples. The “Use cases” section listed personas and scenarios in vague language — the kind of paragraph you skim because it is selling, not showing. I replaced it with a section called “Five example queries (paste these into Claude Desktop)” and wrote five queries. Real queries. The kind you would actually paste:
- CMM length calibration at 10 mm nominal — uses the prebuilt template, computes u_c and U at 95%.
- 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.
- 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.
- Type-K thermocouple at 100 °C with a parameter override on the prebuilt template.
- 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. The previous paragraph said “calibration labs” and “AI engineers building quality-control agents,” which named no day.
Second, every query produces an answer that the buyer needs to produce anyway. They are going to compute u_c on a CMM. They are going to need a TUR on a DMM. 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 and concludes that the person who wrote this README has actually done this work. Whether or not that conclusion is correct — and in my case it is, I did the math kernel before I built the MCP — is less important than that the conclusion is reachable.
What Happened After
It is too early to measure conversion impact, because Wednesday-to-Saturday is a four-day window and the coordinated launch sprint that I had drafted has not yet fired. The 5-channel sprint goes out this Saturday at 23:00 KST.
What I do have is the operational change in the funnel itself. The README rewrite shipped at 15:19 local time on Tuesday. By Wednesday morning, the daily healthcheck task was logging “10 tools active” — the same as before. By Wednesday evening, the daily-pipeline-report Cowork task included one entry I had not seen before: a single referral from a search that had landed on the repo via the term “ISO 10012:2026 uncertainty MCP.” That term did not exist on the repo seven days earlier. It exists now because I wrote it down.
That single referral is not conversion. It is a signal that the repo is now indexable by the search a buyer would actually type.
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. I wrote my X as “AI engineers, metrologists, and semiconductor equipment teams” because that was the audience I imagined cheering for the technical work. The actual buyer was a third group I had not named. 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?” The reader scans your queries and decides whether one of them matches a job they have. 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. If the number is correct, you have spent real currency. If the number is wrong or vague — “compliant with international standards” — the buyer assumes you have not done the work. 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.
The repo has not changed since Tuesday. The endpoint serves the same ten tools. The next deploy will probably be Friday, when I add the KOLAS certificate auto-generation feature that is currently sitting as Issue #6 with three thumbs-up reactions from people I do not know. Saturday is the launch sprint. By Sunday morning I will know whether the new README converts or whether I have learned a different lesson entirely.
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: yb-ai-hustle.beehiiv.com (free, every Sunday morning KST).
메타데이터
- post_id
- d5e7aa18ecfe
- slug
- i-did-not-write-new-code-this-week-i-rewrote-two-paragraphs-and-ten-example-queries-d5e7aa18ecfe
- url
- https://medium.com/@kyb8801/i-did-not-write-new-code-this-week-i-rewrote-two-paragraphs-and-ten-example-queries-d5e7aa18ecfe
- canonical_url
- https://medium.com/@kyb8801/i-did-not-write-new-code-this-week-i-rewrote-two-paragraphs-and-ten-example-queries-d5e7aa18ecfe
- author_url
- https://medium.com/@kyb8801
- status
- ok
- fetched_at
- 2026-06-14 17:09:17