Why agent names have extra constraints

A consumer brand mostly needs to be memorable and legally usable. An agent, MCP server, or CLI name also has to function as an identifier. People will type it after npx, pip install, or cargo add. It will appear as a server id in an MCP configuration, a binary on someone's PATH, a GitHub repository, and possibly a scoped package. Every one of those surfaces has its own collision rules, and a collision you discover after launch is expensive: renaming a published package breaks installs, documentation, and muscle memory at the same time.

That produces three practical requirements before taste even enters the picture. The name must be typeable: lowercase, short, no spaces, at most one hyphen people can remember. It must be sayable: your users will recommend tools out loud in meetings, videos, and pairing sessions. And it must be findable: a search for the name plus your category should not drown in an existing product with the same root.

Four naming patterns, and where each breaks

Role names describe what the agent is: assistant, copilot, pilot, agent, bot. They are instantly clear and almost impossible to own. The copilot suffix in particular is now crowded across the industry, and generic role names make trademark work harder, not easier. Use a role word as the descriptor next to a distinctive name, not as the name.

Imperative and tool names act like commands: short verbs or verb-noun compounds. They feel native in a terminal and read well in docs. The risk is a PATH or package collision with an existing utility, because short verbs were claimed decades ago. Check the exact string everywhere before falling in love.

Coined and mascot names are invented words or characters. They are the easiest to own, the strongest for trademark distinctiveness, and the most expensive to teach. They work best when the product will be used often enough that users amortize the learning cost, which is usually true for daily developer tools.

Descriptive infrastructure names state the mechanism: something-server, something-mcp, something-cli. For the package or repo, a descriptive suffix is genuinely helpful convention. For the brand itself, pure description blends into every neighbor. A common healthy structure is a distinctive brand plus descriptive artifact names underneath it, such as a product called Offhook shipping offhook-mcp and offhook-cli.

The namespace collisions that actually matter

Check the registries your users will install from, not every registry that exists. For most agent tools, four dominate:

  • npm: names are global and first-come. Scopes such as @yourorg/name sidestep collisions for libraries, but a CLI that users run by its bare command name still collides on the command, and npm restricts names that are too similar to existing packages. Check both the package and the binary name.
  • PyPI: names are normalized, so my-tool, my_tool, and My.Tool are the same name. A free hyphen variant does not exist if the underscore variant is taken.
  • GitHub: repository names only need to be unique within an owner, but the org or user name is the global identifier people remember. An available repo under a confusing org does not solve discovery.
  • crates.io: names are global with no namespacing at all, so Rust tooling has the tightest supply of good short names. If Rust is in your future, check it early.

Secondary surfaces worth a manual look when they match your channel: Homebrew formula names, Docker Hub, the VS Code extension marketplace, and the MCP registry id you plan to publish. For MCP servers specifically, keep the server id lowercase with hyphens or underscores, matching what users will type into claude mcp add or a config.toml table name.

One more collision class is easy to miss: model and product names from major AI vendors. Names too close to Claude, Codex, Gemini, or GPT invite both user confusion and trademark objections, and platform naming policies restrict some of these strings in app and extension stores.

TLD conventions for agent products

Developer audiences accept more endings than consumers do, but each carries a signal. .com remains the default for a company. .dev and .app read as developer-native and both require HTTPS by design, which is fine for any modern site. .ai signals the category and typically costs several times a .com per year, so verify first-year and renewal pricing at a registrar before you commit. .io is still common in developer tools, though no longer distinctive on its own. .sh and .tools work for CLIs with a narrow audience.

The practical rule: choose the endings you would genuinely launch on before generating names, then gate candidates on those endings only. Requiring an exact .com you do not need shrinks a strong candidate field for no reason; skipping the check entirely leads to a favorite you cannot use.

A worked example with the NamingSignal workflow

Suppose you are naming an open-source MCP server that summarizes production logs for on-call engineers. Here is the evidence-first pass, which you can run in the web app or from Claude Code or Codex through the MCP server:

  • Brief: one paragraph covering the user (on-call engineers), the painful job (drowning in noisy logs at 3 a.m.), the mechanism (summarization with sources), channels (GitHub, npm, word of mouth), and roots to avoid (log, watch, and guard compounds already crowded in observability).
  • Generate: a 40-name batch across four directions, coined, metaphor, mechanism, and outcome. Cost: 500 Naming Credits.
  • Check: survivors against .com and .dev plus exact GitHub, npm, and PyPI namespaces. 40 names on two endings is 80 combinations, 80 credits. Registry timeouts stay unknown rather than turning green.
  • Rank and research: an editorial ranking of the survivors (500 credits), then source-backed research on two finalists (250 each) covering namesakes, active same-category products, and preliminary trademark starting points.
  • Verify: open the winning candidate at a registrar, confirm price and registrability, and register the npm and PyPI names the same day you buy the domain. The whole run costs about 1,580 credits, roughly a tenth of the free monthly allowance.

The export at the end matters as much as the winner: which names were rejected and why, what evidence was collected and when, and which checks remain manual. Six months later, when someone proposes renaming, that record prevents the same debate from restarting at zero.

The trademark caveat, stated plainly

Software and AI classes are crowded, and a clean domain plus free npm name says nothing about trademark risk. Automated screening, including NamingSignal's finalist research, is preliminary due diligence: it can surface exact and close matches with sources so you walk into a professional conversation informed. It is not clearance. Before you invest in a launch, have a trademark professional review the finalist in the jurisdictions and classes that matter to you.

A compact checklist

  • Write the brief first: user, job, mechanism, channels, roots to avoid.
  • Generate breadth in distinct directions; do not count suffix swaps as new ideas.
  • Check only the TLDs you would launch on, plus npm, PyPI, GitHub, and crates.io as your stack requires.
  • Say every finalist out loud and type it after npx; kill anything that fails either test.
  • Treat unknown results as unknown, research one to three finalists, verify at a registrar, and get professional trademark review.
  • Register the package names and the domain together; a half-claimed name invites squatting.