Skip to main content
Glama
Sign In
agentsvc-mcp

agentsvc-mcp

by jakobautomation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

ip_lookup

Resolve public IPv4 and IPv6 addresses to country, city, timezone, ASN, and ISP data for fraud checks, geo-routing, and analytics.

Instructions

IP Geolocation — IP lookup and geolocation: resolve any public IPv4 or IPv6 address to location and network data from a local database (no third-party call, answers in milliseconds): country, country_code, region, city, lat/lon, IANA timezone, continent, is_eu, ASN with organization (isp, org, asn). Use for fraud and bot checks, geo-routing, analytics, or tagging traffic. Invalid, private and reserved addresses are rejected for free. Params: ip (defaults to the caller's IP). IP Geolocation by DB-IP (https://db-ip.com), CC BY 4.0. Cost: $0.0055 USDC per call. Latency p99: 150ms.

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": "<ip>"
    },
    "name": "ip_lookup"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipYesIPv4 or IPv6 address to look up (e.g. '8.8.8.8' or '2001:4860:4860::8888')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the data source (local DB-IP database, no third-party call), latency (p99 150ms), rejection behavior for invalid/private/reserved addresses, pricing, licensing, and the caller-IP default. This is unusually rich behavioral context for a lookup tool.

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?

Front-loads the operation and its scope, then the returned fields, then use cases, then operational metadata in a compact colon-delimited list. Dense but every clause is substantive; only the license/cost/latency footer is arguably padding, though it is genuinely useful for cost-aware selection.

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?

There is no output schema and no annotations, yet the description enumerates the returned fields (country, city, lat/lon, timezone, is_eu, ASN/isp/org), sources, latency, and rejection rules, so an agent has everything needed to call and interpret the tool 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?

Schema coverage is 100%, so the single parameter is fully documented in the schema, which sets the baseline at 3. The description adds one piece of context ('defaults to the caller's IP'), but this mildly conflicts with the schema marking 'ip' as required, so it does not clearly add reliable value.

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?

States a specific verb and resource ('resolve any public IPv4 or IPv6 address to location and network data from a local database') and enumerates the exact fields returned. This clearly distinguishes it from sibling lookups like dns_lookup, whois, and geocode without needing to open any schema.

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?

Provides concrete use cases ('fraud and bot checks, geo-routing, analytics, or tagging traffic') and notes invalid/private/reserved addresses are rejected, which gives the agent a clear sense of valid context. It stops short of naming which sibling to prefer for related lookups (dns_lookup, whois), so there is no explicit when-not guidance.

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

Deploy Server

Other Tools