Onymu is an MCP server for domain name search, domain availability checking, and social media username lookup. Check a domain name against hundreds of TLDs in one call, including .com, .io, .ai, .co, and country-code extensions. Generate brandable startup names, business names, and product names from a keyword, and instantly see which ones are still available to register. Check username availability across major social networks so a brand name comes with matching handles. Save domains, set favorite TLDs, and recall recent searches to keep name research organized across sessions.
Save one extension to the caller's favorites. The leading dot is optional. Fails if it is already saved, or if the account is at its cap.
| Name | Required | Description | Default |
|---|---|---|---|
| tld | Yes | An extension, with or without the dot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given annotations already indicate this is a non-read-only, non-idempotent write operation, the description adds meaningful behavioral detail by disclosing the leading dot is optional and that the call fails on duplicate or cap. This goes beyond the annotation baseline without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff; the primary action is front-loaded and the edge cases are stated compactly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description supplies the essential behavior, the accepted input format, and the main failure modes. Nothing critical is missing for an agent to invoke it correctly."
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the sole parameter tld as 'An extension, with or without the dot,' and the description restates that the leading dot is optional. With 100% schema description coverage, the description does not add substantial new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Save one extension to the caller's favorites') with a concrete resource. It is easily distinguishable from sibling tools like list_favorite_tlds and remove_favorite_tld because it explicitly targets adding a single extension to favorites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when a caller wants to save a TLD to their favorites—but it never explicitly contrasts it with alternatives or states when not to use it. The failure conditions ('Fails if it is already saved, or if the account is at its cap') give context but do not provide clear routing guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a username is free on X, Instagram, Facebook, YouTube, TikTok, Snapchat, Pinterest, LinkedIn, Discord, GitHub, Telegram and Twitch, and how many apps already carry the name on the App Store and Google Play. Pair it with search_domains when someone is picking a brand name: a name is only really available if the domain AND the handles are. Handle answers are grouped into taken, available, unknown and invalid. unknown means the check could not be completed (the platform blocked it, or timed out) and must NEVER be reported as available. invalid means that platform's own username rules reject the string, so it cannot be claimed there at all. Two platforms answer a narrower question than their name suggests: linkedin checks the company vanity URL (linkedin.com/company/), not a personal /in/ profile, and facebook can only ever report taken or unknown — its logged-out surface cannot tell a free handle from a private one, so it never reports available and its absence from the taken list is not evidence the name is free. The two app stores are reported separately under appStores, NOT as handles: neither store has a username namespace, so they answer how many listings are already named this. Read named for 'apps called this' and matched for 'apps with this word in the title'; scanned is the denominator and truncated: true means the counts are floors. Omit platforms to check all fourteen. Checking several names at once skips X, which bans on volume.
| Name | Required | Description | Default |
|---|---|---|---|
| platforms | No | Platform ids to limit the check to: x, instagram, facebook, youtube, tiktok, snapchat, pinterest, linkedin, discord, github, telegram, twitch, appstore, googleplay. Omit for all fourteen. | |
| usernames | Yes | Handles to check, without an @ — e.g. ["northbeam"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already mark this as read-only, open-world, idempotent, and non-destructive, the description adds critical behavioral detail: unknown must never be reported as available, facebook can only return taken or unknown, linkedin checks company vanity URLs, app store results are separate, and counts can be floors when truncated. These are exactly the kind of non-obvious behaviors an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place for a tool with this many platform-specific exceptions. It front-loads the core purpose, then covers result grouping, unusual platform behaviors, app store semantics, and invocation caveats in a logical order. The density is justified by the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the full burden of explaining return semantics. It does so thoroughly: result categories, app store fields, boolean flags like truncated, and platform caveats. Given the tool's complexity and the absence of an output schema, this description is complete enough for a well-informed agent to call it successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the two parameters at 100% coverage, but the description adds substantial meaning beyond the schema: what each platform-specific result means, why appstore and googleplay are not handles, the distinction between named, matched, scanned, and truncated, and the volume-based X skip. This materially improves an agent's ability to choose and interpret parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether a username is free on X, Instagram, Facebook...' and immediately distinguishes this handle-checking tool from domain-focused siblings like search_domains. It clearly names the exact scope and the result categories, so an agent cannot confuse it with any other tool in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: pair it with search_domains when someone is picking a brand name, because availability requires both the domain and the handles. It also gives operational guidance such as omitting platforms to check all fourteen and warns that checking several names at once skips X, which directly informs invocation decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a keyword into brandable name candidates that are free to register. Generation is deterministic — no model is involved, so the same keyword always produces the same candidates — and it keeps drawing until it has count names free under at least one of the extensions checked, so what comes back is registrable, not merely plausible. Names blend in the keyword's synonyms by default and can blend in antonyms too; realWords keeps only dictionary words, maxWords caps how many words a name may be made of. Pass anything promising to search_domains for a wider sweep of extensions.
| Name | Required | Description | Default |
|---|---|---|---|
| tlds | No | Extensions to check the candidates against. Defaults to the caller's favorites, or the most popular ones. | |
| count | No | How many free candidates to return. Defaults to 8. | |
| prefix | No | Keep only candidates starting with this string. | |
| suffix | No | Keep only candidates ending with this string. | |
| keyword | Yes | The word to build names from. Letters and digits; anything else is stripped. | |
| antonyms | No | Blend the keyword's antonyms into the results. Defaults to false. | |
| maxWords | No | How many words a name may be made of; a blend counts as one. Defaults to 2. | |
| synonyms | No | Blend the keyword's synonyms into the results. Defaults to true. | |
| maxLength | No | Discard candidates longer than this. | |
| minLength | No | Discard candidates shorter than this. | |
| realWords | No | Only names made of dictionary words: the keyword's relatives and compounds of them, no invented endings or blends. Defaults to false. | |
| mustContain | No | Keep only candidates containing this string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond the readOnly/idempotent/non-destructive annotations: determinism ('no model is involved, so the same keyword always produces the same candidates'), a retry loop ('keeps drawing until it has `count` names free'), and an output-quality guarantee ('what comes back is registrable, not merely plausible'). These are execution traits an agent must know and are absent from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by execution behavior and then routing. The three sentences are dense but every clause contributes; the only mild redundancy is that the synonym/antonym/realWords/maxWords recap in the final sentence partially re-states the 100%-coverage schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, this is close to complete: annotations and schema cover safety and parameters, and the description covers purpose, execution cost (retry loop), and result quality. The notable gap is the untold return shape — a bare list of name strings versus objects carrying TLD/availability fields — which a missing output schema would otherwise have supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds real meaning on top: `count` is framed as a guarantee satisfied by continued drawing rather than a mere return limit, and the default blending behavior ('synonyms by default', 'antonyms too') clarifies the effective state of the boolean parameters. Some restatement of realWords/maxWords remains, but the added semantics push it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource: 'Turn a keyword into brandable name candidates that are free to register.' It states the scope (derived from a keyword, verified as registrable) and is clearly distinct from the sibling set — the closest overlapping sibling, search_domains, is explicitly named, while the generation focus separates it from save/remove/list favorites and username-check tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing instruction routes the agent to the one genuinely overlapping sibling: 'Pass anything promising to search_domains for a wider sweep of extensions.' This gives clear workflow context and an explicit alternative condition, though it stops short of a full when-not-to-use or exclusion matrix for the other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the words the caller has recently generated names from, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return. Defaults to 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context about caller scoping and newest-first ordering, but does not disclose other behaviors such as pagination or empty-result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler, front-loading the verb and resource, then adding the ordering detail. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter fully documented in the schema and safety covered by annotations, the description is largely complete. It could be slightly more explicit about the return being a list of words, but 'Read the words...' already conveys that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'limit' with full description, so the description adds little beyond the schema. It reinforces ordering but does not introduce new parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Read'), the resource ('words the caller has recently generated names from'), and the ordering ('newest first'). This distinguishes it from siblings like get_recent_searches by explicitly scoping it to generated words from the caller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieve the caller's recent generation words. However, it does not explicitly mention when to use this tool over the similar sibling get_recent_searches, nor does it provide exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what the caller has searched for lately, newest first. Use it to avoid re-suggesting something they have already looked at.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return. Defaults to 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral detail by specifying the result order ('newest first') and caller scoping, but does not describe return format or pagination behavior, which would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core purpose front-loaded in the first sentence and the usage context in the second. No filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter, rich annotations, and no nested objects, the description fully covers what is returned, the ordering, and the intended use case. Given the tool's low complexity, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'limit' is already documented with its default value ('Defaults to 20'). The tool description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('what the caller has searched for lately'), and adds the ordering ('newest first'). This clearly distinguishes it from the sibling get_recent_generations, which would cover 'generations' rather than 'searches'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence, 'Use it to avoid re-suggesting something they have already looked at,' provides a clear, explicit usage context. It does not name alternatives or state when not to use it, but the intended scenario is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the extensions saved on the caller's account, in the order they saved them. Empty either because they saved none or because they keep the list in their browser only. Call this before search_domains to scope a check to the extensions this person would actually register.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it preserves save order, explains that empty results can have two causes, and describes the intended role in a broader workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The core action is front-loaded, followed by a useful clarification about empty results and a concrete usage directive. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with no output schema, the description is complete: it states what is returned, the ordering, the meaning of an empty result, and the appropriate calling context. Sibling tools are also listed for further orientation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to explain about inputs. The description appropriately focuses entirely on behavior and output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('extensions saved on the caller's account'), and the ordering ('in the order they saved them'). It also explicitly contrasts with search_domains, making it easy for an agent to distinguish this tool from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to call this tool before search_domains to scope a check to the extensions the person would actually register. It also clarifies what an empty result means. It does not explicitly mention alternatives like list_saved_domains, but the primary usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the caller's shortlist of saved names, newest first. This is where anything worth keeping goes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: results are caller-scoped and sorted newest-first. However, it does not describe the return shape or whether pagination/limits apply, which is a gap given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is tight and front-loads the key facts: what is read, whose data it is, and the ordering. The second sentence adds conversational context but is somewhat redundant with 'saved names' and does not carry technical weight, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is largely complete: it identifies the resource, scope, and ordering. However, because no output schema is provided, a bit more detail about the expected return value (e.g., a list of domain name strings) would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing for the description to explain. Per the baseline for zero-parameter tools, the description adds sufficient meaning by clarifying what the returned list represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a clear resource ('caller's shortlist of saved names'), and ordering ('newest first'). This distinguishes it from sibling tools like list_favorite_tlds, which cover a different resource (favorite TLDs), and get_recent_generations/searches, which cover other history types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the caller wants their saved domain shortlist. However, it does not explicitly name alternatives or state when not to use it, such as when the caller needs favorite TLDs instead. Usage context is clear but exclusion/alternative guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop one extension from the caller's favorites.
| Name | Required | Description | Default |
|---|---|---|---|
| tld | Yes | The extension to remove, with or without the dot. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'caller's favorites', clarifying the scope of the operation beyond the annotations. It does not conflict with the destructiveHint and idempotentHint annotations, though it does not detail side effects like behavior when the TLD is not already a favorite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. Every word adds value and the core action and scope are communicated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description together with the schema and annotations is largely sufficient. Minor gaps include no mention of the outcome when the TLD is not currently a favorite, but this is unlikely to prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'tld' parameter, including the 'with or without the dot' detail. The description only repeats the concept as 'extension' without adding new semantic meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Drop') and a clear resource ('one extension from the caller's favorites'), which directly states the tool's action. It is easily distinguished from sibling tools like add_favorite_tld and list_favorite_tlds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of removing from 'the caller's favorites' implies when to use the tool, but there is no explicit guidance on when to choose it over alternatives or what conditions apply. The usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop one name from the caller's shortlist.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The saved name to remove. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=false), and the description is consistent with them, adding the caller-scope and one-item detail. It does not describe irreversibility, error behavior, or what happens if the domain is not currently saved, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that states the action and scope with zero filler. The key meaning is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with one required parameter, no output schema, and annotations that carry the destructive and read-only hints. The description is sufficient for an agent to invoke it correctly, though it could mention not-found behavior or confirmation semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: the only parameter, domain, is documented as 'The saved name to remove,' which matches the tool description's wording. The description adds no extra meaning, format, or example beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Drop one name from the caller's shortlist' uses an active verb (drop) and clearly names the resource (a saved domain/name), so an agent knows this removes one saved domain. It does not explicitly differentiate from the related sibling remove_favorite_tld, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from the caller's shortlist' implies this is the right tool when the user wants to remove a previously saved domain, which gives implied context for use. However, it offers no when-not-to-use guidance or alternative routing (e.g., pointing to remove_favorite_tld for TLD removal).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a name to the caller's shortlist. Accepts a full domain or a bare label — the site saves bare labels when a name is being compared across several extensions.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | A full domain or a bare label. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注释已声明readOnlyHint=false和idempotentHint=false，描述中的'Add'与之一致。描述添加了bare label保存行为的上下文，但未提及重复保存或覆盖行为。注释未提供更多细节，描述也未能补充副作用信息，但无矛盾，处于有注释时的最低合理水平。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
两句话，信息密度高：第一句定义核心动作，第二句解释参数变体的特殊用途。无冗余，每个词都有价值，结构清晰。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于单参数、无输出schema的简单工具，描述覆盖了动作、输入格式和特殊场景。缺乏返回值或错误处理说明，但工具简单，基本信息足以让agent正确调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema覆盖率为100%，domain参数已有基本描述。描述额外解释了bare label'被比较时保存'的场景，这为agent提供了何时传递裸标签的决策上下文，超越了schema的简单说明。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明'Add a name to the caller's shortlist'，动词和资源清晰，且通过'bare label'的说明与兄弟工具（如add_favorite_tld）区分。标题略显笼统，但描述具体化了保存的目标列表和输入格式，agent能准确理解工具用途。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述提供了bare label的使用场景（当在多个扩展名间比较名称时），但未明确说明何时使用save_domain而非替代方案，也没有排除条件。使用指导是隐含的，缺乏与add_favorite_tld等兄弟工具的直接对比。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether names are available, across many extensions at once. This is the main tool: availability is read from a registry-derived list of every registered domain, refreshed daily, so one call covers every extension you ask about and answers in milliseconds. Omit tlds to use the caller's favorite extensions, or the most popular ones if they have none. Names x extensions must not exceed 5,000 in one call — 25 names, for instance, admits at most 200 extensions. Results are split into available and taken, plus an unknown list for extensions the data does not cover - never report those as available.
| Name | Required | Description | Default |
|---|---|---|---|
| tlds | No | Extensions to check against, without the leading dot. Defaults to the caller's favorites, or the most popular extensions. | |
| names | Yes | Bare labels to check, without a dot — e.g. ["northbeam"]. Up to 25 per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond that: data provenance ('registry-derived list ... refreshed daily'), latency ('answers in milliseconds'), response structure ('split into available and taken, plus an unknown list'), and a critical interpretation rule ('never report those as available'). No contradiction with readOnlyHint=true, since checking availability is a pure read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences front-load purpose ('Check whether names are available') and progress logically through provenance/performance, default behavior, and the 5,000 cap. Every sentence carries operational load — the unknown-list warning, the defaults, and the limit — with zero filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the return structure (available/taken/unknown) and the interpretation rule for unknown entries. Annotations cover the safety profile, and the description covers defaults, limits, and result semantics, so nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds genuine value with the cross-parameter constraint 'Names x extensions must not exceed 5,000 in one call — 25 names ... at most 200 extensions,' which no single parameter schema can express. It also reinforces the tlds default behavior, though the schema already documents that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and resource: 'Check whether names are available, across many extensions at once.' This distinguishes it from siblings like check_usernames (username availability) and generate_domains (name generation), and the 'This is the main tool' positioning reinforces its role as the primary domain-availability lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: omit tlds to fall back to the caller's favorites or most popular extensions, respect the 5,000 names×extensions cap, and treat the unknown list as non-available. It positions this as 'the main tool' but does not explicitly name alternatives or state when-not-to-use conditions relative to siblings like check_usernames, so it stops just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_favorite_tldcheck_usernamesgenerate_domainsget_recent_generationsget_recent_searcheslist_favorite_tldslist_saved_domainsremove_favorite_tldremove_saved_domainsave_domainsearch_domainsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Domains MCP — domain registration lookup + availability search over live
Domain search MCP: .com names verified available live via Verisign RDAP - not AI guess lists
AI-powered domain & business name generation with real-time availability checks.
AI-powered domain & business name generation with real-time availability checks.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: domain availability search, username checking, candidate generation, saved domains, favorite TLDs, and recent history are clearly separated. There is no meaningful overlap that would cause an agent to select the wrong tool.
Tool names follow a mostly consistent verb_noun snake_case pattern, but there are minor variations: favorites use add/remove/list, saved domains use save/remove/list, and history uses get_recent_* rather than list_*. These are predictable per resource but not perfectly uniform across the set.
Eleven tools is well-scoped for the domain of brand name availability. Each tool earns its place and maps to a clear step in the workflow: searching domains, checking usernames, generating candidates, saving names, managing favorite TLDs, and reviewing recent activity.
The tool surface covers the full lifecycle of the domain: searching availability, checking social handles, generating candidates, saving/removing/listings saved names, managing favorite extensions, and reading recent history. There are no obvious dead ends or missing operations that would block the primary workflows.