Skip to main content
Glama
Sign In
Unique Domains MCP server

Unique Domains MCP server

Official
by UniqueDomains
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

A word's endings as stored on the latest day

ud_get_word_endings
Read-onlyIdempotent

Retrieve a word's latest stored endings, counts, key endings, and open names per ending to see which domain extensions remain available for that word, such as harbor.ai or harbor.io.

Instructions

A word's endings as stored on the latest day: counts, the key endings and the open names per ending. Use it when someone has a word and asks which endings are still open for it, such as harbor.ai or harbor.io. Pass word (such as harbor); 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": {
      "word": "<word>"
    },
    "name": "ud_get_word_endings"
  }
}

Input Schema

NameRequiredDescriptionDefault
wordYesThe catalog slug, the word, or `wrd_<id>`.
fieldsNoComma-separated top-level keys to keep: byGroup, keyEndings, openByEnding, cheapest.

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.6/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 closed-world scope, so the safety profile needs no restating. The description adds one genuinely useful behavioral nuance — the data is a snapshot 'as stored on the latest day' — but says nothing about staleness limits, result size, or ordering beyond what the output schema already defines.

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-loaded: what the tool returns comes first, then the when-to-use condition, then the input note. It is efficiently sized, with only minor redundancy in restating the title's 'as stored on the latest day' phrasing in the opening clause.

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?

With an output schema present and full parameter coverage, the description only needs to convey purpose, triggering context, and the snapshot nature of the data, all of which it does. Nothing essential for a correct call is missing, though a note on whether the word must exist or how resolution failures behave would round it out.

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 both `word` and `fields` are already documented, including the accepted slug/`wrd_<id>` forms and the valid top-level keys. The description only reinforces required-vs-optional and repeats the returned key names, adding little meaning beyond the schema; baseline 3 applies.

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 the resource and its contents explicitly: a word's endings on the latest day, with counts, key endings, and open names per ending. It is clearly a read of a word-scoped ending report, distinct from the sales/market/domain siblings, though it never names an alternative tool to disambiguate further.

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 gives a concrete triggering scenario — 'someone has a word and asks which endings are still open for it' — with examples (harbor.ai, harbor.io) that make the intent unambiguous. There are no explicit exclusions or pointers to sibling tools for adjacent questions (e.g. market sales for a word), so it stops short of full routing guidance.

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