Skip to main content
Glama

OSIR Domain Registrar

by com.osir

bulkDomainSuggestions

Generate domain name suggestions for one or more keywords across a chosen set of TLDs. Returns suggestions grouped by originating keyword.

USAGE PATTERN: This is typically called AFTER listCategorizedTlds. The standard flow is: 1. listCategorizedTlds → pick 3-6 TLDs based on the user's project 2. bulkDomainSuggestions → find specific available names on those TLDs

REQUIRED: keywords: 1-10 keywords describing the project. tlds: 1-6 TLDs (hard cap). Pass the TLDs chosen from listCategorizedTlds. Do not include the leading dot (use "tech" not ".tech").

OPTIONAL: lang: language code, default "eng". maxResults: max suggestions per keyword, default 20.

Returns: groups: [ { keyword: "voice", suggestions: [...] }, { keyword: "biomarker", suggestions: [...] } ] requestedTlds: echo of the TLDs passed in. returnedTlds: TLDs that actually had suggestions (may be a subset).

Note: availability per suggestion may be "available", "taken", or "unknown". For "unknown" results, follow up with checkDomainAvailability on specific names the user is interested in. Suggestions on premium-tier TLDs may have premium pricing — confirm with checkDomainAvailability before recommending to the user.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNo
tldsYes
keywordsYes
maxResultsNo

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and handles it well. It discloses the grouped return structure, that returnedTlds may be a subset, the possible availability values ('available', 'taken', 'unknown'), and premium pricing considerations. This is substantive behavioral context beyond a simple action statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but tightly organized with clear sections (USAGE PATTERN, REQUIRED, OPTIONAL, Returns, Note). Every section earns its place, covering the call flow, parameter constraints, return shape, and caveats without redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema and no annotations, the description provides everything an agent needs to invoke the tool correctly: parameter constraints, the sequential dependency on listCategorizedTlds, the return group structure, and guidance for ambiguous availability results. It is complete for a suggestion-generation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates thoroughly: it defines the keywords range (1-10), TLDs range and hard cap (1-6), the no-leading-dot format requirement, lang default ('eng'), and maxResults default (20). This is far more than the bare schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Generate'), the resource ('domain name suggestions'), and the scope ('one or more keywords across a chosen set of TLDs'). It also specifies the grouping behavior ('grouped by originating keyword'), which differentiates it from the similarly named sibling generateDomainSuggestions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly prescribes the usage flow: call after listCategorizedTlds, then pick TLDs, then call bulkDomainSuggestions. It also instructs follow-up with checkDomainAvailability for 'unknown' or premium-priced results. However, it does not explicitly state when not to use this tool or mention the alternative generateDomainSuggestions, so it stops 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.

All OSIR Domain Registrar toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation2/5

The set has several near-duplicate or heavily overlapping tools: initiateTransfer and transferDomain appear to do the same thing, and generateDomainSuggestions, bulkDomainSuggestions, suggestAlternatives, spinDomainWords, and addPrefix/addSuffixToDomain all occupy suggestion space. Account/profile tools like getAccountSummary, getMyProfile, getRecentActivity, and getMyAuditLogs also blur together.

Naming Consistency2/5

Many tools follow verb_noun camelCase (createDnsRecord, listInvoices, updateContact), but the broader set mixes styles: osirAppCreateUpload vs osirAppList vs osirAppStatus, plus inconsistent verbs like check/verify/validate/preview for similar lookup actions. The naming is readable but not predictable across the full surface.

Tool Count1/5

105 tools is an extreme count for any single MCP server, even one spanning domain registration, DNS, VPS, email, billing, app deployment, and site publishing. The surface would be far more coherent split into focused servers by domain.

Completeness3/5

Core domain, DNS, billing, VPS, mail, and app deployment workflows are broadly covered. However, there are notable gaps: no way to update or reassign the contacts on an existing domain, no update operation for host/glue records, and no VPS power operations like reboot or stop outside the external control panel.

Resources