Namoly

Resources · For developers

Connect your AI agent to Namoly

Let your AI agent score brand names through Namoly, under your own account, in about a minute and with no API key.

If you work with an AI agent, you can let it run Namoly analyses for you. Point the agent at Namoly's MCP server once, approve it in your browser, and from then on it can score a brand name, list the analyses you have already run, and pull up a full report, all under your own account and drawing on your own history. This guide covers what the connection actually does, how to set it up, how the security model keeps it safe, and where it stops.

Same analysis, wherever you run it. Your agent runs the exact same four deterministic checks as the website (domain availability, memorability, phonetics, and cross-language safety), with no AI in the MVP. It does not check trademarks or social handles, and it draws from your own per-user rate limit, so an agent and your browser share a single budget rather than getting separate quotas.

Try a name analysis, free

Instant, objective, and free. No signup needed to try one.

What your AI agent can do with Namoly

MCP, the Model Context Protocol, is an open standard that lets an AI agent call external tools in a consistent way. Namoly exposes three of them. Every one runs against your own account, using the same analysis engine and the same history table as the website, so nothing your agent does is walled off in a separate system. A report your agent creates is a report you can open on the site, and a name you analysed on the site is one your agent can pull up later.

analyse_name (permission: analyse). Runs a full Namoly analysis on a name your agent hands it and returns the finished report. If you have already analysed an identical name, it returns a short "exists" pointer to the analysis already sitting in your history, the same informational nudge the website shows when you re-run a name. Re-analysing is free, and your agent can pass a force flag to run a fresh analysis anyway.

list_analyses (permission: history:read). Returns a slim, newest-first summary of your saved analyses: the name, score, band, date, and confidence for each, plus a cursor to page through more. It never returns the full reports, so your agent can scan your history without flooding its own context with detail it does not need yet.

get_analysis (permission: history:read). Returns one analysis in full, with every category, justification, and tip, for when your agent has an id from the listing and wants the complete report.

A common pattern ties the three together. Your agent brainstorms a batch of candidate names, calls analyse_name on each to get an objective score and the reasons behind it, then uses list_analyses to compare the batch and get_analysis to pull the full report on the two or three that scored well. Because the results land in the same history you browse on the site, you can pick up where the agent left off, open any of them, and compare them side by side later without re-running a thing.

The scores your agent sees are the scores you would get by typing the same name into the site yourself.

How to connect your agent

Connecting takes two short steps: point your client at Namoly, then sign in. Pick your client below for its exact command or config, and for the sign-in step, which differs from one client to the next. Every client points at the same endpoint, Namoly's MCP server at https://namoly.io/api/mcp, so any client not listed here that speaks Streamable HTTP and can run the standard sign-in flow connects the same way.

  1. Add Namoly as an MCP server.

    claude mcp add --transport http namoly https://namoly.io/api/mcp
  2. Sign in by running the login command, or use the /mcp command inside Claude Code.

    claude mcp login namoly

Claude Code MCP docs →

Two things happen without any action from you. Your client registers itself with Namoly's authorization server, and it discovers the connection details on its own from Namoly's public metadata documents. That is why there is no API key to generate, copy, or paste anywhere: the client sets itself up, and your Google sign-in does the rest. If a step fails, it is almost always the browser handoff, so make sure the machine running the agent can open a browser to sign in.

Sign in with Google, not an API key

Namoly does not hand out API keys, and it does not ask you to paste one. It acts as its own OAuth 2.1 authorization server, so connecting an agent is the same "sign in with Google, then approve" pattern you already know from other apps, run by Namoly on Namoly's own domain rather than delegated to a third party. Your agent is treated as a public client and proves itself with PKCE, a standard exchange that needs no shared secret, which is the technical reason there is nothing for you to configure.

The one screen that matters is the consent screen, and it is mandatory: no agent gets access without it. It shows you three things before you approve. First, the name the agent reported for itself, marked as self-reported and untrusted, because a client picks its own name and Namoly does not vouch for it. Read it and confirm it is the agent you just tried to connect. Second, the permissions it is asking for, written in plain English (run analyses, read your history, or both), never as raw scope strings. Third, the exact host your approval will send the result to, so a redirect somewhere unexpected is visible before you click, not after.

Access is deliberately short-lived. The access token your agent uses to call Namoly lasts one hour. Behind it sits a refresh token that lasts 90 days and rotates on every use, so a token presented a second time is treated as a leak and the whole chain is cut rather than left working for an attacker. You do not manage any of this by hand; it is simply why a connection stays safe without you thinking about it day to day.

And you stay in control. Every agent you connect appears under Connected agents on your account page, with its name, the permissions it holds, when you connected it, and when it last called. Disconnect revokes every token for that agent at once, so it stops working at its very next call, not at the end of the current hour. If a connection ever looks wrong, that is the single button to reach for.

You will rarely think about the connection once it is set up, but it is worth knowing how it ends. Access tokens refresh silently in the background, so a working agent keeps working without prompting you again. If you leave an agent unused past the 90-day refresh window, or you disconnect it yourself, the next call simply fails and you reconnect the same way you connected the first time, with a fresh consent. Nothing is lost, because your history is tied to your account, not to any single agent, so a reconnected agent sees exactly the analyses it saw before.

What it costs, and what it does not check

Connecting an agent costs nothing, and neither does using it. The MVP is free, and re-analysing a name is free. Your agent does not get its own separate quota either. It draws from the same per-user rate-limit bucket as your browser, so an agent and the website share one budget: a burst of analyses from your agent spends the same allowance you would spend running them by hand on the site.

It is worth being exact about what the agent checks, because it is precisely what the website checks and nothing more. Every analysis runs the same four deterministic categories, weighted the same way: domain availability (0.30), memorability and distinctiveness (0.25), phonetics and readability (0.25), and cross-language safety (0.20). Deterministic means the same name and context always produce the same scores. There is no AI in the analysis in the MVP, so nothing is guessed, and every score carries a confidence signal so a low-confidence result never reads as a confident verdict.

Two things the agent leaves to you. It does not check trademarks, and it does not check social handle availability. A clear domain is not proof that a name is legally free to use, so treat an analysis as an objective read on the name itself, then run the trademark and handle checks yourself before you commit to anything. The companion guide on how to check if a brand name is available walks through those layers in order.

Frequently asked questions

Do I need an API key?
No. Namoly does not issue API keys and never asks you to paste one. It is its own OAuth 2.1 authorization server, so you connect the same way you sign in to the site: sign in with Google, then approve a consent screen. The only credential involved is your Google sign-in, which stays with Google. Your agent authenticates with a short-lived token it obtains for itself, not a secret you manage.
Which AI agents can connect?
Any MCP client that speaks Streamable HTTP and can run the standard OAuth 2.1 sign-in flow. The picker in this guide gives the exact steps for Claude Code, Codex, OpenCode, Windsurf, Antigravity, and Claude Desktop. Some use a one-line command, others take a short config block, and each has its own sign-in step. Anything else conformant connects the same way, because it is a plain MCP endpoint. There is no Namoly-specific plugin to install, and no API key for any of them.
Can my agent see my whole history?
Only if you grant it. Reading your saved analyses needs the history:read permission, which is shown on the consent screen and which you approve. An agent granted only the analyse permission can run new analyses but cannot list or open your existing ones. Every call is re-checked against the permissions you approved, so a tool your agent never had access to stays out of reach.
Is it really free?
Yes. The MVP is free, and re-analysing a name is free, so an agent that re-runs a name it already analysed simply gets back a short "exists" pointer to the saved report. Your agent shares your own per-user rate limit with the website instead of getting a separate quota, so the two draw from one budget.
How do I disconnect an agent?
Go to your account page and open Connected agents. Each connected agent is listed with its name, the permissions it holds, when you connected it, and when it last called. Disconnect revokes every token for that agent at once, so it stops working at its very next call rather than at the end of the current hour.

See what your agent will score

Whether you drive it from an agent or type it in yourself, every Namoly analysis is the same objective read: four deterministic categories, clear reasons, and a confidence signal on each. Run one now to see exactly what your connected agent gets back, then point your MCP client at Namoly when you want your agent to do it for you.

Analyse a name, free

Objective scores. Clear reasons. Zero cost.