Look up IP addresses and AS numbers for VPN, proxy, Tor, owner and abuse contact in ipapi.is.
Scored across 3 tools
The three tools target clearly distinct inputs: a single IP, a single AS number, or a batch of up to 100 IPs/ASNs. Although bulk lookup can technically cover a single IP, the descriptions make the keyed-result format and quota cost explicit, so an agent can pick correctly.
All tools share the ipapi_ prefix and are snake_case, which is predictable. There is a minor ordering inconsistency: ipapi_bulk_lookup puts the modifier before the verb, while ipapi_lookup_asn and ipapi_lookup_ip follow verb_noun.
Three tools is on the lean side but well matched to a focused IP/ASN lookup API; each tool covers a distinct lookup mode. It is slightly thin in that there is no auxiliary tool (e.g., quota/usage check), but nothing feels redundant.
The surface covers the core lifecycle of the domain: single IP lookup, single ASN lookup, and batch lookup for efficiency. Minor gaps exist, such as no way to inspect remaining quota or validate/resolve inputs before spending requests, but agents can work around these.
Look up up to 100 IP addresses and AS numbers in one ipapi.is request. The result is an object keyed by the entries you sent. Every entry spends 1 request of your ipapi.is quota. Duplicates and invalid entries are dropped silently by ipapi.is.
| Name | Required | Description | Default |
|---|---|---|---|
| entries | Yes | IP addresses and AS numbers (AS15169), 1 to 100 entries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description goes further by disclosing that each entry consumes one unit of ipapi.is quota and that duplicates and invalid entries are dropped silently. Those are non-obvious behaviors an agent could not infer from structured fields. It stops short of covering failure modes such as partial errors or whether the whole request fails when one entry is bad.
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?
Three short sentences, each carrying distinct information: what it does, what comes back, and the quota/dedup semantics. Front-loaded with the core action and no filler.
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?
No output schema exists, and the description compensates by explaining the return value is an object keyed by the sent entries. With a single fully documented parameter and readOnlyHint covering safety, nothing an agent needs to invoke this correctly is missing.
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%, so the baseline would be 3, but the description adds meaning beyond the schema: entries may be IPs or AS numbers, the response is keyed by the submitted entries, and invalid/duplicate inputs are silently discarded rather than rejected. That last point materially changes how an agent should interpret a missing key in the result.
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?
States a specific verb and resource ('Look up ... IP addresses and AS numbers') plus the batching scope ('up to 100 ... in one ipapi.is request'), which immediately separates it from the single-entry siblings ipapi_lookup_ip and ipapi_lookup_asn. It also says the result is keyed by the entries sent, so the shape of the operation is clear before 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bulk nature and the 100-entry cap imply that this is the tool for many lookups, and the quota note ('every entry spends 1 request') hints at cost trade-offs. But there is no explicit instruction to use ipapi_lookup_ip or ipapi_lookup_asn for single entries, nor any guidance on when batching is discouraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one autonomous system (AS number) in ipapi.is: organization, registry, type, country and announced routes. Spends 1 request of your ipapi.is quota.
| Name | Required | Description | Default |
|---|---|---|---|
| asn | Yes | AS number, with or without the AS prefix, for example AS15169 or 15169. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description adds the non-obvious cost signal "Spends 1 request of your ipapi.is quota," which matters for a metered API. It does not disclose behavior for invalid or unannounced ASNs (empty result vs. error), which is the main remaining gap.
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 short sentences, front-loaded with the action and returned fields, followed by the quota cost. No filler, no repetition of the name or title.
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 usefully enumerates the returned fields (organization, registry, type, country, announced routes) and discloses quota cost, which is enough to call the tool correctly. Only error/empty-result behavior for a nonexistent ASN is left unspecified.
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 description coverage is 100% and the single parameter documents the AS prefix format with an example, so the schema carries the semantic load. The description only restates the resource as "AS number" and adds no format or normalization detail beyond the 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?
States a specific verb and resource ("Look up one autonomous system (AS number)") and enumerates the returned attributes: organization, registry, type, country, announced routes. The word "one" plus the ASN focus clearly separates it from the sibling tools ipapi_bulk_lookup and ipapi_lookup_ip without needing to name them.
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?
Usage is only implied: an agent can infer this is the tool for a single-ASN lookup, and the quota sentence hints it is a paid call worth conserving. There is no explicit when-to-use guidance, no statement of when to prefer ipapi_bulk_lookup (multiple ASNs) or ipapi_lookup_ip, and no mention of error conditions for an unknown ASN.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one IPv4 or IPv6 address in ipapi.is: owner company, network, abuse contact, location, and the flags is_datacenter, is_vpn, is_proxy, is_tor, is_abuser, is_mobile, is_crawler. Spends 1 request of your ipapi.is quota.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | IPv4 or IPv6 address, for example 8.8.8.8. | |
| all_companies | No | Return every WHOIS record that covers the address (company becomes an array). | |
| geolocation_sources | No | Add location.geofeed: the geofeed URLs used to locate the address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to argue safety. It does add genuine context beyond annotations: the quota cost ("spends 1 request of your ipapi.is quota") and the concrete field set returned, which is the main thing an agent needs for a read-only lookup. Missing only error/empty-result behavior for a 5.
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, no filler, and the resource/scope is front-loaded before the quota caveat. Every clause carries information an agent can act on.
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 enumeration of returned fields (including the individual is_* flags) does the job of describing the response shape, which is the main completeness risk here. What is left thin is the effect of the two optional boolean parameters, though the schema covers them well.
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 description coverage is 100%, so all three parameters are already documented, making the baseline 3. The description adds no meaning for the optional all_companies or geolocation_sources switches; its field list reflects the default response, not the parameter effects.
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?
States the specific verb (look up), resource (one IPv4/IPv6 address), the provider (ipapi.is), and enumerates exactly what is returned (company, network, abuse contact, location, and seven flags). The word "one" implicitly contrasts with the bulk sibling, and the ASN sibling is clearly a different resource, so an agent can distinguish them without opening schemas.
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?
The single-address scope and the quota cost hint at when this is appropriate versus ipapi_bulk_lookup, but the routing is only implied — it never names the alternative or says "for multiple addresses use bulk." No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ipapi_bulk_lookupipapi_lookup_asnipapi_lookup_ipResolves IP autonomous system numbers (ASN) and geographic coordinates.
IP geolocation, ASN and network data, plus VPN, proxy and Tor detection. ASN tools need no key.
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Look up the country and ASN of IP addresses (DB-IP Lite). $0.001/call via x402.
Add one secure layer between your agents and this server.
