This is an MCP server, not a REST API — you point an AI client at it once and the tools appear inside your assistant. No key is needed to start; adding one raises the limits and unlocks extra data sources.
Note the key is mcpServers, not servers — clients
differ, and using the wrong one means the server is simply never read. Drop the
headers block to run anonymously.
On a shared corporate network, use an API key. The anonymous tier is rate-limited per client IP, and everyone behind one office NAT or proxy egress shares a single bucket — a handful of colleagues can exhaust 10 requests/minute between them, which presents as the server being intermittently unavailable rather than as a quota message.
Then just ask: “triage 203.0.113.5”, “are any of these log IPs worth worrying about?”, or “should I block this ASN?”
Not supported: claude.ai web Custom Connectors, which require OAuth 2.1 with dynamic client registration. Bearer keys cover Claude Code, Copilot, and the API connector.
Every triage answer returns two independent verdicts, because collapsing them into a single “threat score” throws away what you need to decide a response.
| Axis | Values | Question |
|---|---|---|
| network_type | residential, mobile, business, hosting, vpn, privacy_relay, tor, bogon, unknown | What kind of connection is this? |
| risk | clean, suspicious, flagged, unknown | Is it behaving badly? |
They answer different questions and the combination is what matters:
| Combination | Meaning | Response |
|---|---|---|
| hosting | clean | A server. Scanner or bot — block cheaply, low collateral. |
| residential | flagged | A compromised home machine. Block the /32 or /24 — not the ASN. |
| vpn | clean | A privacy-conscious real user. Policy call, not a security one. |
| tor | any | Origin is unknowable. Policy call; risk doesn't change the answer. |
The flagship. One call fans out to geolocation, ASN, classification, reverse DNS, FBI IC3 provenance, BGP routing, and (with a key) third-party reputation feeds — then returns both axes with the specific evidence behind each.
| Section | Contents |
|---|---|
| Verdict | Risk + network type + confidence, with the ASN and country. |
| Why | Each signal that fired, graded high / medium / info, with its source. |
| Routing | Covering prefixes, origin AS, peers seen, MOAS flag. |
| Enrichment | Open ports, CVEs, blocklist listings, abuse reports. |
| Caveats | What the answer does not tell you. |
For more than a handful of addresses use ip_triage_bulk. For registry and abuse-contact detail use ip_context.
Triage up to 100 addresses in one call and get a table ranked worst-first. Paste a log, an alert, or a firewall export and the addresses worth investigating float to the top. Far cheaper than a loop of single lookups.
Batches over 10 addresses use first-party data only, to protect a rate-limited shared quota — the output says when that happened.
Answers the question triage leaves open: block it at what scope, and what else goes down with it? Accepts an IP, a CIDR, or an AS number.
| Field | Description |
|---|---|
| Recommendation | The scope to block — single address, covering prefix, or ASN — and why. |
| Blast radius | How many addresses and prefixes that scope actually covers. |
| Warnings | Fires when the target is a consumer ISP, shared infrastructure, or a privacy relay. |
| Rule | Paste-ready iptables, nftables, and nginx directives. |
It refuses to recommend an ASN-wide block on a residential or mobile network
unless you pass allow_wide_block. Blocking a consumer ISP because a few of
its subscribers are infected is a tens-of-millions-of-addresses mistake, and the tool
will say so rather than hand you the rule.
Deep detail when triage isn't enough: the PTR record and what its pattern implies, inferred point-of-presence from carrier reverse DNS, the full covering-prefix routing view, the registry record, and the network's abuse contact. Use it to file an abuse report or to explain why a classification came out the way it did.
Is a whole network bad? Reports Spamhaus ASN-DROP membership, the count of FBI IC3 indicators attributed to the AS, the curated network kind, and how many addresses an ASN-wide block would affect. Warns when the AS carries ordinary end users.
Who operates an AS number: organisation, registry record, abuse contact, announced prefix counts, the curated network kind, and a plain-language description of what the network actually does where one exists.
Find an AS number from whatever you have — an organisation name, a CIDR, a bare IP, or an AS number. The input type is auto-detected. Returns up to 25 matches.
Who announces a prefix, how widely it is seen across BGP collectors, and whether more than one AS originates it (MOAS). A MOAS result can be legitimate — anycast, multi-homing — or can indicate a route hijack; the tool names the origins so you can judge.
FBI IC3 advisory indicators for an IP or an ASN, with advisory titles, publication dates, and links to the source advisories.
IC3 listings are provenance, not a verdict. Advisories routinely include victim machines and sinkhole infrastructure alongside attacker-controlled hosts, so a listing on its own does not mean an address is hostile. Read the advisory before drawing a conclusion.
The evidence needed to decide what kind of network an ASN is — hosting, residential, mobile, transit, education, business, government, or VPN. Returns the RIPE RIS view (announced prefixes, addresses, and observed neighbours), the registry record with registration dates, who each sampled prefix is actually registered to, and sampled reverse DNS with a reverse-zone delegation check.
It returns evidence, not a verdict. The org name, the registry handle, and PeeringDB's self-reported fields are evidence in neither direction, and a confidently wrong kind is worse than no answer. The tool gives you what was observed plus the traps that apply to it; you make the call.
Two properties worth knowing. A failed lookup never renders as a number —
counters come back as UNAVAILABLE (fetch failed — NOT zero), and
the tool refuses to quote its own counters when they contradict the prefix list.
And where an rDNS sample comes back empty it queries the reverse zone's NS records,
which separates an operator that never took the zone from addresses that are simply
unnamed. “No PTRs on the addresses sampled” is a sample, not a finding.
depth: "quick" stops after four calls (holder, counters, prefix list,
registry record) and costs 2 units. The default "full" adds the
per-prefix registrant and reverse-DNS evidence and costs 6, because it is roughly 25
requests to third-party registry and DNS servers.
Triage a batch of AS numbers into a worklist: which are announced, which already
have a curated kind, which already have a written description card, and which are
reserved placeholders with no organisation to describe. Use it to find the ASNs
worth researching before spending asn_evidence calls on them.
Touches only first-party services, so it is cheap to run across a whole range. Capped at 100 ASNs per call and charged 1 unit each.
Check a determination against the curation rules and, when it passes, render the
exact list entry. This is the part of the workflow that is mechanical:
only high confidence enters a list; only the safe-to-grow kinds
(education, residential, hosting, mobile, vpn) grow from research, because business,
government and transit are deliberately small sets curated from production traffic;
and an ASN already in a list is a reclassification needing review, not an addition.
Run it on every determination, including the ones you expect it to refuse. Reporting is not a lesser outcome — these lists are trusted precisely because the low-confidence answers were kept out of them.
How old the underlying data is and which sources are currently reachable: the BGP snapshot timestamp and collectors, the classifier image version, per-source health, and your remaining quota.
Costs no quota — call it freely. The classification dataset is rebuilt when its inputs change rather than on a fixed schedule, so for fast-rotating infrastructure like Tor exits it can lag. This is how you find out by how much.
Two independent limits: a per-minute burst cap (abuse protection) and a daily quota
in units, weighted by how much work a call actually does. Most tools cost 1
unit; bulk triage and asn_sweep_probe cost 1 per item;
asn_evidence costs 6 (2 at quick depth) because it fans
out to third-party registry and DNS servers; dataset_status costs
nothing.
| Tier | Burst | Daily units | Data sources |
|---|---|---|---|
| anonymous | 10/min | 200 | First-party only — no key needed |
| free | 60/min | 5,000 | + open-port intelligence, blocklist checks |
| pro | 240/min | 50,000 | + abuse-reputation and threat-pulse feeds |
Tiers follow what each data source costs to serve. First-party data is ours. The free tier's extra feeds are free upstream but rate-limited. The pro tier's feeds have hard daily caps we pay for, so they sit behind a budget — when it is spent, triage continues on first-party data and tells you so rather than silently returning less.
Exceeding a limit returns a readable message with a retry delay, not a protocol error, so your assistant can back off on its own.
These limits are stated in every response too, so an assistant summarising for you carries them through.
| Limit | Why it matters |
|---|---|
| “Clean” is not “trustworthy” | It means no source flagged the address. Absence of evidence is not evidence of absence. |
| “Unknown” is not “clean” | If nothing answered, the tool says so rather than implying safety. |
| Confidence is uncalibrated | It is a normalised weight ratio, not a probability. Don't threshold on it. |
| No behavioural data | Every signal is list membership. It cannot tell you an address started attacking you 20 minutes ago. |
| Shared addresses | Consumer and mobile networks put many subscribers behind one address via CGNAT, so activity may not be attributable to one user. |
| Data can lag | Call dataset_status before relying on a time-sensitive answer. It's free. |