Skip to main content
Glama
1tylermitchell

Sairen

by 1tylermitchell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

whois_lookup

Retrieve structured WHOIS and RDAP domain intelligence: registration age, expiry, registrar, nameservers, DNSSEC, and privacy risk. Screen domains for fraud risk and critical age under 14 days.

Instructions

    [Cost: $0.0005 USDC on Base & Solana] Master domain dispatcher for Domain WHOIS & RDAP Intelligence Screener.
    Structured RDAP and WHOIS domain intelligence: registration age, expiry, registrar, nameservers, DNSSEC, and privacy shield risk analysis.

    Actions:
    - 'lookup': Full domain WHOIS & RDAP structured intelligence. Params: {"domain": "example.com"}
    - 'screen': Autonomous fraud risk & domain age vetting (<14 days = critical risk). Params: {"domain": "example.com"}
    - 'rdap': Raw RFC 9083 RDAP JSON entities. Params: {"domain": "example.com"}
    - 'status': Protocol capabilities and cache telemetry.

    Args:
        action: Target operation name ('lookup', 'screen', 'rdap', 'status').
        params: Optional dictionary of action parameters.
        payment_signature: Optional x402 Base USDC transaction hash (defaults to developer mock key).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNolookup
paramsNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context: the per-call cost, the optional payment signature defaulting to a developer mock key, and the risk threshold. However, it does not disclose whether the tool makes external network calls, how it handles payment failures, rate limits, or data freshness/caching behavior beyond a mention of 'cache telemetry'.

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?

The description is well-structured with a cost line, action list, and argument breakdown. It front-loads the core purpose and cost, then details actions and parameters. Some phrasing is slightly redundant (e.g., 'Master domain dispatcher' followed by 'Structured RDAP and WHOIS domain intelligence'), but overall the length is justified by the multi-action dispatcher design.

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?

The tool has no output schema and no annotations, so the description must explain both invocation and expected returns. It partially does: 'rdap' returns raw RFC 9083 JSON, 'status' returns protocol capabilities and cache telemetry, and 'lookup' returns structured intelligence. However, it lacks detail on the exact return shape for 'lookup' and 'screen', error behavior, and payment failure handling, leaving gaps for an agent.

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 description coverage is 0%, so the description must compensate. It does so by explaining the 'action' parameter's allowed values, providing example params objects for each action, and clarifying the payment_signature field's role and default. It does not fully specify the params object structure beyond the domain example, but it gives enough guidance for correct invocation.

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?

The description clearly identifies the tool as a domain WHOIS/RDAP intelligence dispatcher and enumerates four specific actions ('lookup', 'screen', 'rdap', 'status'), each with a concrete purpose. This makes the tool's function unambiguous and distinguishes it from the sibling tools, which cover broader web, blockchain, and infrastructure concerns.

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?

The description provides clear context for when to use the tool: domain WHOIS/RDAP lookups, fraud risk screening, and raw RDAP retrieval. The 'screen' action explicitly states a use case (domain age vetting with <14 days flagged as critical risk). However, it does not mention alternatives or when not to use the tool, so it stops short of full exclusion 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