Scopeweb

kb_search

Read-onlyIdempotent

Semantic search over a small curated corpus: Scopeweb's own documentation and methodology, ICANN policy, and per-registry policy documents. Returns passages with the source, its URL, and what that source may be cited for. For explaining how something works. It is retrieval, not authority: a vector search always returns its nearest neighbour, so a returned passage is not evidence that it answers the question. Per-registry policy fields and current registration status have their own sources, which take precedence over a passage here. 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": {
      "query": "<query>"
    },
    "name": "kb_search"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes
`top_k`	No

Output Schema

Name	Required	Description	Default
`query`	Yes
`model_v`	No
`passages`	Yes
`not_a_claim_about`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "model_v": {
+      "type": "string"
+    },
+    "not_a_claim_about": {
+      "type": "array"
+    },
+    "passages": {
+      "type": "array"
+    },
+    "query": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "query",
+    "passages"
+  ],
+  "type": "object"
+}

First observedSep 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world behavior, yet the description still adds real value: it warns that nearest-neighbour retrieval is not evidence of relevance, and states precedence rules against other sources. The closing 'Read-only. Cannot spend money' merely restates what annotations already establish.

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 corpus scope and the purpose statement are front-loaded, and each caveat sentence carries distinct meaning about retrieval reliability. The trailing 'Read-only. Cannot spend money.' is redundant with the annotations and could be cut.

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?

With an output schema present, the description need not explain return values, but it does describe them (passages plus source, URL, citation scope), and it sets expectations about trustworthiness of results. The remaining hole is parameter guidance, particularly `top_k`, which nothing in the structured data covers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both parameters, so the description must carry the load, and it does not: `query` is never described (natural language? keyword? filters?) and `top_k` is never mentioned, nor its default or range. The agent learns nothing about parameter behavior beyond the names.

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?

Specific verb (semantic search) plus an enumerated corpus scope ('Scopeweb's own documentation and methodology, ICANN policy, and per-registry policy documents'), which distinguishes it from the generic `search` sibling. It does not name the sibling tools it defers to, only abstract 'own sources', so the differentiation is descriptive rather than tool-specific.

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?

Gives a clear positive trigger ('For explaining how something works') and an explicit exclusion (per-registry policy fields and current registration status have sources that take precedence). The alternatives are described conceptually rather than by tool name, leaving the agent to guess which sibling implements them.

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?