Skip to main content
Glama
Sign In
Unique Domains MCP server

Unique Domains MCP server

Official
by UniqueDomains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Every root TLD with its registry facts and launch phases

ud_list_tlds
Read-onlyIdempotent

Browse root TLDs with registry facts and launch phases, filtered by type, country, status, or IDN/brand flags. Returns paginated results one page at a time using an optional limit and cursor.

Instructions

Every root TLD with its registry facts and launch phases, alphabetical. Use it when someone wants to browse endings by type, country or status; it answers one page at a time. Every input is optional; limit sets the page size.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ud_list_tlds"
  }
}

Input Schema

NameRequiredDescriptionDefault
isIdnNoInternationalised endings only (`true`) or none (`false`).
limitNoPage size, 20 at most.
cursorNoThe `meta.cursor` of the previous page.
fieldsNoComma-separated top-level keys to keep: tld, slug, ianaStatus, kind, ianaType, registryOperator, registryCountryCode, isBrand, isIdn, delegatedOn, removedOn, contractTerminated, rdapServer, category, phases, insights.
countryNoThe registry operator's country, ISO 3166-1 alpha-2.
isBrandNoBrand TLDs only (`true`) or none (`false`).
ianaTypeNoIANA's own type word (`generic`, `country-code`, `sponsored`, `infrastructure`).
publicSetNo`true`: the public set only (v1's `listing=public`).
ianaStatusNoIANA root zone status.

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNoThe day of the answer, and the page cursor of a list.
linksNoLinks of the answer.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds behavior beyond that: results are alphabetical and paginated ('answers one page at a time'), which tells the agent to expect cursor-driven paging. It doesn't mention result volume or how cursor interacts with filters, but the pagination disclosure is the important extra.

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?

Three short sentences with the identity of the tool front-loaded and pagination and optionality following. Nothing is padded, though the phrase 'Every input is optional; limit sets the page size' is largely redundant with the schema.

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?

An output schema exists, so return values need not be described, and annotations cover the safety and side-effect profile. The description supplies the remaining essentials an agent needs: what the collection is, what facets it can be browsed by, and that responses are paginated.

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%, so every one of the nine parameters is already documented in the schema. The description only restates that all inputs are optional and that 'limit' sets page size, which duplicates the schema's default and maximum. Baseline 3 is appropriate since the schema carries the semantics.

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 names a specific resource and scope ('Every root TLD with its registry facts and launch phases, alphabetical'), so an agent knows this returns a full TLD catalog with phases rather than a single record. It does not name a sibling to contrast with, and the 'browse endings by type, country or status' framing is the only hint at how it differs from narrower listers like ud_list_tld_phases.

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 condition 'Use it when someone wants to browse endings by type, country or status' gives a clear trigger for reaching for this tool. There is no explicit when-not or named alternative, so an agent must infer that ud_get_tld or ud_list_tld_phases serve different needs.

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