ipinfo

Lookup Ip

lookup_ip

Read-onlyIdempotent

Get geolocation and network info for any IP address (e.g., "8.8.8.8"). Returns city, region, country, coordinates, org, postal code, timezone.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ip`	Yes	IPv4 or IPv6 address to look up (e.g., "8.8.8.8")

Output Schema

TableJSON Schema

Name	Required	Description
`ip`	Yes	The IP address that was looked up
`org`	Yes	Organization or ISP name
`city`	Yes	City name associated with the IP address
`postal`	Yes	Postal code associated with the IP address
`region`	Yes	Region or state associated with the IP address
`country`	Yes	Country code associated with the IP address
`latitude`	Yes	Latitude coordinate of the IP geolocation
`timezone`	Yes	Timezone associated with the IP address
`longitude`	Yes	Longitude coordinate of the IP geolocation

Schema Changelog

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

Changed2 schema fields changedMay 24, 2026

addedInput schema / examples

Added value: +[
+  {
+    "ip": "8.8.8.8"
+  },
+  {
+    "ip": "2001:4860:4860::8888"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "city": {
+      "description": "City name associated with the IP address",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "country": {
+      "description": "Country code associated with the IP address",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ip": {
+      "description": "The IP address that was looked up",
+      "type": "string"
+    },
+    "latitude": {
+      "description": "Latitude coordinate of the IP geolocation",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "longitude": {
+      "description": "Longitude coordinate of the IP geolocation",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "org": {
+      "description": "Organization or ISP name",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "postal": {
+      "description": "Postal code associated with the IP address",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "region": {
+      "description": "Region or state associated with the IP address",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "timezone": {
+      "description": "Timezone associated with the IP address",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "ip",
+    "city",
+    "region",
+    "country",
+    "latitude",
+    "longitude",
+    "org",
+    "postal",
+    "timezone"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedMay 11, 2026

removedInput schema / examples

Removed value: -[
-  {
-    "ip": "8.8.8.8"
-  },
-  {
-    "ip": "1.1.1.1"
-  }
-]

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "cpes": {
-      "description": "List of CPE software identifiers found on the IP address",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "found": {
-      "description": "Whether the IP address was found in Shodan InternetDB",
-      "type": "boolean"
-    },
-    "hostnames": {
-      "description": "List of hostnames associated with the IP address",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "ip": {
-      "description": "The IPv4 address that was looked up",
-      "type": "string"
-    },
-    "ports": {
-      "description": "List of open ports found on the IP address",
-      "items": {
-        "type": "number"
-      },
-      "type": "array"
-    },
-    "tags": {
-      "description": "List of tags associated with the IP address",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    "vulns": {
-      "description": "List of known CVE vulnerabilities for the IP address",
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    }
-  },
-  "required": [
-    "ip",
-    "found",
-    "ports",
-    "hostnames",
-    "vulns",
-    "cpes",
-    "tags"
-  ],
-  "type": "object"
-}New value: +null

Changed1 schema field changedMay 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "cpes": {
+      "description": "List of CPE software identifiers found on the IP address",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "found": {
+      "description": "Whether the IP address was found in Shodan InternetDB",
+      "type": "boolean"
+    },
+    "hostnames": {
+      "description": "List of hostnames associated with the IP address",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "ip": {
+      "description": "The IPv4 address that was looked up",
+      "type": "string"
+    },
+    "ports": {
+      "description": "List of open ports found on the IP address",
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "tags": {
+      "description": "List of tags associated with the IP address",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "vulns": {
+      "description": "List of known CVE vulnerabilities for the IP address",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "ip",
+    "found",
+    "ports",
+    "hostnames",
+    "vulns",
+    "cpes",
+    "tags"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "ip": "8.8.8.8"
+  },
+  {
+    "ip": "1.1.1.1"
+  }
+]

First observedApr 14, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description adds value by specifying the types of data returned and the 'any IP' scope. No hidden or unexpected behavior is disclosed, but none is present given 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.

Conciseness5/5

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

One sentence that front-loads the purpose, provides a concrete example, and lists the return fields. No filler words, perfectly sized for quick comprehension.

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 simple lookup tool with full schema coverage, an output schema, and safe-read annotations, the description is complete. It tells the user exactly what to expect and how to invoke it without redundant detail.

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 documentation covers 100% of the single parameter, and the description's example ('8.8.8.8') reinforces it. However, the description doesn't add new semantic meaning beyond what the schema already provides (e.g., IPv4/IPv6 details).

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 clearly states the action ('Get') and the resource ('geolocation and network info for any IP address'), and the example differentiates it from siblings like get_my_ip. It is specific and instantly understandable.

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 provides clear context: this tool is for looking up geolocation info for any IP address. It doesn't explicitly name alternatives or exclusions, but the use case is unambiguous given the example and return fields.

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

All ipinfo 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.6/5.0

Disambiguation2/5

Several tools have overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, and deep_research all answer data questions; polymarket_arbitrage, polymarket_edges, and polymarket_edge_tracker all scan prediction markets. Despite long descriptions, an agent could easily select the wrong one, especially the currently identical ask_pipeworx and ask_pipeworx_beta.

Naming Consistency3/5

Mostly snake_case, but with inconsistent patterns: get_my_ip/lookup_ip use verb_noun, entity_profile/recent_changes are noun phrases, remember/recall/forget are bare verbs, and the polymarket_* tools share a brand-prefixed noun style. Readable but not a predictable, uniform convention.

Tool Count2/5

At 33 tools, the server is overloaded, far exceeding the 25-tool threshold for 'too many.' It combines two unrelated identities—the original ipinfo IP lookup and the massive Pipeworx data/research platform—making the toolset heavy and harder for an agent to navigate efficiently.

Completeness4/5

The tool surface provides strong coverage of the data query and research lifecycle: discovery (discover_tools, suggest_questions), entity resolution (resolve_entity), lookup (ask_pipeworx, entity_profile), verification (validate_claim, ask_pipeworx_grounded), and post-processing (search_within, recent_changes). Minor gaps exist—for example, no dedicated 'get SEC filing by accession' tool or single-purpose financials endpoint—but these are workaroundable via the routing tools.

Lookup Ip

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources