Scopeweb

quote_domain

Read-only

Prices a name believed to be unregistered and returns total_cents, renewal_cents, an expiry and a confirm_url. For when the user has chosen a name and wants the real price. It re-runs the registry check first: a registered name, or one whose status cannot be confirmed, is not quoted. Premium names are quoted at their real price or refused, never at the base rate. An expired quote is re-quoted, never honoured. The confirm_url is not a purchase: it opens a page where a person types the domain to authorise the charge, and no tool in this server completes an order. Cannot spend money. PRICES ARE IDENTICAL FOR ALL BUYERS REGARDLESS OF BUDGET: passing a project_id adds budget context (does it fit, what is left after) and never changes the number.

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": {
      "domain": "<domain>"
    },
    "name": "quote_domain"
  }
}

Input Schema

Name	Required	Description	Default
`domain`	Yes	The name to price, e.g. 'stoff.fit'.
`project_id`	No	Optional. Adds budget CONTEXT to the answer (does it fit, what is left after). It never changes the price.

Output Schema

Name	Required	Description
`domain`	Yes
`message`	No
`contract`	No	Who may spend. An agent may not.
`quotable`	Yes	False means we will not sell it; read message and what_to_do.
`quote_id`	No
`what_to_do`	No
`confirm_url`	No	A page where a HUMAN completes the purchase. Not a purchase.
`quote_expires_at`	No
`annual_commitment_cents`	No	What it costs to KEEP, every year.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "annual_commitment_cents": {
+      "description": "What it costs to KEEP, every year.",
+      "type": "integer"
+    },
+    "confirm_url": {
+      "description": "A page where a HUMAN completes the purchase. Not a purchase.",
+      "type": "string"
+    },
+    "contract": {
+      "description": "Who may spend. An agent may not.",
+      "type": "string"
+    },
+    "domain": {
+      "type": "string"
+    },
+    "message": {
+      "type": "string"
+    },
+    "quotable": {
+      "description": "False means we will not sell it; read message and what_to_do.",
+      "type": "boolean"
+    },
+    "quote_expires_at": {
+      "type": "integer"
+    },
+    "quote_id": {
+      "type": "string"
+    },
+    "what_to_do": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "domain",
+    "quotable"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 5, 2026

addedInput schema / properties / domain / description

Added value: +"The name to price, e.g. 'stoff.fit'."

addedInput schema / properties / project_id

Added value: +{
+  "description": "Optional. Adds budget CONTEXT to the answer (does it fit, what is left after). It never changes the price.",
+  "type": "string"
+}

First observedSep 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations: it discloses that premium names are quoted at real price or refused, that expired quotes are never honoured (explaining the idempotentHint=false), that confirm_url is a human-authorised page rather than a purchase, and that the tool 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?

Purpose and return values are front-loaded, then constraints follow in a logical order. The all-caps final sentence is slightly over-emphatic and partially duplicates the schema, but no sentence is 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?

For a read-only pricing tool with an output schema, the description covers the remaining unknowns an agent needs: registry re-check, premium handling, quote expiry, budget semantics, and the fact that no purchase can occur.

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 schema itself already states that project_id never changes the price, so the description's budget-context paragraph largely restates structured data. The domain parameter is not elaborated beyond the schema's own example.

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?

Opens with a specific verb and resource ('Prices a name believed to be unregistered') and enumerates the returns (total_cents, renewal_cents, expiry, confirm_url). It also implicitly separates itself from check_live/verify_ownership by stating it re-runs the registry check and never completes an order.

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 trigger: 'For when the user has chosen a name and wants the real price.' It also states when-not conditions: registered or unconfirmable names are not quoted, expired quotes are re-quoted, and no tool in the server can complete the purchase.

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?