Which integrations are available for this server?

Generates fast checkout deep-links that open Namecheap with the target .si domain pre-selected for immediate cart addition, bypassing homepage search lag. Generates fast checkout deep-links that open Porkbun with the target .si domain pre-selected for immediate cart addition, bypassing homepage search lag. Generates fast checkout deep-links that open Spaceship with the target .si domain pre-selected for immediate cart addition, bypassing homepage search lag.

How do I use mcp-si-radar?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-si-radar check if compute.si is available" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-si-radar

by tudadada

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

mcp-si-radar

Authoritative Registry Socket Scanner, Real-Time Availability Checker, GEMINI Rule 10 Evaluator & Instant Checkout Generator for .si (Slovenia) ccTLDs.

npm version License: MIT

📌 Problem & Technical Architecture

1. Common Bottlenecks in `.si` Domain Acquisition

Registrar Search Lag: Web interfaces of major registrars (Dynadot, Spaceship, Namecheap) frequently hang, show infinite loading spinners, or rate-limit users when searching for .si domains because of multi-TLD suggestions, marketplace calls, and heavy frontend bundles.
Anti-Bot Roadblocks: Aggressive Cloudflare Turnstile, CAPTCHAs, and session timeouts disrupt research and domain acquisition workflows.
Cart Flow Friction: Adding domains through a web search bar re-triggers redundant checks and upsell popups that slow down domain registration.

2. The `mcp-si-radar` Solution

Direct Socket Connection to ARNES Registry (Port 43):
- Connects directly via raw TCP socket to whois.register.si:43 (the sovereign national registry of Slovenia).
- Blazing-fast response time (~50ms – 200ms).
- 100% real-time authoritative accuracy, bypassing all web proxies, CDN queues, and CAPTCHAs.
Pacing Delay Engine (Batch Scanning):
- Automatically paces sequential queries (default 350ms) to ensure ARNES firewall never rate-limits or blocks your IP.
Fast Checkout Deep-Links:
- Generates clean direct URLs that open registrars with the target domain pre-selected and an immediate "Add to Cart" button, bypassing homepage search lag.
Automated Headless API Registration:
- Direct integration with Dynadot REST API (api.dynadot.com/api3.json) for zero-click purchases right from the AI chat window.
GEMINI Rule 10 Discipline ("Two-Reading Rule"):
- Automatically scores Reading A (Domestic Slovenian Real-Economy Baseline) and Reading B (Superintelligence Option Value).
- Delivers actionable verdicts: 🟢 HOLD (ACQUIRE), 🟡 OPTIONAL (SPECULATIVE), or 🔴 AVOID (HIGH RISK) to prevent portfolio dilution.

Related MCP server: Domain Checker

🛠️ MCP Tools Reference

Tool Name	Description
`si_check_domain`	Real-time availability query via ARNES socket port 43. Returns registration status, socket latency, registrar details, expiry, fast checkout links, and Rule 10 evaluation.
`si_batch_check`	Scans a list of candidate `.si` keywords with an intelligent pacing delay to prevent registry throttling. Separates available vs registered domains.
`si_fast_checkout`	Generates instant deep-links to pre-fill shopping carts across Dynadot, Spaceship, Namecheap, and Porkbun.
`si_evaluate_rule10`	Evaluates `.si` domains under GEMINI Rule 10 (Slovenian Baseline Salary vs Superintelligence Lottery Ticket).
`si_api_register`	Executes instant automated domain purchase via Dynadot API (requires `DYNADOT_API_KEY` in `.env`).

🚀 Installation & Configuration

1. Global / Project MCP Configuration

Add mcp-si-radar to your MCP configuration file (mcp_config.json or claude_desktop_config.json):

{
  "mcpServers": {
    "mcp-si-radar": {
      "command": "npx",
      "args": ["-y", "mcp-si-radar"],
      "env": {
        "DYNADOT_API_KEY": ""
      }
    }
  }
}

Or run directly from local source:

{
  "mcpServers": {
    "mcp-si-radar": {
      "command": "node",
      "args": ["/path/to/mcp-si-radar/index.js"]
    }
  }
}

2. Optional Environment Variables

In your project .env:

# Optional: Enables zero-click automated purchases via si_api_register
DYNADOT_API_KEY=your_dynadot_api_key_here

📋 Example Usage

Single Domain Check

{
  "name": "si_check_domain",
  "arguments": {
    "domain": "compute.si"
  }
}

Sample Response:

{
  "domain": "compute.si",
  "available": false,
  "status": "REGISTERED",
  "latency_ms": 118,
  "details": {
    "registrar": "Dynadot Inc",
    "status": "ok",
    "created": "2026-09-20",
    "expire": "2027-09-20"
  },
  "rule_10_assessment": {
    "reading_A": {
      "concept": "Territory / Slovenian Real Economy (BASELINE SALARY)",
      "score": "1/3",
      "analysis": "Universal tech and cloud compute term applicable to Slovenian data centers."
    },
    "reading_B": {
      "concept": "Domain Hack: [Word] + Superintelligence (OPTION VALUE)",
      "score": "2/3",
      "analysis": "Natural semantic synergy with Superintelligence compute clusters."
    },
    "verdict": "🟡 OPTIONAL (SPECULATIVE)"
  }
}

Batch Scanning

{
  "name": "si_batch_check",
  "arguments": {
    "domains": ["compute", "piloting", "kinging", "nuclear", "safe.si"],
    "delay_ms": 350
  }
}

👤 Author & Support

Author: Tu Da (Founder & Research Lead | Dot The World)
Website: https://dottheworld.com
Email: ceo@dottheworld.com

📄 License

MIT © Tu Da (Dot The World) ceo@dottheworld.com

Available Tools

5 tools

si_api_registerA

Automated headless domain registration via Dynadot API (requires DYNADOT_API_KEY in .env). Purchases directly without opening a browser.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Domain name to register immediately (e.g. 'kinging.si')
`duration_years`	No	Registration period in years (default 1 year)

TDQS

A3.8/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 and does flag the two most important traits: this immediately commits a purchase and requires an API key. It stops short of cost, irreversibility/refund behavior, or what happens if the domain is unavailable, which matters for a financial mutation.

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?

One tight sentence that front-loads the mechanism and the purchase consequence. No filler; the parenthetical is the only extra and it carries real setup information.

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?

For a 2-parameter tool with no output schema, the description covers the essentials an agent needs: what it does, that it spends money immediately, and the auth prerequisite. A note on prerequisites like confirming availability first would make it fully complete.

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 both parameters are documented there (including the example 'kinging.si' and the 1-year default). The description adds no parameter-level meaning beyond the schema, 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 (register/purchase) and resource (domain) plus the mechanism (Dynadot API, headless). 'Purchases directly without opening a browser' cleanly separates it from sibling check tools like si_check_domain and si_batch_check.

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?

It discloses the prerequisite (DYNADOT_API_KEY in .env) and implies the headless-vs-browser distinction, but never states when to prefer this over siblings such as si_fast_checkout, nor whether availability must be verified first. Usage is only implied.

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

si_batch_checkA

Batch scan a list of .si candidate domains with an intelligent pacing delay to prevent ARNES registry IP blocking. Returns structured lists of available vs registered domains with direct registration links.

ParametersJSON Schema

Name	Required	Description	Default
`domains`	Yes	Array of .si domain keywords to scan (e.g. ['kinging', 'compute', 'nuclear', 'safe.si'])
`delay_ms`	No	Pacing delay between socket queries in milliseconds to protect IP from ARNES rate-limiting. Default is 350ms.

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does add non-obvious behavioral context: the built-in pacing delay to avoid ARNES rate-limiting/IP blocking, and the shape of the result (available vs registered lists with registration links). It does not state permissions or whether the scan is purely read-only.

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?

Two sentences, front-loaded with the core action, then the return shape. The phrase 'intelligent pacing delay' is slightly promotional but does convey the rate-limit motive without wasting much space.

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?

No output schema exists, so the description usefully describes the return value (available vs registered lists plus registration links), and both parameters are covered. Missing only auth/permission context for what is a registry-querying operation.

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 both parameters are already documented in the schema with defaults and examples. The description only restates the domain list concept and the pacing purpose, adding no syntax or format detail beyond the schema.

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: batch-scanning a list of .si candidate domains. The word 'Batch' implicitly distinguishes it from the single-domain sibling si_check_domain, but the description never names the alternative or states the contrast explicitly.

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

Usage Guidelines2/5

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

No when-to-use guidance, no conditions for choosing this over si_check_domain or si_fast_checkout, and no prerequisites. The pacing rationale explains a behavior, not when the agent should pick this tool.

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

si_check_domainB

Authoritative real-time availability check for .si domains via direct raw socket connection to ARNES port 43 (whois.register.si). Completely bypasses registrar web bloat, Cloudflare queues, and CAPTCHAs. Includes instant checkout links and GEMINI Rule 10 two-reading evaluation.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Target .si domain name to inspect (e.g. 'kinging.si', 'compute.si', or simply 'kinging')

TDQS

B3.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so reasonably: it names the upstream (ARNES whois port 43), the transport (raw socket), what is bypassed (Cloudflare queues, CAPTCHAs), and what is returned (availability plus checkout links and a Rule 10 evaluation). It omits rate limits, failure modes, and does not explicitly confirm the read-only/no-auth nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One long sentence that is appropriately front-loaded with the core purpose, but the middle clause about 'registrar web bloat, Cloudflare queues, and CAPTCHAs' is promotional filler that displaces more useful routing or behavioral information.

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?

For a single-parameter tool with no output schema, the description gives enough to call it and hints at the return payload (availability, checkout links, rule 10 reading). However, it never resolves how it relates to the similarly named checkout and rule-10 sibling tools, leaving ambiguity about whether calling this redundantly triggers that logic.

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% and the single 'domain' parameter is already documented with examples in the schema, including the 'kinging' shorthand. The description adds no syntax, format, or normalization details beyond that, so the baseline 3 applies.

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: a real-time availability check for .si domains via whois (ARNES port 43). It does not differentiate from the sibling si_batch_check, so an agent must infer that this handles a single domain from the one-param schema.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance or comparison to si_batch_check, si_fast_checkout, si_evaluate_rule10, or si_api_register. The claim that it 'includes instant checkout links and GEMINI Rule 10 two-reading evaluation' actually muddies routing, since dedicated siblings appear to exist for exactly those concerns.

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

si_evaluate_rule10B

Evaluates a .si domain against GEMINI Rule 10 (Two-Reading Rule: Slovenian Real Economy Baseline vs Superintelligence Option Value). Returns actionable verdict: HOLD / OPTIONAL / AVOID.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	The .si domain to evaluate (e.g. 'compute.si', 'piloting.si', 'kinging.si')

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose the behavioral output shape by naming the three verdict categories, which is genuine value, but it omits any note on determinism, cost, permissions, or what the underlying rule actually evaluates.

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 the action front-loaded and the return contract stated second. No filler, no repetition of the tool name.

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 must carry the return contract, and it does name the verdicts and the rule applied. However, it never explains what distinguishes HOLD from OPTIONAL from AVOID, leaving an agent unable to interpret or act on the result without more context.

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?

Only one parameter, and schema description coverage is 100%, so the schema already documents the domain argument with examples. The description adds no syntax, format, or case-sensitivity detail beyond what the schema provides, making 3 (baseline) appropriate.

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?

Uses a specific verb (evaluates) on a specific resource (.si domain) under a named rule, and the verdict enumeration (HOLD/OPTIONAL/AVOID) makes the output tangible. It reads as distinct from siblings like si_check_domain or si_fast_checkout, though the proprietary 'GEMINI Rule 10' framing is opaque without external context.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus si_check_domain, si_fast_checkout, or si_batch_check, nor any precondition or exclusion. Usage must be inferred entirely from the name.

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

si_fast_checkoutB

Generates instant deep-links to registrar shopping carts/checkout pages (Dynadot, Spaceship, Namecheap, Porkbun), bypassing laggy web search bars.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Target .si domain name to purchase (e.g. 'kinging.si')

TDQS

B3.4/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. It discloses core behavior by saying it generates links rather than completing purchases, and adds 'instant' and bypasses search bars. However, it does not state whether the operation is read-only, requires auth, or has side effects.

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?

The description is a single, front-loaded sentence with no wasted words. Every clause contributes: the verb, the resource, the supported registrars, and the key benefit.

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?

For a simple one-parameter tool with full schema coverage and no output schema, the description adequately explains what it generates and for which registrars. It does not mention the .si domain context (left to the schema) or return cardinality, but these are minor gaps.

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 single required parameter ('domain') is well documented in the schema. The description adds no parameter-specific syntax or format details beyond what the schema already provides, so the baseline of 3 applies.

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 ('Generates instant deep-links') and resource ('registrar shopping carts/checkout pages'), and names the target registrars. It distinguishes itself functionally from siblings like si_check_domain and si_api_register, but does not explicitly contrast with them.

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

Usage Guidelines2/5

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

No explicit when-to-use guidance or alternatives are provided. The phrase 'bypassing laggy web search bars' hints at a use case, but there is no comparison to sibling tools such as si_api_register or si_check_domain.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.2Sep 30, 2026
- First observedsi_api_register
- First observedsi_batch_check
- First observedsi_check_domain
- First observedsi_evaluate_rule10
- First observedsi_fast_checkout

Deploy Server

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

TDQS

A3.6/5.0

Scored 2026-09-30 17:50 across 5 tools

Disambiguation3/5

si_batch_check vs si_check_domain are clearly distinguishable (batch vs single), but si_check_domain's description says it also returns checkout links and Rule 10 evaluation, making it a superset that overlaps with si_fast_checkout and si_evaluate_rule10. An agent would struggle to know when to call the specialized tools versus just using si_check_domain.

Naming Consistency4/5

All tools share a consistent si_ prefix and snake_case, with predictable verb/noun components (check, batch_check, fast_checkout, api_register, evaluate_rule10). Minor deviation in ordering (noun_verb vs verb_noun) but still readable and coherent.

Tool Count5/5

Five tools is well-scoped for a specialized .si domain availability and registration workflow. Each tool earns its place across checking, batch scanning, evaluation, checkout linking, and registration.

Completeness4/5

Covers the full lifecycle of find-check-evaluate-buy with single check, batch check, Rule 10 evaluation, checkout deep-links, and automated API registration. Minor gap: no post-registration management (renewal, transfer, DNS) or bulk registration.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Domain SentinelOAuth
com.domain-sentinel
Domain availability over RDAP, watchlists with daily checks, change history and email alerts.
Open Data
1
expired-domain-screenerOAuth
io.github.PrometheusAgency
Screen expired domains: availability, drop stage, history, brandability, trademark risk.
Search
2
DomainKits A
io.github.ABTdomain
Search newly registered, expired, aged, active, deleted and for-sale domains, plus WHOIS and DNS.
Search Web Scraping Security
3126
DomainCheckr A
io.github.nach-dakwale
Check domain name availability via RDAP. Single, bulk, and smart suggestions. No API key needed.
Search Web Scraping
32

Related MCP Servers

Domain Checker
Web Scraping Search Developer Tools
ahramadan44
F
license
Not graded
quality
D
maintenance
Enables checking domain name availability using WHOIS lookups and DNS resolution. Supports both single and batch domain checking with detailed availability analysis.
Updated a year ago (2025-09-23 13:33 UTC)
-
Domain Checker
Networking & Infrastructure
do-community
F
license
Not graded
quality
D
maintenance
Enables checking domain availability using WHOIS and DNS resolution, with support for single and batch queries.
Updated a year ago (2025-07-11 20:16 UTC)
29
-
FastDomainCheck MCP Server
bingal
A
license
A
quality
D
maintenance
Enables checking domain name availability for single or multiple domains using WHOIS and DNS verification.
Updated a year ago (2025-10-24 06:05 UTC)
1
21
MIT
Domain Availability MCP Server
Networking & Infrastructure Developer Tools
1shanra1
A
license
Not graded
quality
D
maintenance
Enables checking domain name availability for .com, .ai, and .net TLDs using WHOIS, DNS, and RDAP lookups.
Updated 8 months ago (2026-01-31 14:44 UTC)
MIT

mcp-si-radar

📌 Problem & Technical Architecture

1. Common Bottlenecks in .si Domain Acquisition

2. The mcp-si-radar Solution

🛠️ MCP Tools Reference

🚀 Installation & Configuration

1. Global / Project MCP Configuration

2. Optional Environment Variables

📋 Example Usage

Single Domain Check

Batch Scanning

👤 Author & Support

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. Common Bottlenecks in `.si` Domain Acquisition

2. The `mcp-si-radar` Solution