Skip to main content
Glama

Suprsonic

by io.github.O-mega-Enterprise
OverviewDiscussionsAdmin

domains

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. First observed

TDQS

B3.2/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 contribute genuinely useful non-schema information: per-mode credit costs. That is real transparency value. However, it omits return shape, whether operations are read-only, rate limits, and pagination behavior, so it is only partial.

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 tight sentences with the purpose front-loaded and the cost data packed into a single scannable clause. No filler; every element earns its place. Slightly dense cost enumeration but well structured.

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, six-mode tool with nested objects and no output schema or annotations, the description omits mode-selection guidance and any sense of what each mode returns. The rich per-parameter schema descriptions partly compensate, but the description itself leaves meaningful gaps.

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 each parameter is already tagged with the mode(s) it applies to (tlds, query, domains, purpose, search_options, etc.), so the schema does the heavy lifting. The description adds little parameter meaning beyond restating the mode names in the cost list. 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?

States a specific verb and resource — 'Find domain names and the extensions that fit a business' — and the cost sentence enumerates the six mode capabilities (suggest-names, suggest-extensions, search-extensions, check-availability, pricing, tlds). It is clear about scope, though it describes the suggest-* flavor well while the pricing/tlds/availability modes are named only as line items rather than explained.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is offered. The description never says which mode to pick for a given intent, nor does it point to any alternative; the sibling list (search, site-intel) is not referenced. An agent must infer mode selection entirely from the schema.

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

All Suprsonic toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources