Crawler IP Verifier - real Googlebot or fake

Can this crawler be verified at all, and how?

verification_methods

Read-onlyIdempotent

FIRST CALL, needs nothing: {"name":"whoami","arguments":{}} — Per crawler: whether the operator publishes IP ranges, documents reverse DNS, or publishes no verification method at all — with the exact source URL or the exact dig commands, and how fresh this mirror is. Call it before reading anything into an address that matched nothing. Reverse DNS is never run here; the command is handed back instead. Example: crawler='claudebot'. Also callable without MCP, same implementation: GET https://www.pathwren.workers.dev/tools/verification-methods?crawler=claudebot&s=client-dossiers

Input Schema

TableJSON Schema

Name	Required	Description	Default
`crawler`	No	Crawler slug, name, operator or UA substring. Omit for all of them.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description adds crucial behaviors: it never executes reverse DNS but returns the dig command, the output includes freshness of the mirror, and it is callable without MCP via the same implementation. No contradiction with 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 description is dense and mostly front-loaded, with the 'FIRST CALL' directive and output specifics early. The embedded `whoami` JSON is confusing and slightly undermines structural clarity, but there is no redundant filler.

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 one optional parameter and no output schema, the description explains what is returned (verification type, exact source/commands, freshness), when to call it, and how to reach it via REST. The main gap is the ambiguous `whoami` reference and no explicit statement about response structure for the 'no verification method' case.

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?

The schema already documents the optional `crawler` parameter with 100% coverage. The description adds an example value (`claudebot`) and the notion that the call 'needs nothing,' but this is only marginal added meaning, so it remains at the baseline for high schema coverage.

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?

The description states a specific deliverable: for a given crawler, whether the operator publishes IP ranges, documents reverse DNS, or publishes no verification method, including exact source URLs/dig commands and freshness. This distinguishes it from sibling lookup/verify tools, though the opening mentions 'whoami' in a way that can confuse tool identity.

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?

It explicitly marks itself as the 'FIRST CALL' and instructs 'Call it before reading anything into an address that matched nothing,' giving a clear when-to-use. It also clarifies a non-behavior: 'Reverse DNS is never run here; the command is handed back instead.' It doesn't name alternative tools explicitly, so it stops short of full routing.

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

All Crawler IP Verifier - real Googlebot or fake tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation2/5

verify_my_address and whoami both check the caller's address against published crawler prefixes using the user-agent as the claim, making their outputs largely redundant. verify_batch and example also overlap in shape, with example appearing to run a verification though it only returns canned data. lookup_prefix, range_stats, and verification_methods are distinct, but the core verification tools blur together.

Naming Consistency3/5

Several tools follow a verb_noun pattern (export_ip_acl, lookup_prefix, verify_batch), but range_stats and verification_methods are noun phrases, whoami breaks the pattern entirely, and example is not a domain verb at all. The names are still readable and mostly snake_case, so the inconsistency is noticeable but not chaotic.

Tool Count5/5

Eight tools is a reasonable, well-scoped size for an IP verification server. The surface covers verification, lookup, stats, export, and method discovery without ballooning into excessive granularity.

Completeness4/5

The core workflow of verifying an IP/claim against published crawler ranges is well covered, along with useful extras like prefix lookup, ACL export, and source freshness stats. The main gap is that there is no obvious way to enumerate all known crawler operators from the tool set, since verification_methods requires a crawler name to be supplied.

Resources

Need Help?