Skip to main content
Glama
Sign In

SatsDNS

by com.satsdns
OverviewDiscussionsAdmin

Domain availability and price (free)

domain_check
Read-onlyIdempotent

Free: whether a domain name is available and its price in sats (offered TLDs and live 1-year prices per TLD: info, domains.tlds and domains.prices). Tightly rate-limited. If the answer carries a registry notice (tld_notice), show it to your user before they pay.

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

Input Schema

NameRequiredDescriptionDefault
yearsNoRegistration years to quote (default 1).
domainYesA name under an offered TLD (info: domains.tlds), e.g. example.com.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / domain / description
      Previous value: -"A .com, .net or .org name, e.g. example.com."New value: +"A name under an offered TLD (info: domains.tlds), e.g. example.com."
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, open-world status, so the description adds real value on top: it discloses tight rate limiting, that prices are live one-year prices in sats, and an operational obligation to surface any tld_notice to the user before payment.

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?

Very compact and front-loaded, leading with free availability and price. The parenthetical field references ('domains.tlds and domains.prices') are telegraphic and dense, but they convey required pointer information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of explaining returns, and it does partially: availability, sats price, and the tld_notice field. It omits any mention of error behavior or what an unavailable result looks like, and never positions itself against the sibling 'check' tool.

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 coverage is 100%, so both parameters are self-documented; the description only adds that the domain must sit under an offered TLD, referenceable via domains.tlds. It says nothing extra about the 'years' quote parameter, and 'live 1-year prices' sits slightly awkwardly beside a years field that allows up to 10.

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?

States a specific verb and resource: whether a domain is available plus its price in sats, with the TLD set scoped. An agent can distinguish it from mutating siblings like claim/order/renew, though it never explicitly contrasts with the ambiguous sibling 'check' or with 'info'.

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?

The word 'Free' plus 'before they pay' implies this is the pre-purchase lookup, and rate-limit pressure hints it should not be polled. But there is no explicit when-to-use/when-not statement and no named alternative (e.g., 'use info for already-registered domains').

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

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