Skip to main content
Glama
O-mega-Enterprise

suprsonic-mcp

by O-mega-Enterprise
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

domains

Find domain names and extensions that fit a business. Check availability and compare pricing across TLDs.

Instructions

Find domain names and the extensions that fit a business. Cost: suggest-names 5 credits, suggest-extensions 3 credits, search-extensions 2 credits, check-availability 1 credit, pricing 1 credit, tlds 1 credit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoWhich domain capability to run.suggest-names
tldsNoExtensions to price (pricing), to check the name across (search-extensions), or to restrict name ideas to (suggest-names).
queryNoAn exact name to check across extensions (search-extensions).
offsetNosearch-extensions: pagination offset into the catalog.
domainsNoFull domains to check, e.g. ["brewhaven.com"] (check-availability).
purposeNoWhat the domain is for (suggest-names / suggest-extensions): website (the site address), cold (a dedicated cold-email domain, kept apart from the site) or extra. Context the model weighs when judging fit; it sets no search options, which are yours to choose (search_options) from what the company needs.
company_idNoOptional O-mega/Founden company id; pulls the real business brief to ground the fit.
descriptionNoWhat the business does; grounds the fit (suggest-* modes).
company_nameNoThe business name (suggest-extensions), or for suggest-names a natural-language brief: any ordering or limit it states (for example "shortest" or "renewal under $15") is read and applied beneath your explicit search_options.
search_optionsNoSearch options, only the fields you set (suggest-names / search-extensions / suggest-extensions): priorities (objective keys in priority order: total_length, annual_price, renewal_price, registration_total, semantic_fit, brandability, label_length), max_total_length and max_label_length (characters), max_annual_price, max_renewal_price and max_registration_total (USD), hacks (include, exclude or only) and allow_premium (boolean). A field you set wins over what the company_name brief asks for; null (or priorities: []) leaves that field to the brief; unknown keys are rejected. Options that do not apply to a mode are ignored there. The response echoes the effective options (search-extensions: search_options; suggest-names: search_plan.search_options).
exact_extensionNosearch-extensions: check ONLY the typed extension.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does add genuinely useful information: exact credit costs per mode. However, it says nothing about read vs write semantics, whether any mode mutates state, rate limits, or failure behavior for the availability checks.

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

Conciseness4/5

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

Two sentences, purpose front-loaded before the cost table, and no filler. The cost enumeration is dense but every item maps to a real billable mode, so it earns its place.

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

Completeness3/5

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

For an 11-parameter, multi-mode tool with a nested search_options object and no annotations or output schema, the description covers purpose and billing but omits mode-specific workflows, ordering between modes (e.g. suggest then check-availability), and return expectations. The very complete schema compensates for much of the gap.

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

Parameters3/5

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

Schema description coverage is 100% and the parameter descriptions are unusually rich (mode-specific applicability, priority keys, override rules for search_options). The description adds only credit costs per mode and no parameter-level 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.

Purpose4/5

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

The description states a specific verb and resource ("Find domain names and the extensions that fit a business") and enumerates the six modes, so an agent knows this is a domain-sourcing tool rather than a generic search tool. It is clear, but it never contrasts itself with siblings like search or companies, so differentiation is left to inference.

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

Usage Guidelines3/5

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

The per-mode credit costs implicitly hint at trade-offs between the heavier suggest-* modes and the cheap lookups, which nudges mode selection, but there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The schema's mode enum does the real routing work.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools