Skip to main content
Glama
Sign In

NicheDB

by dev.nichedb
OverviewDiscussionsAdmin

check_domain

Read-onlyIdempotent

Is a domain name registered? Asks each registry over RDAP. Give name as a full name (foo.watches), or a bare word with tlds (foo + com,dev,io), or several names comma separated. Each answer is registered (with registrar and expiry), not_registered, or unknown. not_registered means the registry holds no registration; the name may still be reserved or premium, so it is not a promise that it is for sale. unknown (no RDAP server, a timeout, a 429) is never a yes. Each answer carries the cheapest known USD price for its ending.

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": "check_domain"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesA full name, a bare word with tlds, or names comma separated, e.g. foo.watches or a.com,b.dev
tldsNoEndings to try a bare word under, comma separated (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / name / description
      Previous value: -"foo.watches, or foo, or a.com,b.dev"New value: +"A full name, a bare word with tlds, or names comma separated, e.g. foo.watches or a.com,b.dev"
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the annotations (readOnly/openWorld/idempotent) by disclosing the lookup mechanism (per-registry RDAP), the failure modes that produce unknown (no RDAP server, timeout, 429), and the crucial caveat that not_registered does not mean purchasable because reservations and premium pricing exist. It also states that unknown 'is never a yes', which is exactly the kind of interpretation an agent needs.

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 with the core question, then input forms, then result semantics, then the pricing note. Every sentence carries information, though the result-semantics block is dense enough that a slightly tighter phrasing would read better.

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?

There is no output schema, so the description has to cover return values, and it does: registered with registrar and expiry, not_registered, or unknown, plus the per-answer cheapest USD price. Nothing essential for a correct call or correct interpretation of results is missing.

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?

Schema coverage is already 100%, so the baseline is 3. The description still adds value by explaining how name and tlds combine (bare word plus tlds expands to multiple queries) and by giving concrete examples, which the schema repeats more tersely.

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?

Opens with a specific question-form verb and resource: 'Is a domain name registered? Asks each registry over RDAP.' That names both the operation and the mechanism (RDAP), which distinguishes it from registry-metadata siblings like get_tld, search_tlds, and tld_changes.

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?

Explicitly describes the three accepted input shapes (full name, bare word plus tlds, comma-separated list) and what each result class means, which implies when to call it. It stops short of naming an alternative tool or stating exclusions, so it does not reach the when/when-not bar of a 5.

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

All NicheDB 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