BOSTON, JUNE 2, 2026 — intent engineering mcp, shipped
Intent Engineering MCP
◐ 0.1.0 · NPM + MCP REGISTRY · 2026-05-12
─ OPENER ─
It shipped on May 12, 13 days early. @swins/intent-engineering-mcp: a single-purpose Model Context Protocol server that lives on npm, runs locally, and gives any MCP client a small set of intent-engineering tools: prompt scaffolds, intent templates, an audit step. The kind of thing I had been hand-rolling into terminals for months before it occurred to me that this might be a package.
The reason it shipped early is that I cut the most exciting thing in the spec. The v1 had an embedded tool-call demo right here on this page: click a button, fire a real MCP call, render the response inline. I loved it. I cut it on April 30, the way you cut a scene that’s slowing the second act, and slid it to a separate future spec where it is currently gathering dust instead of breaking production.
What stayed is the load-bearing part: the DNS-verified registry listing, the npm publish, the install verification block, the handful of tools that actually do the job. The live block above this paragraph reads the install counts at 08:30 every morning. The investigation board below is the build calendar with the cut sitting visibly in the middle. The point of this page is the cut decision, not the ship date. The ship date was just the receipt.
─ INVESTIGATION BOARD ─
MCP protocol surface: 3-tool spec lock
tools/list + tools/call wired against the SDK. The three tools (audit_intent_spec, generate_intent_spec_scaffold, assess_retrofit_level) registered at this spec lock. Stdio transport only; no Streamable HTTP, no SSE.
Cut decision: keep registry verification, defer embed
Keep the DNS-verified registry block as v0.1.0's load-bearing trust signal. Defer the embedded tool-call demo to a separate future spec.
Verification is load-bearing for adoption trust; installs without it are taken on faith. The embed is retrospective polish: exciting, but the kind of exciting that slows the ship. Cut on purpose, on the calendar, before it cost the date.
Validation checklist canonicalized at 25 items
Scope-lock prose realigns to SKILL.md, not the other way around. 40-item reference reconciled to the canonical 25 across 7 sub-sections.
Source-of-truth discipline (scope-lock §3): SKILL.md is canonical. The earlier 40-item figure was paraphrased into scope-lock without verification. validation_score output reads X/25, not X/40. No Zod schema change.
@swins/intent-engineering-mcp@0.1.0: npm + MCP registry publish
npm publish lands at v0.1.0. MCP registry listing live under com.seanwinslow/intent-engineering with DNS-verified namespace. Thirteen days earlier than the date circled on the calendar.
Scale audit: 118 first-party skills by retrofit level (% of skills)
─ METHODS ─
| TASK | AGENT / TOOL | MODEL / COST |
|---|---|---|
| protocol implementation | TypeScript MCP SDK | open-source / $0 |
| transport | stdio | local / $0 |
| registry verification | DNS-verified MCP registry | free |
| package publish | npm | free tier |
| development environment | Claude Code | per-token billing |
─ 4Q ─
A-3.Q1 What is this?
An MCP server that exposes a small set of intent-engineering tools (structured prompt scaffolds, intent templates, an audit step) to any client that speaks the protocol. It runs locally, ships on npm, and is listed in the DNS-verified MCP registry as of May 12, 2026.
A-3.Q2 Why this approach?
Three shapes were on the table: a standalone CLI, a feature baked into a larger MCP, or a single-purpose registered server. The registered server won because the DNS-verified registry is the closest thing the MCP ecosystem has to a trust signal; installs without it are taken on faith, and intent-engineering is exactly the kind of tool a user has to trust before they hand it a prompt. Standalone CLI lost on distribution; the larger MCP lost on scope creep.
A-3.Q3 What would break?
Three named failure modes. One: the MCP spec revs faster than this server tracks, and the tools/list call returns a shape Claude Desktop no longer accepts; detection signal is the post-update health check failing in the install verification block. Two: DNS verification for the registry lapses on a domain renewal, and the registry quietly drops the listing; detection signal is the registry verification badge going stale on the public listing page. Three: a tool argument shape changes without a semver major bump, breaking installs at older client versions; detection signal is the install count flatlining while npm download counts hold.
A-3.Q4 What did I learn?
The thing that made it ship 13 days early was deciding what not to build. The embedded tool-call demo (fire an intent-engineering call from this case-study page and watch it return) was the most exciting idea in the spec and the first thing cut. It is a separate future spec, not a v1 feature. Cutting an exciting thing on purpose, on the calendar, before it costs you the ship date, is the only PM skill I trust now.