IPGeolocation MCP Server

VPN/Proxy/Threat Detection

check_security

Read-only

Read-only security lookup via GET /v3/security. Paid only. Cost: 2 credits. This endpoint is dedicated to security and threat data; lookup_ip with include=security provides security data together with location, ASN/company, network…

Instructions

Returns { ip, security } with threat_score, VPN, proxy, residential proxy, Tor, relay, anonymity, bot, spam, known attacker, and cloud-provider fields; provider names, confidence scores, and last_seen dates appear when available.

fields/excludes accept comma-separated security.* dot paths; ip is always returned. Threat scores and flags are indicators, not a safety guarantee; missing or unknown data is inconclusive. This queries IP intelligence, not the separate live browser detection API. force_refresh bypasses cached data, makes a new upstream request, and can consume credits.

Input Schema

Name	Required	Description
`ip`	No	IPv4 or IPv6 address to check. Omit to check the server's public egress IP.
`fields`	No	Comma-separated dot-path fields to return (e.g. security.threat_score,security.is_vpn). Reduces response size.
`excludes`	No	Comma-separated dot-path fields to exclude (e.g. security.is_tor,security.is_cloud_provider).
`force_refresh`	No	Default false. When true, bypasses cached security data; a successful refresh makes a new upstream request and can consume credits.

Output Schema

Name	Required	Description
`data`	No	Present on success: API result after field selection, redaction, and transport limits.
`page`	No
`error`	No	Present on failure, with isError: true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv2.0.3Oct 28, 2026

removedOutput schema / properties / data / additionalProperties / anyOf

Removed value: -[
-  {
-    "type": "null"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "array"
-  },
-  {
-    "type": "object"
-  }
-]

addedOutput schema / properties / data / additionalProperties / type

Added value: +[
+  "null",
+  "boolean",
+  "number",
+  "string",
+  "array",
+  "object"
+]

Addedv2.0.1Oct 13, 2026
Removedv2.0.0Jul 25, 2026

Changed1 schema field changedv1.0.15May 8, 2026

changedInput schema / properties / force_refresh / description

Previous value: -"Default false. Leave unset unless the user asks to refresh or rerun."New value: +"Default false. Set true only when the user asks to refresh cached security data; a successful refresh makes a new upstream request and can consume credits."

First observedv1.0.10Mar 16, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds the cost model (2 credits), the caching behavior of force_refresh and its credit implications, and an important interpretive caveat that threat flags are indicators rather than guarantees and that missing data is inconclusive. These are behavior facts an agent cannot get from annotations or schema alone.

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?

Front-loads the endpoint, read-only nature, cost, and differentiation before moving to return fields and caveats. Despite covering a lot, each sentence carries a distinct decision-relevant fact with no filler.

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?

With an output schema present, the description does not need to define return values, yet it still summarizes the security object enough for the agent to know what it will receive. Cost, cache, refresh side effects, interpretive caveats, and sibling alternatives are all covered, leaving nothing an agent needs missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all four parameters, establishing a baseline of 3. The description adds some value beyond this: it clarifies that fields/excludes take comma-separated security.* dot paths, that ip is always returned, and that force_refresh can consume credits on a new upstream request. That is a modest but real improvement over the schema text.

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?

Opens with a specific verb, resource, and endpoint ("Read-only security lookup via GET /v3/security") and immediately distinguishes itself from lookup_ip with include=security. It also separates itself from the unrelated live browser detection API, so an agent can place it precisely among siblings.

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?

Gives explicit routing rules: use this endpoint for dedicated security/threat data, use lookup_ip with include=security when location, ASN, network, timezone, currency, or abuse data is also wanted. It also states it is paid-only at 2 credits and is not the browser detection API — clear when-to-use and when-not-to-use guidance.

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

Deploy Server