Skip to main content
Glama

combell_domains_register

Register an available domain name and purchase it, providing registrant details. The operation runs in the background and returns a provisioning job to track progress.

Instructions

Register an available domain name. SIDE EFFECT: this purchases a domain name and incurs costs. Registration runs in the background (202 Accepted); check the returned provisioning job. '.ca' domains are only available for registrants with country code 'CA'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
registrantYes
domain_nameYesDomain part and TLD only, e.g. 'example.be'
name_serversNoName servers; leave empty to use Combell's default name servers

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

The description prominently discloses that this purchases a domain and incurs costs, that execution is asynchronous with a 202 response, and that a provisioning job must be checked. These are critical behavioral traits beyond the minimal annotations (readOnlyHint=false, idempotentHint=false) and materially help an agent handle side effects.

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?

Three tight sentences front-load the action and side-effect warning before the async and TLD notes. No sentence is wasted, and critical warnings appear before less urgent details.

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

Completeness4/5

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

For a purchase operation with no output schema, the description covers the essential behavioral context: cost, asynchronous 202 handling, and a TLD eligibility rule. It doesn't spell out the polling contract or explicitly point to combell_provisioning_jobs_get, but 'check the returned provisioning job' gives a sufficient starting point.

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

Parameters4/5

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

The description adds a registrant country_code constraint ('.ca' only for country code 'CA') not present in the input schema, and the term 'available' conditions the domain_name parameter. With 67% schema coverage, the schema already documents most field semantics, so the description's extra constraint is meaningful but not exhaustive.

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 says 'Register an available domain name', which is a specific verb and resource that clearly identifies the action. It distinguishes from sibling operations like combell_domains_transfer and combell_domains_list without ambiguity.

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?

It clearly indicates this is for newly available domain registrations and states the '.ca' country-code restriction. It doesn't explicitly name alternative tools for transfers or renewals, but the domain registration vs transfer/list distinction is clear from the wording and sibling names.

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