Parallel World

Verify that an IP address is really the AI bot its User-Agent claims

verify_ai_bot

Read-onlyIdempotent

Given the IP address and the User-Agent string of a request (for example from a server log), says whether that IP is inside the IP ranges the bot's operator publishes. The User-Agent is matched against the migurei bot registry (registry/bots); the IP is matched, IPv4 and IPv6, against the operator's published feed snapshot bundled with the registry (the snapshot date and registry version are in the answer). Status: verified (IP is in the operator's published ranges), ip_not_in_feed (the User-Agent names a registered bot but the IP is not in its ranges), no_feed (registered bot, but its operator publishes no IP ranges, so it cannot be checked), unknown_ua (no registered bot matches). Needs no outside request. Only public internet addresses are accepted (private, loopback, link-local, CGNAT, multicast, documentation and reserved addresses are refused). Read-only; the IP address and User-Agent are not stored and not logged. "verified" only means the IP is in the operator's ranges; the snapshot goes stale between updates.

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": {
      "ip": "<ip>",
      "user_agent": "<user_agent>"
    },
    "name": "verify_ai_bot"
  }
}

Input Schema

Name	Required	Description	Default
`ip`	Yes	One public IPv4 or IPv6 address, for example from the access log.
`user_agent`	Yes	The User-Agent header of that request, for example "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.1; +https://openai.com/gptbot)".

Output Schema

Name	Required	Description	Default
`ip`	Yes
`bot`	Yes
`feeds`	Yes
`limits`	No
`method`	No
`status`	Yes
`meaning`	No
`privacy`	No
`ip_version`	Yes
`matched_feed`	Yes
`snapshot_date`	Yes
`registry_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/closed-world annotations, it explains what each of the four statuses means, warns that the bundled feed snapshot goes stale between updates, and states that "verified" only proves range membership, not bot identity. It also adds privacy behavior (inputs are not stored or logged) and input restrictions (private, loopback, link-local, CGNAT, multicast, documentation and reserved addresses are refused). None of that duplicates the annotations.

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 core behavior leads, followed by status semantics and then caveats, so it is well front-loaded. It runs long and the parenthetical asides ("registry/bots", "the snapshot date and registry version are in the answer") are slightly noisy, but nearly every sentence carries decision-relevant information.

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 two-parameter read-only lookup with a full output schema, the description covers everything an agent needs: what is compared, the definition of each status, the staleness caveat, and the input acceptance rules. No remaining gaps that would cause a misselection or misuse.

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 100%, so both params are already documented, but the description adds meaning: both IPv4 and IPv6 are handled, the User-Agent is matched against the named bot registry, and the address is matched against the operator's published feed snapshot. It also breaks "public" out into concrete refused categories that the schema does not enumerate.

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 precise verb and resource: given an IP and User-Agent, report whether the IP falls inside the ranges the bot's operator publishes. That is clearly distinct from the siblings check_ai_bot_access and get_site_info, and the title reinforces the same scoping.

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?

The description supplies the selecting context ("for example from a server log") and makes clear this check is local ("Needs no outside request") and limited to public addresses. It never names the sibling tools or says when to prefer them, so it stops short of a full when/when-not routing statement.

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

All Parallel World 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?