Skip to main content
Glama

Check domain availability and indicative price

check_domain_availability
Read-onlyIdempotent

Check whether a domain can be registered and get an indicative price (VAT included where it applies). Read-only: it never buys, registers or reserves a domain. alternatives:true also checks the same name on be, com, net, eu, nl, io, dev and app. Not tied to a site. The result states whether the user's plan includes buying domains in the dashboard (purchase.dashboardUrl); a domain the user already owns is connected with add_custom_domain.

Input Schema

NameRequiredDescriptionDefault
domainYesThe domain to check, e.g. "example.com".
alternativesNoWhen true, also check the same second-level name across a canonical TLD set (be, com, net, eu, nl, io, dev, app) and return each one's availability + indicative price.

Output Schema

NameRequiredDescriptionDefault
noteYesReminder that the price is indicative and nothing was bought.
domainYes
currencyYesISO currency code for the price (e.g. EUR).
purchaseYesWhether and where the user can buy a domain through VibeDeploy.
availableYesWhether the domain can be registered through VibeDeploy right now.
ownDomainYesHow a domain the user already owns is connected instead.
priceCentsYesIndicative price in cents (VAT included where it applies), or null when no price is published.
alternativesNoPresent only when alternatives:true was requested.
unavailableReasonNoSet when the registrar lists the name as free but VibeDeploy cannot register it. MULTI_YEAR_ONLY: this extension is only sold for two years or more, and VibeDeploy registers and renews one year at a time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedOutput schema / properties / alternatives / items / properties / unavailableReason
      Added value: +{
      +  "description": "Set when the registrar lists the name as free but VibeDeploy cannot register it. MULTI_YEAR_ONLY: this extension is only sold for two years or more, and VibeDeploy registers and renews one year at a time.",
      +  "type": "string"
      +}
    • changedOutput schema / properties / available / description
      Previous value: -"Whether the domain can be registered right now."New value: +"Whether the domain can be registered through VibeDeploy right now."
    • addedOutput schema / properties / ownDomain
      Added value: +{
      +  "description": "How a domain the user already owns is connected instead.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / purchase
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Whether and where the user can buy a domain through VibeDeploy.",
      +  "properties": {
      +    "allowedOnPlan": {
      +      "description": "Whether the user's current plan includes buying domains through VibeDeploy.",
      +      "type": "boolean"
      +    },
      +    "dashboardUrl": {
      +      "description": "Dashboard page where the user buys domains. Buying always happens there, never through this tool.",
      +      "type": "string"
      +    },
      +    "reason": {
      +      "description": "Neutral statement of why buying is not possible. Present only when allowedOnPlan is false.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "allowedOnPlan",
      +    "dashboardUrl"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / unavailableReason
      Added value: +{
      +  "description": "Set when the registrar lists the name as free but VibeDeploy cannot register it. MULTI_YEAR_ONLY: this extension is only sold for two years or more, and VibeDeploy registers and renews one year at a time.",
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "available",
      -  "domain",
      -  "priceCents",
      -  "currency",
      -  "note"
      -]New value: +[
      +  "available",
      +  "domain",
      +  "priceCents",
      +  "currency",
      +  "note",
      +  "purchase",
      +  "ownDomain"
      +]
  2. Changed3 schema fields changed
    • changedOutput schema / properties / alternatives / items / properties / priceCents / description
      Previous value: -"Gross (incl. 21% VAT) indicative price in cents, or null if pricing/availability lookup failed."New value: +"Indicative price in cents (VAT included where it applies), or null if the lookup failed."
    • changedOutput schema / properties / note / description
      Previous value: -"Reminder that this is an indicative gross price and not a purchase."New value: +"Reminder that the price is indicative and nothing was bought."
    • changedOutput schema / properties / priceCents / description
      Previous value: -"Gross (incl. 21% VAT) indicative retail price in cents, or null if unavailable / no price is published."New value: +"Indicative price in cents (VAT included where it applies), or null when no price is published."
  3. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
      -  "description": "Server-assigned request correlation id. Quote it when contacting support.",
      -  "type": "string"
      -}
  4. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
      +  "description": "Server-assigned request correlation id. Quote it when contacting support.",
      +  "type": "string"
      +}
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, but the description adds non-redundant behavior: it never buys, registers or reserves; prices include VAT where applicable; alternatives expands to a fixed TLD list; and the response reveals whether the user's plan permits domain purchase (purchase.dashboardUrl). This is more than the annotations cover.

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?

Front-loads the purpose, then disambiguates with the read-only note and the alternatives scope. Slightly dense with four clauses, but every sentence carries information (safety, scope, cross-selling to add_custom_domain) rather than restating the title.

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?

For a two-parameter read-only lookup with a full output schema and rich annotations, nothing an agent needs is missing: cost basis (VAT), scope (single vs canonical TLD set), safety profile, and the follow-up path for already-owned domains are all stated.

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 coverage is 100% and both parameters are fully documented in the schema, so the description's parallel explanation of 'alternatives:true' and the domain string adds no new syntax or format detail. Baseline 3 is appropriate since the schema carries the parameter burden.

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?

States a specific verb and resource ('check whether a domain can be registered') plus the secondary output ('indicative price'), which uniquely distinguishes it from siblings like add_custom_domain or list_custom_domains. An agent can identify this as the only pre-purchase lookup tool without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use context ('Not tied to a site'), explicitly rules out the mutation path ('Read-only: it never buys, registers or reserves'), and routes the owned-domain case to the sibling add_custom_domain. It also explains when to set alternatives:true, which is the only real decision point in the call.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.