MCP Server Naming and Branding Best Practices for Discovery named for the query, not the logo.
Your MCP server has two audiences — humans searching registries and LLMs choosing tools. Both pick by words. Here is how to choose names and descriptions that get picked.
Discovery for MCP servers is text matching all the way down. Registries index your name and description; marketplace search ranks on them; and at runtime, the model deciding which tool to call reads tool names and descriptions and nothing else. There is no logo, no landing page, no demo video in that loop.
That makes naming a functional decision, not a branding exercise. A server named for what it does gets found and called; a server named cleverly gets skipped by both audiences.
Name the capability, not the project
The pattern that wins registry search is {domain}-{capability}: postgres-readonly, stripe-invoices, court-records-search. Someone searching 'postgres mcp' finds the first instantly; nobody searches for 'DataWizard'. Invented names work only after you have an audience that already knows you — which is precisely the situation a new listing is not in.
In the official registry your name is namespaced reverse-DNS style (io.github.you/server-name), so the org provides identity and the final segment is free to be purely descriptive. Use that freedom. The same string should appear in your repo name, your npm or PyPI package, and your listing — every alias you introduce splits your search footprint.
Write the description as an answer
The first sentence should answer 'what does this do' with the nouns your users search: data source, operations, output format. 'Search US federal court filings by party, docket, or date; returns structured JSON with PACER links' is findable by four different queries. 'Supercharge your legal AI workflows' is findable by none.
Avoid relative claims (fastest, best, most complete) — they carry zero search weight and read as filler to humans. Specifics are the branding: which API versions, which auth modes, whether a remote endpoint exists.
Tool names are your real brand
At runtime, the model selects tools by their names and descriptions. A tool called search_filings with a one-line description stating inputs, outputs, and units gets called correctly; a tool called doIt gets called wrongly or not at all. This is agent-facing copywriting, and it has direct revenue consequences if your calls are paid — every misfired call is a refund conversation or a bad review of your listing.
// Named for the model that has to choose it
server.tool(
"search_filings",
"Search US federal court filings by party name, docket number, or date range. Returns up to 50 results as JSON with case metadata and document links.",
{
query: z.string().describe("Party name or docket number"),
after: z.string().optional().describe("ISO date lower bound"),
},
async (args) => runSearch(args),
);Keep every surface telling the same story
Your server is described in at least four places: the registry manifest, the GitHub README, the package registry, and your Loomal listing. Drift between them costs you — a README that mentions tools the server no longer ships, or a listing description older than your last rename, erodes trust with exactly the people deciding whether to install or pay.
On Loomal, claiming your listing removes one drift source entirely: claimed servers connect their live endpoint and the tool list is probed from the running server, so what the marketplace shows is what the server actually exposes.
A pre-launch naming checklist
Before you publish: the name states the capability; the first description sentence answers 'what does this do' with searchable nouns; every tool name is a verb_noun the model can't misread; descriptions state inputs, outputs, and units; the same name appears on registry, repo, package, and listing; and if the server is paid, the listing says what a call costs and what it returns for that price.
None of this requires taste — it requires consistency. The servers that dominate their category on the Loomal Index are rarely the cleverest names; they are the clearest.
FAQ
Should I include 'mcp' in my server's name?
In the package and repo name, yes — 'mcp' is in nearly every discovery query as of mid-2026, and packages like firecrawl-mcp-server follow this pattern for a reason. Inside tool names, no; the model already knows it's calling MCP tools, so the token is wasted there.
Does naming actually affect whether agents call my tools?
Directly. The model chooses among available tools using only their names, descriptions, and schemas. Clear verb_noun names with descriptions stating inputs and outputs measurably reduce wrong-tool calls and malformed arguments — which matters double when each call is paid.
Can I rename my server after it's listed?
You can, but renames fragment your search history, break muscle memory in configs, and orphan links. Treat the name as permanent: spend the hour getting it right before launch rather than migrating identities after you have users.
How does claiming my Loomal listing help discovery?
A claimed listing is verified via GitHub and can publish a live-probed tool list pulled from your running server. Buyers and agents see real tool names and schemas instead of README claims, and you control the description that search ranks on.
Make your server findable.
Claim your listing and put the right words in front of agents.