mcp-livedatapro

getIpIntelligence

High-accuracy IP geolocation, ASN/ISP details, and threat detection (VPN, Residential Proxy, Tor, Datacenter). Use when analyzing an IPv4 or IPv6 address for physical geolocation, ASN/ISP ownership, and cybersecurity threat indicators (VPN, Tor exit node, residential proxy, datacenter hosting). Do not use for domain name WHOIS lookups (use getDomainWhois) or street address validation (use validateAddressGeocode). Returns a 0-100 fraud risk score.

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_address": "<ip_address>"
    },
    "name": "getIpIntelligence"
  }
}

Input Schema

Name	Required	Description	Default
`ip_address`	Yes	Public IPv4 or IPv6 address to inspect for geolocation and proxy/VPN risk.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 24, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / ip_address / examples
```
Added value: +[
+  "8.8.8.8"
+]
```
- addedInput schema / properties / ip_address / maxLength
```
Added value: +45
```
- addedInput schema / properties / ip_address / minLength
```
Added value: +7
```

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / ip_address / description

Previous value: -"IPv4 or IPv6 address to inspect"New value: +"Public IPv4 or IPv6 address to inspect for geolocation and proxy/VPN risk."

First observedOct 21, 2026

TDQS

A4.2/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden. It does disclose the threat-indicator categories beyond the schema, and that the tool returns a 0-100 fraud risk score; but it says nothing about error behavior for private or malformed IPs, rate limits, or whether the lookup is a read-only deterministic call, which an agent needs for a lookup of this type.

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

Conciseness5/5

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

Three dense sentences put the capability first and keep the exclusion and return-value clauses together. Every clause carries information and no sentence is wasted.

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?

For a single-parameter tool, the definition covers purpose, exclusions, threat coverage, and a partial note on what it returns. Because there is no output schema and no annotations, a fuller account of the returned fields and preconditions would still help, but the description is sufficient for correct invocation.

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?

Schema description coverage is 100% and the single parameter is already documented in detail, so the baseline is 3. The description only echoes that it accepts IPv4 or IPv6, adding nothing beyond the schema's 'Public IPv4 or IPv6 address'.

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?

The description gives a specific verb-plus-resource statement: geolocation, ASN/ISP details, and threat detection for an IP address. It also names the two sibling tools it is not (getDomainWhois, validateAddressGeocode), which lets an agent separate it from them without opening the schema.

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?

The description states explicitly when to use the tool (IPv4 and IPv6 physical geolocation, ASN/ISP ownership, VPN/Tor/proxy/datacenter indicators) and when not to use it, naming the alternatives to use instead. It covers both the positive and the negative cases, leaving little to the agent's inference.

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

All mcp-livedatapro 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?