Skip to main content
Glama

Domain age and registrar

domain_registration
Read-onlyIdempotent

Domain registration only, for 1-10 domains, from the official RDAP registries. Use this when you need to spot newly registered (possibly risky) domains, check who a domain is registered with, or find upcoming expiries. The fastest and cheapest tool here; no DNS, email or website checks (use domain_report for everything). Input: domains (1-10 domains, URLs or email addresses). Returns results[] with, per domain: registration (registrar, created, updated and expiry dates, age in days, status codes), errors, analyzedAt and cached. Limits: each domain counts as one lookup; answers cached for 1 hour per domain; 25 free domains a day per IP without a key, more with a paid key in the x-api-key header. Read-only: nothing is stored, no email is sent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainsYes1-10 domains, website URLs or email addresses (the domain part is used)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / domains / description
      Previous value: -"1-10 domains, URLs or email addresses, e.g. [\"example.com\"]"New value: +"1-10 domains, website URLs or email addresses (the domain part is used)"
    • addedInput schema / properties / domains / examples
      Added value: +[
      +  [
      +    "stripe.com",
      +    "example.com"
      +  ]
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / domains / description
      Added value: +"1-10 domains, URLs or email addresses, e.g. [\"example.com\"]"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: cost model (each domain counts as one lookup), 1-hour per-domain caching, 25 free lookups/day per IP, x-api-key auth for higher limits, and explicit 'nothing is stored, no email is sent'.

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 purpose and routing, then input, returns, and limits in a logical order. Dense but nearly every clause carries usable information; the return-value detail is justified because there is no output schema.

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 no output schema and no nested parameters, the description fully compensates by enumerating the results[] fields (registrar, created/updated/expiry dates, age in days, status codes, errors, analyzedAt, cached), plus rate limits and auth requirements. An agent has everything needed to call it correctly.

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 the domains array, its 1-10 bounds, and that URLs/emails have their domain part extracted. The description restates this and adds only the cost-per-domain framing, so the baseline 3 applies.

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?

States a specific verb and resource ('Domain registration only... from the official RDAP registries') and immediately distinguishes itself from siblings by ruling out DNS, email and website checks and naming domain_report as the catch-all alternative.

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

Usage Guidelines5/5

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

Gives three concrete use cases (spotting newly registered risky domains, checking registrar, finding upcoming expiries) and an explicit exclusion with a redirect ('use domain_report for everything'). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources