Zovo IP Lookup

Look up IP address owners

lookup_ip

Read-onlyIdempotent

Use this when the user wants an ip lookup, asks who owns this ip, needs the ip address owner or the whois ip details, wants the ip abuse contact, or needs an ip range lookup: it reads the five regional internet registries through RDAP and the reverse DNS (PTR) name, for one to twenty IPv4 or IPv6 addresses or CIDR ranges, and returns a CSV download for the batch. Limits: registry data shows the network holder and its country, not a street address or a person's location; some registries publish no abuse email; reverse DNS exists only when the network sets it. Do not use for an ip locator that claims a precise location, for looking up a domain name (that is a domain lookup), or for scanning a host.

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": {
      "ips": "<ips>"
    },
    "name": "lookup_ip"
  }
}

Input Schema

Name	Required	Description	Default
`ips`	Yes	One to twenty IPv4 or IPv6 addresses or CIDR ranges, separated by commas, spaces, or new lines. Example: 8.8.8.8, 1.1.1.1, 2606:4700:4700::1111, 192.168.1.1/24.

Output Schema

Name	Required	Description	Default
`count`	Yes
`notes`	Yes
`columns`	Yes
`sources`	Yes
`addresses`	Yes
`downloads`	Yes
`error_count`	Yes
`preview_note`	Yes
`public_count`	Yes
`preview_limit`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations already declare read-only, open-world, idempotent, and non-destructive behavior. Beyond that, the description adds data sources (five RIRs via RDAP plus PTR), batch size, CSV output, and important limits such as registry data showing only network holder/country, possible missing abuse contacts, and PTR existing only when configured.

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 definition is front-loaded with use cases, then limits and exclusions, and each clause supports selection. The first sentence is dense and slightly run-on, but it is not bloated and the structure remains clear.

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?

Given rich annotations, full schema coverage, and an output schema, the description supplies the remaining selection-relevant context: data sources, batch behavior, output format, limitations, and exclusions. An agent can determine when and how to call it correctly.

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?

There is a single ips parameter and schema description coverage is 100%, with the schema already documenting separators, limits, and examples. The description repeats the same one-to-twenty address/range constraint but adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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?

States a specific verb and resource: reads RIR RDAP and PTR data for one to twenty IPv4/IPv6 addresses or CIDR ranges and returns a CSV batch download. It clearly excludes domain lookup, precise IP locator use, and host scanning, but does not explicitly distinguish itself from the sibling reverse_dns_lookup tool even though reverse DNS is part of its output.

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?

Opens with concrete user intents (IP lookup, owner, WHOIS details, abuse contact, range lookup) and gives explicit do-not-use cases: precise IP locator, domain lookup, and host scanning. The only gap is that it does not name reverse_dns_lookup as an alternative, but overall the when/when-not guidance is strong.

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

All Zovo IP Lookup 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?