Scopeweb

check_live

Read-onlyIdempotent

⛔ THE LAST GATE, NOT THE FIRST STEP. Use this to CONFIRM a name immediately before acting on it, after suggest_names has generated candidates and score_name has ranked them. It answers only 'is this registered', and it will answer just as confidently for a list you invented as for one this service helped you build -- so a clean result here says nothing about whether the name is any good, or whether a better one sits next to it. If none of the names you pass have been seen by suggest_names or scan_namespace, the response says so and points you back. Use this immediately before you recommend buying anything, and any time an earlier answer said 'unknown', 'pending' or 'unprobed'. Those are never registration claims. Real-time authoritative registration check for up to 10 domains via RDAP. Read-only. Cannot spend money. This is the final gate before recommending a purchase — never rely on cached or older scan results for buying decisions. It answers whether a registration EXISTS, not whether the name can be bought or at what price: reserved and premium names return 404 here too. Registration-only: it does not fetch the site, so it returns 'registered' rather than 'active' or 'dormant'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`domains`	Yes

Output Schema

TableJSON 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.4/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: 10-domain cap, RDAP-backed real-time authority, 404 also returned for reserved/premium names, and that it returns 'registered' rather than 'active'/'dormant' because it does not fetch the site. It even warns the result is registration-only and says nothing about quality. Strong, though return-format detail partially duplicates the output schema.

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 critical rule is front-loaded in the first line and the ordering constraint follows immediately, which is good structure. However it is long and repeats the 'final gate before recommending a purchase' idea twice and restates the registration-only scope in two separate sentences, which could be trimmed.

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?

For a single-parameter read-only check with an output schema, the description covers everything an agent needs: ordering relative to siblings, the 10-domain limit, what the result does and does not mean, and how edge cases (reserved/premium, unvetted names) behave.

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 0% for the single domains parameter, so the description must compensate. It adds a real constraint the schema lacks ('up to 10 domains') but never clarifies the expected string format (bare name vs. FQDN, whether a TLD is required), leaving the one parameter partially specified.

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+resource+method: 'Real-time authoritative registration check for up to 10 domains via RDAP', and explicitly distinguishes it from siblings by naming suggest_names and score_name as the prior steps. The 'answers only is this registered' framing nails the exact scope.

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?

Explicit when-to-use ('immediately before you recommend buying anything', 'any time an earlier answer said unknown/pending/unprobed'), when-not-to-use ('THE LAST GATE, NOT THE FIRST STEP', not before suggest_names/score_name), and what to do instead if names were not vetted. Routing is fully specified.

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?