IP Geolocation MCP Server
IPGeolocation.io MCP Server
Official MCP server for IPGeolocation.io. Includes 16 MCP tools: IP geolocation, threat/VPN/proxy detection, timezone lookups and conversions, sunrise/sunset/moon data, ASN details, abuse contacts, and user-agent parsing. Seven tools work on the free plan (1,000 credits/day). Paid plans unlock all 16 plus bulk endpoints (up to 1,000 items per call).
Works with Claude Desktop, Cursor, Windsurf, VS Code, Codex, Cline, Glama, and any other MCP client.
Item | Value |
Package |
|
Version |
|
Transport |
|
Node.js |
|
Quick Start
Cursor users can install in one click:
Add this to your MCP client config (see Install by Client below for the exact config file path for your client):
{
"mcpServers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Restart your client.
Test it: ask "Where is 8.8.8.8 located?"
Related MCP server: GeoIP MCP Server
Table of Contents
Install by Client
Requirements
Node.js 18 or later
npxavailable in your terminalAn IPGeolocation.io API key for most tools
get_my_ip works without an API key. Everything else requires one.
Sign up for a free IPGeolocation API key
Codex CLI
codex mcp add ipgeolocation --env IPGEOLOCATION_API_KEY=<YOUR_API_KEY> -- npx -y ipgeolocation-io-mcp
codex mcp listStart a new Codex session after adding the server.
Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Restart Claude Desktop after saving. We also ship manifest.json for clients that support MCP Bundles.
Cline
Open MCP Servers panel > Configure > Advanced MCP Settings. Add to cline_mcp_settings.json:
{
"mcpServers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Restart Cline after saving.
Cursor
One-click install:
Or add to .cursor/mcp.json manually:
{
"mcpServers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Restart Cursor after saving.
Windsurf
Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}Restart Windsurf after saving.
VS Code / GitHub Copilot
Add to your VS Code settings.json:
{
"mcp": {
"servers": {
"ipgeolocation": {
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}
}
}
}Restart VS Code after saving.
Glama
You can try the server on Glama directly. Only IPGEOLOCATION_API_KEY is required. Leave other environment variable fields empty unless you want to change cache, timeout, or output limits.
If you don't have a key yet, create a free IPGeolocation API key.
Any Other MCP Client
Use this config:
{
"command": "npx",
"args": ["-y", "ipgeolocation-io-mcp"],
"env": {
"IPGEOLOCATION_API_KEY": "<YOUR_API_KEY>"
}
}Verify It Works
Try these after setup:
Prompt | Expected tool |
Where is 8.8.8.8 located? |
|
For IP 49.12.212.42, give me security verdict, company, ASN, and city. |
|
Is 2.56.12.11 safe to allow and what is the abuse contact email? |
|
For AS1, list upstream ASN numbers only. |
|
Convert 2026-03-07 09:30 from New York to Tokyo time. |
|
Give sunrise times for Karachi from 2026-03-10 to 2026-03-15. |
|
Parse this user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 |
|
Tools by Plan
Free Plan
1,000 credits per day. These 7 tools are available:
Tool | Credits | What it does |
| 1 | Location, timezone, currency, ASN for one IP |
| 0 | Public IP of the machine running the server |
| 1 | Currency and country metadata for one IP |
| 1 | Timezone by name, location, IP, airport code, or UN/LOCODE |
| 1 | Convert time between two locations |
| 1 | Sunrise, sunset, moonrise, moonset, twilight, moon phase for one date |
| 1 | Daily astronomy data for a date range (up to 90 days) |
Paid Plans
All 16 tools. Paid plans also add network, company, and extended asn fields to lookup_ip, plus the include parameter for security, abuse, hostname, liveHostname, hostnameFallbackLive, user_agent, geo_accuracy, dma_code, or *.
Tool | Credits | What it does |
| 1 per IP | Batch geolocation for up to 1,000 IPs |
| 2 | VPN, proxy, Tor, bot, spam, and threat flags |
| 2 per IP | Batch threat checks |
| 1 | Company name and ASN holder for one IP |
| 1 | Route prefix, connection type, anycast status |
| 1 | Parse one UA string into browser, device, OS, engine |
| 1 per UA | Batch UA parsing for up to 1,000 strings |
| 1 | ASN details, peers, upstreams, downstreams, routes, WHOIS |
| 1 | Abuse contact emails, phone, address, route |
Credit math for lookup_ip with include:
Combination | Total credits |
Base lookup | 1 |
| 3 |
| 2 |
| 4 |
| 2 |
| 1 |
For current plan details and pricing, see the IPGeolocation pricing page.
Tool Reference
lookup_ip
Single IP or domain lookup. Free and paid. 1 credit.
Use this when you need location, timezone, currency, or ASN for one IP address. On paid plans you can add include modules to pull security, abuse, or hostname data in the same call, which avoids extra requests.
Free plan returns base location, country metadata, currency, timezone, and basic ASN. Paid plans add network, company, extended ASN, and the include parameter. Note that domain lookups require a paid plan.
Parameter | Required | Description |
| No | IPv4, IPv6, or domain. Domain lookup requires a paid plan. |
| No | Response language. Non-English requires a paid plan. |
| No | Extra modules: |
| No | Comma-separated fields to return |
| No | Comma-separated fields to exclude |
| No | Skip the cache and hit the API directly |
Tip: combining include with fields can cut your credit cost. For example, include=security&fields=security costs 2 credits instead of 3 because you skip the base geolocation response. Similarly, include=abuse&fields=abuse costs 1 credit instead of 2.
bulk_lookup_ip
Batch IP lookup. Paid. 1 credit per IP.
Takes an array of IPs or domains (up to 1,000 by default, configurable with IPGEOLOCATION_MCP_MAX_BULK_ITEMS). Supports the same include, fields, and excludes options as lookup_ip.
Parameter | Required | Description |
| Yes | Array of IP addresses or domains |
| No | Response language |
| No | Extra modules per IP |
| No | Comma-separated fields to return per IP |
| No | Comma-separated fields to exclude per IP |
| No | Skip the cache |
get_my_ip
Returns the public IP of the machine running the server. Free. 0 credits. No API key needed.
Takes no parameters. Always hits the network (not cached). Useful as a quick check to confirm the server process is up.
check_security
Threat and anonymity data for one IP. Paid. 2 credits.
Returns threat score, VPN/proxy/Tor flags, provider names, confidence scores, bot/spam indicators, anonymity flags, and cloud-provider status.
If the same prompt also asks for location, ASN, or abuse data, you're better off using lookup_ip with include=security because it bundles everything in one call (3 credits total instead of 2 + 1 separately).
Parameter | Required | Description |
| No | IP address to check |
| No | Comma-separated fields to return |
| No | Comma-separated fields to exclude |
| No | Skip the cache |
bulk_security_check
Batch version of check_security. Paid. 2 credits per IP.
Parameter | Required | Description |
| Yes | Array of IP addresses |
| No | Comma-separated fields to return per IP |
| No | Comma-separated fields to exclude per IP |
| No | Skip the cache |
get_timezone
Current time and timezone details for a location. Free and paid. 1 credit.
Accepts IANA timezone names, coordinates, IP addresses, airport codes (IATA/ICAO), or UN/LOCODEs. The response includes timezone offsets, date/datetime variants, current_time, current_time_unix, time_24, time_12, week, month, year, timezone abbreviations, and DST transition details.
Always hits the network (not cached) because it returns the current time.
Parameter | Required | Description |
| No | IANA timezone name (e.g., |
| No | Latitude and longitude |
| No | City or address string |
| No | IP address |
| No | IATA airport code |
| No | ICAO airport code |
| No | UN/LOCODE |
| No | Response language. Non-English requires a paid plan. |
convert_timezone
Converts a time between two locations. Free and paid. 1 credit.
Takes the same location input types as get_timezone for both source and destination. If you leave out the time parameter, it converts the current time. Always hits the network (not cached).
Parameter | Required | Description |
| No |
|
| No | IANA timezone names |
| No | Source coordinates |
| No | Destination coordinates |
| No | City/address strings |
| No | IATA airport codes |
| No | ICAO airport codes |
| No | UN/LOCODEs |
get_astronomy
Sun and moon data for one location on one date. Free and paid. 1 credit.
Returns sunrise, sunset, moonrise, moonset, morning and evening twilight, solar noon, day length, moon phase, sun/moon status flags, and live sun/moon position (altitude, azimuth).
Always hits the network (not cached) because skipping date defaults to today.
Parameter | Required | Description |
| No | Coordinates (highest priority when given) |
| No | City or address |
| No | IP address |
| No |
|
| No | Meters, 0 to 10000 |
| No | IANA name to control output times |
| No | Response language. Non-English requires a paid plan. |
get_astronomy_time_series
Astronomy data for a date range, up to 90 days. Free and paid. 1 credit per request.
Each daily entry includes mid_night, night_end, morning, sunrise, sunset, evening, night_begin, sun_status, solar_noon, day_length, moon_phase, moonrise, moonset, and moon_status. Use this instead of calling get_astronomy repeatedly for a range.
Parameter | Required | Description |
| Yes | Start date ( |
| Yes | End date ( |
| No | Coordinates (highest priority when given) |
| No | City or address |
| No | IP address |
| No | Meters |
| No | IANA name to control output times |
| No | Response language. Non-English requires a paid plan. |
| No | Skip the cache |
parse_user_agent
Parses one UA string into browser, device, OS, and engine data. Paid. 1 credit.
Also classifies bots and crawlers. Note: this parses the uaString you pass in. It does not infer a caller UA from the MCP connection itself.
Parameter | Required | Description |
| Yes | The user-agent string to parse |
| No | Skip the cache |
Returns name, type, version, device, engine, and operating_system.
bulk_parse_user_agent
Batch version of parse_user_agent. Paid. 1 credit per string.
Takes up to 1,000 strings per request by default (configurable with IPGEOLOCATION_MCP_MAX_BULK_ITEMS).
Parameter | Required | Description |
| Yes | Array of user-agent strings |
| No | Skip the cache |
lookup_company
Returns just the company name and ASN holder for one IP. Paid. 1 credit.
Returns company and asn objects. lookup_ip returns the same data plus location, timezone, and more. Use this when the company/ASN pair is all you need and you want a smaller response.
Parameter | Required | Description |
| No | IP address |
| No | Skip the cache |
lookup_currency
Currency, country calling code, TLD, and languages for one IP. Free and paid. 1 credit.
Returns currency and country_metadata objects.
Parameter | Required | Description |
| No | IP address |
| No | Skip the cache |
lookup_network
Route prefix, connection type, and anycast status for one IP. Paid. 1 credit.
Returns a network object with connection_type, route, and is_anycast.
Parameter | Required | Description |
| No | IP address |
| No | Skip the cache |
lookup_asn
Full ASN lookup. Paid. 1 credit.
lookup_ip also returns an asn object, but only with basic metadata. This tool returns the full ASN record, including peers, upstreams, downstreams, routes, and WHOIS. Call it once with the include fields you need, then filter locally instead of making multiple calls for different slices.
Parameter | Required | Description |
| No | ASN (e.g., |
| No | IP address to resolve to an ASN |
| No |
|
| No | Comma-separated fields to return |
| No | Comma-separated fields to exclude |
| No | Skip the cache |
get_abuse_contact
Abuse contact details for one IP. Paid. 1 credit.
Returns the abuse route, country, contact name, organization, address, email addresses, and phone numbers. If you also need geolocation or security data for the same IP, use lookup_ip with include=abuse (or include=security,abuse) to get everything in one call.
Parameter | Required | Description |
| No | IP address |
| No | Comma-separated fields to return |
| No | Comma-separated fields to exclude |
| No | Skip the cache |
Prompt Examples
Check if an IP is safe
Is 49.12.212.42 safe to trust in our network? Give me the threat summary and city.
Check these IPs for VPN, proxy, Tor, bot, and spam indicators: 49.12.212.42, 2.56.12.11, 8.8.8.8
For 203.0.113.42, tell me the threat score, whether it is a cloud provider, and whether it looks like a relay.
Find who owns an IP
Who uses 1.1.1.1 and which ASN routes it?
For AS24940, list upstream ASN numbers only.
Is this IP anycast and what route prefix is announced for it: 1.1.1.1
Get abuse contacts
For IP 2.56.12.11, give me the abuse contact email, phone number, and organization.
I need the abuse contact for 1.0.0.0 and the network route involved.
For this IP, show me the abuse contact details only: 198.51.100.27
Timezone lookups and conversions
What time is it in Tokyo right now?
Convert 2026-03-07 09:30 from New York to Tokyo time.
What is the current local time at JFK airport?
Sunrise, sunset, and moon data
Give sunrise and sunset for London on 2026-06-21.
Show sunrise times in Karachi from 2026-03-10 to 2026-03-15.
For New York, give me moon phase and day length on 2026-07-17.
Parse user-agent strings
Parse this user agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/601.3.9 (KHTML, like Gecko) Version/9.0.2 Safari/601.3.9
Parse these user agents in bulk and tell me the browser, OS, and device type for each.
Does this user agent look like a crawler or bot? Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Example Answers and Tool Output
The text answers below show what a client might say. Exact wording depends on the model. The JSON blocks show raw tool output, trimmed for readability.
Single IP lookup
Prompt: Locate 91.128.103.196 and give me the country, city, ASN, and local time.
Example answer: 91.128.103.196 is in Stockholm, Sweden. ASN is AS1257, operated by Tele2 Sverige AB. Timezone is Europe/Stockholm, local time was 2026-02-12 18:36:54.
{
"ip": "91.128.103.196",
"location": {
"country_name": "Sweden",
"state_prov": "Stockholms lan",
"city": "Stockholm"
},
"asn": {
"as_number": "AS1257",
"organization": "Tele2 Sverige AB",
"country": "SE"
},
"time_zone": {
"name": "Europe/Stockholm",
"current_time": "2026-02-12 18:36:54.401+0100"
}
}Time conversion
Prompt: Convert 2025-01-21 13:42:52 from DXB to LHR.
Example answer: 2025-01-21 13:42:52 in Dubai converts to 2025-01-21 09:42:52 in London. The difference is 4 hours.
{
"original_time": "2025-01-21 13:42:52",
"converted_time": "2025-01-21 09:42:52",
"diff_hour": 4,
"diff_min": 240
}Abuse contact
Prompt: Give me the abuse contact for 1.0.0.0.
Example answer: The abuse contact for 1.0.0.0 is IRT-APNICRANDNET-AU in Australia, covering route 1.0.0.0/24. Email: helpdesk@apnic.net.
{
"ip": "1.0.0.0",
"abuse": {
"route": "1.0.0.0/24",
"country": "AU",
"name": "IRT-APNICRANDNET-AU",
"address": "PO Box 3646, South Brisbane, QLD 4101, Australia",
"emails": ["helpdesk@apnic.net"]
}
}Error Codes
All tools return structured errors instead of crashing the server. API errors include the upstream status/message plus a guidance field so MCP clients can tell the user what to check next instead of only repeating the upstream response.
Code | Meaning |
| Bad parameters, invalid date/time format, missing coordinate pair, or unsupported input |
| Missing/invalid API key, free plan calling a paid tool, or non-English |
| Resource not found (e.g., ASN does not exist) |
| Method or subscription restriction from the upstream API |
| POST body is larger than the upstream API allows |
| POST request is missing the required |
| Bogon or private IP ( |
| Rate limit, daily credit limit, or account quota exceeded |
| Client-side request or connection timeout was too short |
| Upstream API server-side error |
| Server could not reach the upstream API |
| Upstream API timed out |
Exact status codes can vary by endpoint and request mode. If an upstream endpoint returns a status outside this table, the server does not guess the cause. It passes the upstream status and message through with category: "undocumented_api_error" and adds guidance for the MCP client to explain the response as an undocumented upstream status without inventing a cause.
How It Works
This is a stdio MCP server that wraps the ipgeolocation.io v3 APIs.
At runtime:
Your MCP client starts the server process.
The client reads the tool list.
When a prompt matches a tool, the client calls it.
The server validates inputs, calls our API, and returns structured JSON.
Cacheable responses are stored in process memory so repeated identical requests skip the API call.
lookup_company, lookup_currency, and lookup_network are wrappers around parts of the full IP lookup response. They exist as separate tools so MCP clients can discover them when a user only needs one piece of data.
Caching
Tools that return stable data (not current-time lookups) cache their responses in process memory. Repeated lookups are faster and don't use additional credits. Client retries don't generate duplicate API calls.
Process-level cache, not client or model memory
Cache entries are scoped by API key, so separate MCP sessions do not share cached upstream data
Default TTL: 5 minutes (
300000ms)Cache resets when the server process stops
Cache misses on TTL expiry, changed parameters, or
force_refresh: true
Cached: lookup_ip, bulk_lookup_ip, check_security, bulk_security_check, lookup_company, lookup_currency, lookup_network, parse_user_agent, bulk_parse_user_agent, lookup_asn, get_abuse_contact, get_astronomy_time_series
Always live (not cached): get_my_ip, get_timezone, convert_timezone, get_astronomy
Environment Variables
Variable | Required | Default | Description |
| Yes (most tools) | Your ipgeolocation.io API key | |
| No |
| Upstream timeout in ms. Range: 1000-120000 |
| No |
| Cache TTL in ms. Range: 1000-3600000 |
| No |
| Max entries before eviction. Range: 10-5000 |
| No |
| Max items per bulk request. Max: 50000 |
| No |
| Max array items before truncation |
| No |
| Max response text length |
| No |
| Max error text length |
Building from Source
git clone https://github.com/IPGeolocation/ipgeolocation-io-mcp.git
cd ipgeolocation-io-mcp
npm install
npm run buildRun it directly:
IPGEOLOCATION_API_KEY=<YOUR_KEY> node dist/cli.jsInspect with MCP Inspector:
IPGEOLOCATION_API_KEY=<YOUR_KEY> npx @modelcontextprotocol/inspector node dist/cli.jsDocker
docker build -t ipgeolocation-mcp .
docker run -e IPGEOLOCATION_API_KEY=<YOUR_KEY> ipgeolocation-mcpTesting
npm test # full suite
npm run test:unit # unit tests only
npm run test:integration # integration tests onlyTroubleshooting
Client uses an old tool after updating: Restart the client and confirm it loaded the latest npm version.
401 errors: Check that IPGEOLOCATION_API_KEY is set in your config. Some tools are paid-only and return 401 on the free plan. Domain lookups in lookup_ip also require a paid plan.
423 errors: You passed a private/bogon IP like 10.0.0.1 or 192.168.1.1. These have no geolocation data.
504 timeouts: The upstream API did not respond in time. Increase the timeout with IPGEOLOCATION_REQUEST_TIMEOUT_MS (default: 15000 ms, max: 120000 ms).
Pricing
For current plan details, credits, and pricing, see the IPGeolocation pricing page.
Links
License
Privacy Policy
Read the IPGeolocation Privacy Policy.
Available Tools
5 toolsbulk_lookup_ipBulk IP GeolocationARead-only
Read-only bulk IP lookup via POST /v3/ipgeo-bulk. Paid only. Base geolocation costs 1 credit per valid IP; security adds 2 and abuse adds 1 per valid IP. This MCP server accepts up to 1,000 IPs per request.
The response covers location data or mixed IP data domains for multiple IPs or domains. Private, bogon, and malformed IPs are not billed. fields, excludes, lang, and include behave like lookup_ip for each item; this server also infers include modules from fields. bulk_security_check provides dedicated security-only batch responses.
| Name | Required | Description | Default |
|---|---|---|---|
| ips | Yes | Array of IPv4 and/or IPv6 addresses to look up. Minimum 1, maximum 1,000 in this MCP server. Domain names are also accepted. | |
| lang | No | Response language code (en, de, ru, ja, fr, cn, es, cs, it, ko, fa, pt). Defaults to en. | |
| fields | No | Comma-separated dot-path fields to return per IP (e.g. location.city,asn.organization). Reduces response size and can reduce credit cost when combined with include. If fields reference include-only modules (for example security.* or abuse.*), this server auto-adds required include modules. | |
| include | No | Comma-separated extra modules to include per IP. Options: security (+2 credits/IP), abuse (+1 credit/IP), hostname, liveHostname, hostnameFallbackLive, user_agent, geo_accuracy, dma_code, or * for all (4 credits/IP total). | |
| excludes | No | Comma-separated dot-path fields to exclude per IP (e.g. currency,time_zone). | |
| force_refresh | No | Default false. When true, bypasses cached bulk geolocation data; a successful refresh makes a new upstream request and can consume credits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: billing rules (not billed for private/bogon IPs), auto-inference of include modules, behavior of fields/excludes/lang similar to lookup_ip, and caching behavior of force_refresh. No contradiction with readOnlyHint or openWorldHint.
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?
Organized into three paragraphs with front-loaded key info (read-only, paid, limits). Could be slightly more concise, but each sentence adds unique value. No redundant or vague sentences.
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?
Covers billing, limits, parameter interactions, and alternative tool. Lacks detailed return format (no output schema) and only vaguely describes response as 'location data or mixed IP data domains'. Adequate but gaps remain.
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 covers descriptions for all 6 parameters (100% coverage). Description adds extra semantics: auto-inference of include from fields, credit costs for include options, default lang, and force_refresh caching effect. Adds value beyond schema.
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?
Specifies 'Read-only bulk IP lookup' with verb and resource, distinguishes from sibling lookup_ip (single IP), and mentions HTTP method and credit costs. Clearly states what the tool does and sets expectations for bulk usage.
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?
Provides context on paid nature, credit costs, and limits (up to 1,000 IPs). Mentions alternative tool bulk_security_check for security-only. However, does not explicitly contrast with single IP lookup (lookup_ip) or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_my_ipGet My IP AddressARead-only
Returns the public IP address of the machine running this MCP server via GET /v3/getip. Takes no input parameters and requires no API key, account, or credits. The response is a plain IP address string, not geolocation data; lookup_ip provides location, ASN, timezone, currency, security, and abuse data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; description adds that no auth or credits are needed and that response is a plain IP string (not geolocation), adding useful context without contradiction.
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?
Two sentences, front-loaded with purpose, then usage and comparison. Every sentence adds value with no wasted words.
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 no parameters, no output schema, and simple functionality, the description fully covers purpose, usage, and differentiation from siblings.
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 description confirms no inputs, which is sufficient; no additional semantics needed.
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 tool returns the public IP address of the machine running the MCP server, specifies the endpoint GET /v3/getip, and distinguishes itself from sibling tool lookup_ip by contrasting the response type.
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?
Explicitly states it takes no input parameters, requires no API key/account/credits, and contrasts with lookup_ip for geolocation data, providing 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.
lookup_companyCompany/Organization LookupARead-only
Read-only ownership lookup via GET /v3/ipgeo. Paid only. Cost: 1 credit. This response is limited to company and ASN ownership; lookup_ip can return ownership together with location, security, abuse, network, timezone, or currency.
Returns { company, asn }: company name/type/domain plus ASN allocation fields when available. ip omitted means caller IP. force_refresh bypasses cached data, makes a new upstream request, and can consume credits.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | IPv4 or IPv6 address to look up. Omit to check the caller's IP. | |
| force_refresh | No | Default false. When true, bypasses cached ownership data; a successful refresh makes a new upstream request and can consume credits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Consistent with readOnlyHint = true. Discloses cost, credit consumption, data caching behavior, and the effect of force_refresh. All behavioral traits are transparently described.
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?
Concise at about 5 sentences, front-loaded with purpose, then usage, then return format. Every sentence adds value without redundancy.
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?
Covers purpose, parameters, return structure (company, asn), cost, alternatives, and caching. No missing information for this simple 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?
Adds context beyond the schema, e.g., 'ip omitted means caller IP' and explains force_refresh behavior. Schema already describes both parameters well, but the description provides useful additional usage detail.
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?
Clearly states 'Read-only ownership lookup via GET /v3/ipgeo' and specifies the limited scope to company and ASN ownership, distinguishing it from the sibling lookup_ip which returns more fields.
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?
Explicitly mentions 'Paid only. Cost: 1 credit' and explains when to use force_refresh. Contrasts with lookup_ip, providing guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_currencyCurrency and Country MetadataARead-only
Read-only currency and country metadata lookup via GET /v3/ipgeo. Works on free and paid plans. Cost: 1 credit per successful lookup.
Returns { currency, country_metadata }: currency code/name/symbol plus country calling_code, tld, and languages. ip selects the IP used to derive country and currency; omit it for caller IP. force_refresh bypasses cached data, makes a new upstream request, and can consume credits.
This response is limited to currency and country metadata. lookup_ip can return these fields together with other IP data.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | IPv4 or IPv6 address whose country determines the returned currency and country metadata. Omit to use the caller's IP. | |
| force_refresh | No | Default false. When true, bypasses cached currency/country data; a successful refresh makes a new upstream request and can consume credits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses HTTP method, credit cost, caching behavior, and response structure (currency and country_metadata). Annotations already declare readOnly and openWorld, but description adds operational details beyond that.
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?
Description is clear and front-loaded with purpose, but could be slightly more concise. Some redundancy in explaining force_refresh credit consumption, but overall well-structured.
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 adequately explains returned fields and behavior under different parameter usage. Also references sibling tools, providing complete context for an agent.
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% with descriptions, so baseline is 3. The description adds context: ip selects the IP used to derive country and currency, force_refresh bypasses cached data and can consume credits. This extra value warrants a 4.
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 tool is a read-only lookup for currency and country metadata via GET /v3/ipgeo. It distinguishes from sibling tool lookup_ip by noting that lookup_ip returns these fields plus other IP data.
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?
Provides explicit guidance: works on free/paid plans, costs 1 credit per lookup, when to omit ip for caller IP, when to use force_refresh, and contrasts with lookup_ip for broader data needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_ipIP Geolocation LookupARead-only
Read-only unified IP lookup via GET /v3/ipgeo. Base lookup costs 1 credit; include=security adds 2 credits and include=abuse adds 1 credit. The unified response can cover multiple data domains for one IP or domain: location, company/ASN, network, timezone, currency, security, abuse, user_agent, hostname, geo_accuracy, and dma_code.
Returns root IP/domain data plus selected objects such as location, country_metadata, currency, asn, network, company, time_zone, security, abuse, user_agent, hostname, geo_accuracy, or dma_code. Free plans support core location, country_metadata, currency, time_zone, basic ASN, fields, and excludes; paid plans add domain lookup, company, network, extended ASN, non-English lang, and include modules.
ip omitted means caller IP. fields/excludes accept comma-separated dot paths; ip is always returned, unknown excludes do not error, and include wins over fields/excludes. This server auto-adds include modules referenced by fields. lookup_asn provides ASN relationships, routes, and WHOIS; check_security and get_abuse_contact provide dedicated security and abuse responses.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | IPv4 address, IPv6 address, or domain name to look up. Domain lookups require a paid plan. Omit to use the caller's IP. | |
| lang | No | Response language code (en, de, ru, ja, fr, cn, es, cs, it, ko, fa, pt). Paid plans only. Free plan returns a 401 error if you pass any value other than en. Defaults to en. | |
| fields | No | Comma-separated dot-path fields to return (e.g. location.city,asn.organization). Works on all plans including free. Reduces response size and can reduce credit cost when combined with include. If a field references an include-only module (for example security.* or abuse.*), this server auto-adds the required include module. | |
| include | No | Comma-separated extra modules to include in the response. Paid plans only. Options: security (+2 credits), abuse (+1 credit), hostname, liveHostname, hostnameFallbackLive, user_agent, geo_accuracy, dma_code, or * for all (4 credits total). Free plan cannot use this parameter. | |
| excludes | No | Comma-separated dot-path fields to exclude from response (e.g. currency,location.continent_code). Works on all plans including free. | |
| force_refresh | No | Default false. When true, bypasses cached lookup_ip data; a successful refresh makes a new upstream request and can consume credits. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral context beyond annotations: credit costs per module, plan restrictions, auto-adds include modules, fields/excludes handling, force_refresh bypasses cache, ip always returned, unknown excludes do not error. Annotations only state readOnlyHint and openWorldHint, so description enriches understanding.
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?
Description is detailed and somewhat lengthy with multiple paragraphs. While it front-loads the essential purpose and cost structure, some details could be more compact. Still, every sentence adds necessary information for a complex tool.
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 no output schema, the description adequately explains return values (root data plus selected objects) and lists possible fields. It covers credit costs, plan restrictions, parameter interactions, and default behaviors. The tool is complex, but the description is comprehensive.
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 covers all 6 parameters with descriptions (100% coverage), but description adds significant value: credit costs for include modules, plan restrictions (free vs paid), auto-add behavior for fields, default for ip (caller's IP), and interaction between fields/excludes and include. This justifies a score above baseline 3.
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?
Clearly states it is a read-only unified IP lookup via GET /v3/ipgeo. Distinguishes from siblings like lookup_company, bulk_lookup_ip, get_my_ip, lookup_currency by focusing on IP geolocation and mentioning alternatives for ASN, security, and abuse.
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?
Provides explicit when to use (IP geolocation, credit costs, plan limitations) and when not to use (mentions lookup_asn, check_security, get_abuse_contact as alternatives for specific purposes). Also explains default behavior (omit ip for caller's IP).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
15 tool updates
v2.0.0- Changed
bulk_lookup_ip2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / force_refresh / descriptionPrevious value: -"Default false. Set true only when the user asks to bypass cached bulk geolocation data; a successful refresh makes a new upstream request and can consume credits."New value: +"Default false. When true, bypasses cached bulk geolocation data; a successful refresh makes a new upstream request and can consume credits."
- Removed
bulk_parse_user_agent - Removed
bulk_security_check - Removed
check_security - Removed
convert_timezone - Removed
get_abuse_contact - Removed
get_astronomy - Removed
get_astronomy_time_series - Removed
get_timezone - Removed
lookup_asn - Changed
lookup_company2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / force_refresh / descriptionPrevious value: -"Default false. Set true only when the user asks to refresh cached ownership data; a successful refresh makes a new upstream request and can consume credits."New value: +"Default false. When true, bypasses cached ownership data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_currency2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / force_refresh / descriptionPrevious value: -"Default false. Set true only when the user asks to refresh cached currency/country data; a successful refresh makes a new upstream request and can consume credits."New value: +"Default false. When true, bypasses cached currency/country data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_ip2 fields changed- removed
Input schema / additionalPropertiesRemoved value: -false - changed
Input schema / properties / force_refresh / descriptionPrevious value: -"Default false. Set true only when the user asks to bypass cached lookup_ip data; a successful refresh makes a new upstream request and can consume credits."New value: +"Default false. When true, bypasses cached lookup_ip data; a successful refresh makes a new upstream request and can consume credits."
- Removed
lookup_network - Removed
parse_user_agent
2 tool updates
v1.0.16- Changed
bulk_parse_user_agent1 field changed- added
Input schema / properties / uaStrings / items / minLengthAdded value: +1
- Changed
parse_user_agent1 field changed- added
Input schema / properties / uaString / minLengthAdded value: +1
12 tool updates
v1.0.15- Changed
bulk_lookup_ip1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 bypass cached bulk geolocation data; a successful refresh makes a new upstream request and can consume credits."
- Changed
bulk_parse_user_agent1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 bulk user-agent parsing data; a successful refresh makes a new upstream request and can consume credits."
- Changed
bulk_security_check1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 bulk security data; a successful refresh makes a new upstream request and can consume credits."
- Changed
check_security1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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."
- Changed
get_abuse_contact3 fields changed- changed
Input schema / properties / excludes / descriptionPrevious value: -"Comma-separated fields to exclude from response (e.g. phone_numbers,address)."New value: +"Comma-separated abuse fields to exclude from response (e.g. abuse.phone_numbers,abuse.address)." - changed
Input schema / properties / fields / descriptionPrevious value: -"Comma-separated fields to return (e.g. emails,organization). Reduces response size. Works on all plans."New value: +"Comma-separated abuse fields to return (e.g. abuse.emails,abuse.organization). Reduces response size." - changed
Input schema / properties / force_refresh / descriptionPrevious 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 abuse contact data; a successful refresh makes a new upstream request and can consume credits."
- Changed
get_astronomy_time_series1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 astronomy time-series data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_asn1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 ASN data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_company1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 ownership data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_currency2 fields changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 currency/country data; a successful refresh makes a new upstream request and can consume credits." - changed
Input schema / properties / ip / descriptionPrevious value: -"IPv4 or IPv6 address to look up. Omit to check the caller's IP."New value: +"IPv4 or IPv6 address whose country determines the returned currency and country metadata. Omit to use the caller's IP."
- Changed
lookup_ip1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 bypass cached lookup_ip data; a successful refresh makes a new upstream request and can consume credits."
- Changed
lookup_network1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 network data; a successful refresh makes a new upstream request and can consume credits."
- Changed
parse_user_agent1 field changed- changed
Input schema / properties / force_refresh / descriptionPrevious 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 user-agent parsing data; a successful refresh makes a new upstream request and can consume credits."
16 tool updates
v1.0.10- First observed
bulk_lookup_ip - First observed
bulk_parse_user_agent - First observed
bulk_security_check - First observed
check_security - First observed
convert_timezone - First observed
get_abuse_contact - First observed
get_astronomy - First observed
get_astronomy_time_series - First observed
get_my_ip - First observed
get_timezone - First observed
lookup_asn - First observed
lookup_company - First observed
lookup_currency - First observed
lookup_ip - First observed
lookup_network - First observed
parse_user_agent
TDQS
Each tool targets a distinct aspect of IP geolocation: lookup_company for company/ASN, lookup_ip for comprehensive data, bulk_lookup_ip for batch queries, get_my_ip for caller IP, and lookup_currency for currency/metadata. Overlaps are clarified in descriptions, so agents can distinguish them.
All tool names follow a consistent verb_noun snake_case pattern (lookup_company, lookup_ip, bulk_lookup_ip, get_my_ip, lookup_currency), making them predictable and easy to understand.
With 5 tools, the server is well-scoped for an IP geolocation service: single lookup, batch lookup, specific data queries (company, currency), and a utility tool. Neither too few nor too many.
Core IP geolocation workflows are covered, including single and batch lookups with flexible field selection. However, dedicated tools for security, abuse, and ASN lookup are missing; these are only accessible via lookup_ip parameters, which is a minor gap.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
1
Related MCP Servers
- AlicenseAqualityCmaintenanceIP Geolocation MCP server using IP2Location.io API to ease the query of geolocation information.115PythonMIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that provides IP geolocation services using MaxMind's GeoIP2 databases, allowing users to retrieve geographical information for single or multiple IP addresses including country, city, coordinates, and ASN details.GPL 3.0
- AlicenseNot gradedqualityFmaintenanceMCP server for IP geolocation lookups using ipinfo.io, with single, own, and batch queries.1MIT
- AlicenseNot gradedqualityDmaintenanceMCP server providing IP address lookup capabilities. Enables AI assistants to fetch details about public IP addresses or the user's current device IP.32ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/IPGeolocation/ipgeolocation-io-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server