Crawler IP Verifier - real Googlebot or fake

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

Annotations already mark it read-only, idempotent, and non-destructive; the description adds substantial context beyond that: no API key, no account, no consent prompt, deterministic, touches no third party, input is canned from host data, and the response is real structuredContent 'not a mock.' This is exactly the kind of behavioral disclosure that helps an agent trust and predict the call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is heavily redundant: 'no third party' appears three times, 'shape of an answer' twice, and the canned-input/no-URL-of-yours point twice. It also opens with a raw HTTP/JSON-RPC POST instruction that an MCP agent invoking the tool through its framework does not need to construct. The essential message is roughly a third of the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema, safety/determinism annotations, and a zero-parameter input schema, the description covers everything remaining: what the canned call verifies, that the result is a real structuredContent response, and that no auth or external resources are involved. Completeness is high; the bloat and odd HTTP framing are presentation flaws, not gaps.

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

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

Zero parameters with 100% schema coverage set a baseline of 4. The description goes beyond the empty schema by explicitly stating 'Takes no arguments,' showing the exact arguments={} call shape, and explaining what canned input that produces. Nothing more is needed for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the purpose specifically: run this server's own worked example of verify_batch on canned input to see the exact shape of a real answer. It distinguishes itself from the verify_batch sibling by the canned-input contrast ('no URL of yours is fetched'), but this differentiation sits deep in a long passage rather than up front, so the purpose is clear yet not instantly extractable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'Use it to see the shape of an answer before you decide what to send.' The repeated contrast between canned input and the agent's own data implicitly tells the agent this is not the tool for checking real addresses. It never explicitly names the alternative tool for real checks, so it stops short of a 5.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond annotations: every export includes a provenance header with source URLs and mirror time, and it reports rule cost. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core information is dense and mostly front-loaded, but the 'FIRST CALL, needs nothing: {"name":"whoami",...}' prefix is confusing in a tool description and interrupts the main purpose statement. The rest is reasonably concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 0 required parameters and a 100%-covered schema, the description is nearly complete: it lists formats, uses a representative example, and explains provenance and cost behavior. The main missing piece is explicit guidance on what the returned text/header looks like, but the provenance statement partly covers that.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters and their enums/defaults. The description adds only a representative example and format-name context, which is useful but not required for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Turn a set of operators into a config you can paste', and enumerates the concrete output formats (nginx, Apache, HAProxy, Cloudflare, ipset, Caddy, CIDR). This clearly separates it from sibling verification/lookup tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when the tool applies (any need for paste-ready allow/deny config), reinforced by a concrete example. It does not explicitly state when not to use it or name an alternative, and the opening 'FIRST CALL... whoami' prerequisite is cryptic.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral nuance: matching is three-way (containing, contained, overlapping) and source-slug mode returns everything that source publishes. It does not describe response format or limits, but for a safe lookup tool this is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and mostly useful, but it opens with an inline JSON call to the sibling whoami tool before stating lookup_prefix's actual purpose. That makes the structure less front-loaded and potentially confusing during tool selection. The main behavioral statement is buried after an em-dash, though every other part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-mode lookup with no output schema, the description covers the core return semantics (matching prefixes by containment/overlap or by source) and gives an example call. It does not specify behavior when both or neither parameters are supplied, and it does not mention potential result size, but those are marginal for invoking the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3 because parameter descriptions already exist in the schema. The description adds value by framing cidr and operator as mutually exclusive alternatives ('Give an operator or source slug instead') and by providing a concrete cidr example. This goes slightly beyond the schema without doing the schema's job.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that lookup_prefix returns all published operator prefixes that contain, are contained by, or partially overlap a given CIDR, and that it can alternatively return everything published by a source slug. This is a specific verb+resource behavior with concrete use cases. It does not explicitly differentiate this tool from sibling tools such as range_stats, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: checking whether a network collides with a crawler range and auditing an allowlist. It also tells the agent when to provide a CIDR versus an operator/source slug by using 'instead,' and it opens with a whoami prerequisite. It does not state when not to use this tool relative to the sibling range or verification tools, so exclusions are missing.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by stating determinism, no third-party interaction, and the per-source output granularity. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the most important traits: no arguments, safe, deterministic, no third-party calls. The final example is slightly redundant with the first sentence and schema example, but the overall structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of explaining return value contents, and it does so thoroughly: prefix counts, totals, /24-equivalents, extremes, URLs, fetch times, and multi-operator prefixes. This is complete enough for an agent to understand what the tool returns and why it matters.

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

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

The tool has zero parameters, so the baseline is 4. The description reinforces this with 'Takes no arguments' and an explicit {} example, leaving no ambiguity for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies what the tool produces: per-source prefix statistics, sizing/freshness information, and multi-operator prefixes. This is specific enough to distinguish range_stats from siblings like lookup_prefix, verify_batch, and export_ip_acl.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the intended decision context: 'the sizing and freshness information an allowlist decision needs.' It does not explicitly name alternatives or exclusions, but the no-arguments, read-only, aggregate nature makes the appropriate use case clear.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful context: it returns the matching prefix, source, mirror timestamp, and operator rollup. It also discloses the important semantic that a miss is not evidence of a fake, and notes the same implementation is callable via plain HTTP.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Most sentences earn their place, but the opening 'FIRST CALL, needs nothing: whoami' is an unrelated directive that adds confusion and does not describe verify_batch itself. The description is packed with useful detail, but the extraneous preamble and the non-MCP URL make it less tight than it should be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With one parameter, no output schema, and straightforward complexity, the description is complete: it explains input formats, maximum size, return contents, an example, claim semantics, and edge-case caveat. An agent has enough information to invoke the tool correctly.

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

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

The schema already documents the single 'addresses' parameter thoroughly, including accepted formats and the 500 maximum, so the baseline is 3. The description adds value by explaining {ip, claim} pairs and providing a concrete example showing how claims are matched or missed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Check up to 500 addresses against every mirrored operator prefix list in one call.' It clearly communicates the batch nature, the scope over all mirrored lists, and what is returned. The example reinforces the purpose and distinguishes it from single-address siblings like verify_my_address.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: batch verification of up to 500 addresses or {ip, claim} pairs. It does not explicitly name alternatives or state when not to use it, but 'in one call' and the 500-address limit signal the intended use case.

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

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

Beyond the read-only and idempotent annotations, the description discloses that no key, account, OAuth, or session is needed, that nothing is fetched externally, that no URL of the caller's is touched, and that all facts are computed from headers and mirrored files. It also explains the meaning of a miss, saying it is not evidence of a fake address, which is valuable interpretive context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is far too long and repetitive for a zero-argument tool. It includes the same JSON-RPC example more than once, repeats 'nothing to invent' and 'read-only', and buries the core purpose under transport-level details and sibling path listings that an MCP tool description does not need.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 0-parameter, read-only tool with an output schema, the description is fully complete: it explains invocation, authentication requirements, side-effect profile, return contents, and the interpretive caveat about a miss. Nothing needed to call the tool correctly is missing.

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

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

There are zero parameters, so the schema leaves nothing to document. The description reinforces this by stating that the arguments object must be empty and that there is nothing to invent, which is appropriate for a no-argument tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: verify whether the caller's address falls inside an operator-published prefix list, with no arguments needed. It also distinguishes itself from siblings by noting that only this server answers the verification question about the caller's own address. The clarity is slightly diluted by leading with a literal JSON-RPC body rather than a plain-language purpose statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'THIS IS THE CALL TO MAKE FIRST' and tells the agent there is nothing to look up and no argument to invent. It also maps out the sibling tools and notes that they answer other questions about the caller, giving clear routing guidance without requiring the agent to open schemas.

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

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

The description substantially extends the annotations: it discloses 'free, read-only, no API key, no account, no consent prompt,' 'Deterministic. Touches no third party,' and precisely attributes every fact to 'the headers on your own request or from a file this host already publishes.' This goes well beyond the readOnlyHint/idempotentHint/openWorldHint annotations and directly informs an agent's safety reasoning. There is no contradiction with 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is severely bloated and repetitive: the list 'the user-agent you sent, the address you came from, the class our instrument books you as, and whether this host has seen you before' appears nearly verbatim at least three times. The same guarantees (no arguments, nothing fetched, nothing invented) are also restated. It could be condensed to roughly three sentences without losing any information, and the repetition actively harms readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the bloat, all necessary information is present: exact invocation (endpoint and body), safety profile, data provenance, and the returned fields. An output schema exists, so return format needn't be repeated. The main gap is minor — no pagination or error-case discussion, which is low-stakes for a zero-argument read-only introspection tool.

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

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

With zero parameters and 100% schema coverage, the baseline is 4. The description adds explicit reinforcement that no arguments exist ('Takes no arguments,' 'no argument exists') and provides a concrete example invocation with 'arguments={}', which is useful extra confirmation for an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function: it reports caller identity — user-agent, source address, classification, and whether the host has seen the caller before. It also distinguishes itself from siblings by noting it runs 'through this server's own verify_batch.' However, the purpose is buried under a literal POST body and repetitive phrasing, so it's clear but not crisply stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than explicit: it says 'Takes no arguments. Safe to call' and gives an exact invocation body, which signals when to use it. But there is no explicit when-to-use vs alternatives such as verify_batch, verify_my_address, or lookup_prefix, and no stated conditions for choosing a sibling tool.

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