Scopeweb

check_live

Read-onlyIdempotent

Checks up to 10 domains against the registry in real time (RDAP) and reports whether each is registered right now. For confirming availability just before a recommendation or purchase decision, and for any name an earlier answer marked 'unknown', 'pending' or 'unprobed', which are never registration claims. It answers whether a registration exists, not whether the name can be bought or at what price: reserved and premium names also read as unregistered here. It does not judge whether a name is good, and it does not fetch the site, so it reports 'registered' rather than 'active' or 'dormant'. Read-only. Cannot spend money.

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": {
      "domains": "<domains>"
    },
    "name": "check_live"
  }
}

Input Schema

Name	Required	Description	Default
`domains`	Yes

Output Schema

Name	Required	Description	Default
`results`	Yes	One row per domain asked about, with its verdict and evidence grade.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "description": "One row per domain asked about, with its verdict and evidence grade.",
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}

First observedSep 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds genuinely new behavioral facts: a hard batch ceiling of 10 domains, real-time RDAP lookups, and the important caveat that reserved and premium names read as unregistered, so 'unregistered' is not equivalent to 'available'. It also distinguishes 'registered' from 'active'/'dormant' since no site fetch occurs, and notes it cannot spend money.

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 action and the batch limit in the first sentence, and every subsequent sentence carries distinct routing information. The block of three consecutive negative-scope sentences ('not whether it can be bought', 'does not judge', 'does not fetch') is slightly repetitive and could be tightened, but nothing is truly wasted.

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?

An output schema exists, so return-value shape needs no explanation, and the description instead covers the semantics an agent actually needs: what 'registered' means, what it does not mean, batch limits, and freshness (real-time RDAP). Nothing required to call this correctly 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 0% and the single `domains` array is undocumented in the schema, so the description must carry the load — it does supply the key operational constraint (up to 10 entries). It stops short of specifying the expected string format (bare domain vs. URL) or behavior when more than 10 are passed, leaving a small gap.

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 (checks) and resource (domains against the registry via RDAP) with explicit scope: up to 10 domains, real-time, returns registered/unregistered. It also carves out exactly what it is not — not a buyability/price check (that's quote_domain), not a quality judgement (score_name), not a liveness fetch (fetch) — so an agent can route without opening the schema.

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 explicit when-to-use: just before a recommendation or purchase decision, and for any name a prior answer marked 'unknown', 'pending' or 'unprobed'. It also states when-not: it answers registration existence only, not purchasability or price, and it does not judge name quality. Alternatives are implicitly named by disowning those jobs.

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

All Scopeweb tools Inspect

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

Need Help?