Skip to main content
Glama
Sign In

Unique Domains

by domains.unique
OverviewDiscussionsAdmin

Stored answer for one domain name

ud_get_name
Read-onlyIdempotent

The stored answer for one domain name: status, drop day, price today, registry facts, word facts and similar sales. Pass name (such as get.plumbing).

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": {
      "name": "<name>"
    },
    "name": "ud_get_name"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesA full domain name on an ending the catalog holds, lowercased, IDN as punycode. A bare word, a subdomain, an e-mail address or an unknown ending answers 400 `validation_failed` with `reason` and `suggestion`.
fieldsNoComma-separated top-level keys to keep: id, name, ending, tracked, status, lifecycle, drop, ownableNow, price, registry, parking, length, format, shape, word, rating, verdict, value, comps.

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 observed

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds only the word 'stored', which hints that this returns a precomputed snapshot rather than a live lookup, but it never states freshness or staleness semantics even though a ud_get_meta_freshness sibling exists. That single word is useful context, not a full behavioral picture.

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?

Two tight sentences with no waste: the return contents are front-loaded before the calling instruction. Every clause earns its place, and nothing is buried behind preamble.

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, the description need not explain return values, and it correctly omits that. It covers the required parameter and the payload breadth, but leaves the two gaps an agent would actually hit: how this differs from the similarly named ud_get_domain, and what 'stored' means for data recency.

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%, and the schema already spells out the lowercase/punycode format and the 400 validation_failed behavior with reason and suggestion. The description's only addition is the inline example 'get.plumbing', which is a modest format illustration rather than new meaning. Baseline 3 applies because the schema carries the load.

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 specific resource (one domain name) and enumerates its contents: status, drop day, price today, registry facts, word facts and similar sales. That enumeration implies an aggregate superset of narrower siblings like ud_get_name_comps and ud_get_name_registry, but it never explicitly contrasts itself with ud_get_domain, so the differentiation is inferential rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: by listing every content category, it signals 'reach for this when you want the full picture on one name.' There is no explicit when-to-use, no when-not-to-use, and no named alternative for the case where the agent only needs comps or registry data. The agent must reason from the content list rather than being routed.

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

All Unique Domains toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources