Skip to main content
Glama
Unique Domains MCP server

Unique Domains MCP server

Official

Ending's public registry changes, newest first

ud_list_tld_changes
Read-onlyIdempotent

List public registry changes for a specific TLD in reverse chronological order, so you can answer questions about what changed at that ending's registry recently.

Instructions

The ending's public registry changes, newest first. Use it when someone asks what changed at an ending's registry lately. Pass tld (such as ai); the other inputs are optional.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tld": "<tld>"
    },
    "name": "ud_list_tld_changes"
  }
}

Input Schema

NameRequiredDescriptionDefault
tldYesThe ending without the dot (`ai`), ASCII or `xn--` form; lowercased, a leading dot stripped.
limitNoPage size, 20 at most.
cursorNoThe `meta.cursor` of the previous page.
fieldsNoComma-separated top-level keys to keep: kind, after, seenOn.

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

A3.8/5.0
Behavior3/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 fully covered elsewhere. The description's main addition is 'newest first' ordering, which is near-duplicated in the title annotation, and a vague note that other inputs are optional; it says nothing about coverage window, rate limits, or freshness lag.

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 resource and ordering front-loaded and no filler. The final sentence partly restates what the schema's required/optional flags already communicate, keeping it just below maximum.

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?

With full schema coverage, an output schema, and rich annotations, the remaining job for the description is purpose and trigger, both of which are supplied. An agent can call this correctly without additional prose.

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 the schema already documents tld normalization, the 20-item page cap, the cursor source, and the fields filter. The description only adds an example value ('such as ai') and the note that non-tld inputs are optional, which is marginal value over the schema.

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 ('public registry changes' for an 'ending' / TLD) and states the ordering ('newest first'), which is enough to distinguish it from generic change-listing tools. It does not, however, differentiate itself from the closely named sibling ud_list_tld_application_changes, so an agent must infer the boundary.

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?

'Use it when someone asks what changed at an ending's registry lately' gives a clear triggering context. There are no explicit exclusions or pointers to alternative change feeds (application changes, price changes, registrar changes), which keeps it short of a 5.

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