I shipped my first MCP server in April under the name canvas-mcp. Three weeks later I renamed it to framesmith — same code, same project, new identity. Then I had to write a “we renamed it” launch post that, honestly, nobody actually wants to read.

Worth it. Here’s why, and the lesson I’d give past-me before I picked the original name.

The two real problems

Problem 1: the name described the wiring, not the work.

canvas-mcp was honest about what the project is — an MCP server that gives an AI agent a visual canvas. But honesty about implementation is different from honesty about value. To anyone scanning a list of devtools, -mcp reads as plumbing. Servers, schemas, transport layers. Nobody wakes up wanting an MCP server. They wake up wanting their agent to stop writing 200 lines of React they’ll throw away because the design wasn’t what they pictured.

The name was filtering for the wrong audience. The people who clicked through were mostly other MCP builders curious about the protocol. The people I actually wanted — devs sick of the agent-shipping-blind problem — kept scrolling.

Problem 2: a literal SEO and namespace collision.

“canvas” collides in spirit (and almost in package slug) with Canvas LMS, the education platform half my potential audience touches at work. Every Google search for “canvas-mcp” surfaced unrelated results. SEO was a non-starter from day one, and it would only have gotten worse — Canvas LMS spends real money on its name. I was never going to outrank them.

These are different problems with the same root: I picked a name that described how the project worked, not what it did for the person using it.

What framesmith fixes

Same project, still MIT, still works with Claude Code, Codex, Cursor, Windsurf, and any MCP client. But:

• It names a verb the user cares about. A framesmith is someone who forges frames. The reader’s job is to ship screenshot-tested UI; the tool’s job is to help them forge it. The user is the smith, the tool is the forge. The MCP transport is invisible to that mental model, which is exactly where transport belongs.
• It’s a real English word people will spell correctly on the first try. “canvas-mcp” has a hyphen, a three-letter acronym, and a noun nobody outside the protocol cares about. “framesmith” you can hear on a podcast and type into a URL bar.
• It owns its search results. The competition is a few jewelry artisans. I outrank them by week two.

The rebrand cost me one weekend: rename the npm package, update the GitHub repo (with redirects), republish, write the announcement post, retell the story on X and LinkedIn with continuity back to the original launch. Annoying work. But the new name lets the project punch in the audience I wanted from the start, instead of getting filtered into the MCP-protocol-nerd bucket. Worth the weekend.

A naming checklist I now use

Before naming any OSS project in the agent/MCP era, I run candidates through this:

1. Does the name describe what the user does, or how it’s built? If it has -mcp, -sdk, -cli, -api, or -server in the slug, you’re naming the wiring. The wiring is invisible to anyone who isn’t already inside the protocol.
2. Can you say it on a podcast and have the listener spell it right? If not, you’ve added friction to every word-of-mouth recommendation you’ll ever get.
3. Google the candidate. Look at the first ten results. If the front page is dominated by something else with the same string — a SaaS product, an educational platform, a celebrity — your SEO ceiling is already low. Pick again.
4. Check npm, GitHub, and the relevant package registries. Slug collisions are silent killers. Your install command becomes asterisk-laden and your StackOverflow answers fight with someone else’s.
5. Does the name age past the underlying tech? “canvas-mcp” presumed MCP would matter forever. Maybe it will. But naming a product after a protocol bets your brand on that protocol’s longevity. “framesmith” still makes sense if the transport changes to HTTP, gRPC, or whatever comes next.

That’s the whole framework. A candidate failing one of these isn’t automatically wrong — but you should know what you’re trading away before you ship.

What I’d tell past-me

The first version of an OSS project doesn’t deserve a careful name, because you don’t know what the project really is yet. But the moment it starts working — the moment people other than you start using it — the name becomes part of the product. You can rename later (I did) but renaming costs you cumulative momentum, search history, and the SEO juice of every launch post you’d already written under the old name.

So the rule isn’t “spend three weeks picking the perfect name before you ship.” It’s: ship under a name you’d be okay carrying for a year, even if it isn’t the final one. Avoid the obvious traps — describing the wiring, slug collisions with bigger names, words people can’t spell. Those traps are cheap to avoid up front and expensive to escape later.

If I’d run my own checklist on canvas-mcp before publishing, I’d have caught at least two of the five red flags. I didn’t, because I was excited and the name was descriptive. Descriptive isn’t the same as good.

framesmith is the second name. It won’t be the last good positioning call I’ll have to make on this project. But it’s the one I’ll carry going forward — and the checklist is the actual artifact I wish I’d had three weeks earlier.