Connect an AI assistant to BGPScout's internet-routing intelligence: search ASNs/IXPs/facilities/CDNs/traceroutes, look up IPs & prefixes, find sales prospects, and take account actions.
https://bgpscout.io/mcp → authorize (OAuth).
https://bgpscout.io/mcp (spec at /mcp/openapi.json), Auth = Bearer with an API key from /account (or header {"X-API-Key":"KEY"}).
list_tools from your assistant to enumerate everything on demand.| list_tools | Discover all available BGPScout tools, grouped by category. Call this first to see the full capability set (search, lookup, prospecting, intelligence, account actions). Optional: category to filter. |
| lookup_asn | Look up detailed information about an ASN, including its PoP/facility count and IXP count. Location caveat: the record's latitude/longitude are the centroid of the registered POSTAL CODE, never the street address; the `location` field gives the resolved point with its provenance and precision, which may be a geocoded address, a data-centre facility, an exchange, or a country centroid. Do not report an approximate position as an address. |
| search_asns | Search ASNs with rich filters (name/asn, country, state, city, rir, traffic level, IPv6, on-IX, MANRS, RPKI, network type, asn_type flag, CDN provider, min PoPs/IXPs) |
| bulk_lookup_asns | Summarize several ASNs at once (name, country, traffic, PoPs, IXPs) in one call |
| compare_asns | Compare multiple ASNs side by side - PoPs, IXPs, prefixes, routing quality, announced IPv4 address total, BGP downstream count and the owning registry organisation. Same columns as the /compare page. CAVEATS: `ipv4_addresses` is the merged union of announced space (more-specifics collapsed), and null means the network announces no IPv4 - it is not zero. `bgp_downstream_networks` comes from AS_PATH adjacency, which does NOT label relationships: an adjacency may be transit OR peering, and it is not proven hierarchy. `org` is resolved through the RIR allocation record, not asn.org_id. |
| get_asn_history | Historical trends for an ASN: facility/IXP counts, total IXP capacity, and prefix counts over time |
| get_asn_neighbours | Every ASN observed adjacent to this one in BGP AS_PATHs, in BOTH directions - this is the tool for "who does X peer with". CAVEATS: AS_PATH does NOT label relationships, so an adjacency may be transit OR settlement-free peering OR a sibling; it is not proof of a commercial arrangement. Direction is "seen nearer/further from the origin", an observation and not proven hierarchy. Built from a single RouteViews collector, so a sparse result is a statement about collector visibility, not about the network. For networks that merely share an exchange - opportunity rather than observation - use get_asn_ixp_colocated instead. |
| get_asn_ixp_colocated | Networks present on at least one of the same internet exchanges as this ASN, from PeeringDB membership, ranked by shared exchanges. NOT A PEER LIST: co-presence on a fabric is a peering OPPORTUNITY, and two networks can share an exchange and exchange no traffic. Covers only ASNs with a PeeringDB record and a listed port. For neighbours actually observed in BGP, use get_asn_neighbours. |
| get_asn_facilities | List the data-center facilities/PoPs a network (ASN) is present in, with a total count. Use this to answer 'how many PoPs/facilities does ASN X have'. Sourced from PeeringDB. |
| get_asn_ixps | List the Internet Exchange Points (IXPs) an ASN peers at, with port speeds and total interconnection capacity |
| get_asn_cdn_caches | List the CDN edge caches hosted inside an ASN, grouped by provider with cache locations. Located providers: Google GGC, Netflix OCA, Meta FNA, Akamai. AWS CloudFront, Microsoft and Apple caches are reported separately in providers_present_without_locations - we know the ASN hosts them but never collected node locations (#191). total_caches counts LOCATED nodes only, so an ASN hosting only Apple caches reports 0 there and names Apple in that list; do not read total_caches: 0 as 'no caches'. |
| get_transit_providers | An ASN's upstreams from two sources: traceroute-observed Tier-1 handoffs (narrow, ~490 ASNs, but carries the handoff city) and BGP AS_PATH adjacency (79,250 ASNs, no location). AS_PATH does not label relationships, so a BGP adjacency may be transit or peering. |
| find_ddos_protected | Networks observed sitting behind a blanket DDoS scrubbing provider (Akamai Prolexic, Cloudflare Magic Transit, Global Secure Layer, Path, Imperva). Their routes were seen transiting a provider whose product IS the BGP announcement, so the service was live in the routing snapshot - this is evidence, not a contract, and absence does not mean unprotected. Distinct from the 'ddosm' tag, which means a network SELLS mitigation. Set exclusive=true for networks whose only upstreams are scrubbers. |
| get_asn_prefixes | List the IPv4/IPv6 prefixes a network (ASN) announces, with counts |
| get_prefix_counts | Get IPv4/IPv6 prefix counts with history |
| get_asn_ipv6_reachability | Evidence that a network's IPv6 actually WORKS, not just that it announces v6 space (#54). Returns the strongest level observed and every supporting observation with its date and vantage point. Levels, weakest to strongest: announced (announces v6 prefixes - NOT reachability evidence) < ixp_port (v6 configured on an IXP port, PeeringDB self-report) < aaaa (a name of theirs resolves AAAA) < path (a router in their own v6 space answered a traceroute) < icmp6 (their own space answered our ping) < tcp6 (a TCP handshake completed into their own space). An unconfirmed result means we have not observed it working - most ASNs have never been probed - and NEVER means the network has no IPv6. |
| lookup | Everything we know about one IPv4 address, IPv6 address, CIDR or hostname, in a single call. Type is detected - no separate tool per input shape - and IPv6 is first-class. sections filters the payload: routing (covering prefix, origin ASN, more-specifics, bogon status), geo (resolved location with EVERY candidate source and which one won), registration (RIR allocation, registered org, contacts), rpki (Valid/Invalid/NotFound against the ROA set), rdns (PTR for an address, observed forward records for a prefix). Every section carries its own source and observation date so you can say how confident you are rather than presenting a guess as fact. Prefer this over lookup_ip and lookup_prefix, which answer narrower slices of the same question. |
| lookup_ip | Geolocate an IP address (city/country/coordinates) and, when available, the ASN that announces it |
| lookup_prefix | For an IPv4 CIDR (e.g. 8.8.8.0/24), the ASN that announces the covering prefix |
| get_asn_bogons | Bogon prefixes an ASN announces - IANA special-use space (RFC 1918, loopback, documentation, multicast, …) or space no RIR has delegated. Omit asn to list the ASNs announcing the most bogons. severity: high (special-use) | medium (undelegated) | low (registry holds it reserved; advisory only) |
| search_allocations | Search RIR address allocations - every IPv4/IPv6/ASN delegation the five registries published, with the date each block was handed to an organisation. Use for 'what has ARIN allocated recently', 'which blocks were assigned in <country> since <date>', or to date a prefix. Newest first by default. |
| get_asn_allocations | Every IPv4/IPv6 block the registry delegated to an ASN's organisation, oldest first, plus the date the ASN itself was delegated. Each block carries its provenance: 'direct_allocation' (issued by the registry to this org) or 'transferred', with the selling organisation, the transfer date and whether it was a market transfer or a merger/acquisition. IMPORTANT: a transferred block's alloc_date is the date it changed hands - the registry overwrites the delegation record on transfer - so it is not evidence the address space is new. Use for 'when did AS X get its address space', 'did AS X buy its space or was it allocated', or to see a network's growth in allocations. |
| search_transfers | The RIR transfer logs: IPv4/IPv6 blocks and ASNs that changed hands between organisations, naming both parties. transfer_type distinguishes a market transfer (the block was bought or leased) from a merger/acquisition (the holding company itself was acquired). Use for 'who has been buying address space', 'where did this prefix come from', 'what has <company> sold', or 'which ASNs were acquired in <year>'. Covers ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC. |
| lookup_rir_org | A registry organisation and everything delegated to it - its ASNs and all its IPv4/IPv6 blocks. Identify it by ASN, by a prefix/IP it holds, by name, or by its registry org key. Use for 'what else does the org behind AS X hold'. |
| find_near | Find facilities, IXPs and CDN caches within a radius of a location (latitude/longitude in degrees, radius in km) |
| find_networks_near | Networks (ASNs) with IP address presence in an area - the geolocated IP footprint behind the IP-density heatmap. Use for 'which networks have IPs in/around <place>'. Ranked by number of geolocated IPs. Give either latitude+longitude (+radius_km) or a city and/or country. Coverage: ~6.5k ASNs with enough geolocated space to map; a network absent here may still operate there. |
| get_asn_density | The per-location IP-density breakdown behind the prospect map for one ASN. Requires Sales access. Locations are geolocated address-space observations, not registered offices or facilities. |
| get_asn_geo_prefixes | Which address space an ASN has in a place, at PREFIX granularity - the inverse of find_networks_near (which goes place -> ASNs). Give an asn alone for its full per-location prefix breakdown, or add city/country or latitude+longitude+radius_km to constrain it. Returns the announced CIDRs with the geolocated IP count of each, not just totals. Coverage differs by field: coordinates and ip_count come from the per-prefix footprint (79,121 ASNs), while city/region/country come from the per-ASN city footprint (6,515 ASNs) - so an ASN can have located prefixes with NO city label, and a city filter cannot see it. An empty result means we have no geolocated space for that ASN, NEVER that the network is absent from the area. Coordinates are a 0.1-degree grid cell (~11km), not a precise centroid. |
| find_transit_near | Networks (ASNs) observed taking transit handoffs in an area, and from which Tier-1, derived from traceroute data. Use for 'which ASNs have transit locations in/around <place>'. Give latitude+longitude (+radius_km) or a city/country. Coverage is narrow - only ~490 ASNs across 11 Tier-1 providers currently have observed handoffs, so absence is not evidence of absence. |
| find_upstreams_near | Networks (ASNs) present in an area together with their BGP upstreams. Use for 'which networks around <place> buy transit, and from whom', or with upstream_asn for 'who near <place> is behind <provider>'. Wide coverage (79,250 ASNs have upstream data) but the two halves come from different sources: location is PeeringDB facility presence, upstreams are BGP AS_PATH adjacency - an upstream listed here was NOT observed handing off in that city, and AS_PATH cannot distinguish transit from peering. Use find_transit_near instead when the handoff location itself must be real. |
| find_networks_at_facilities_near | Networks (ASNs) with a PeeringDB data-centre/PoP presence in an area, and which facilities. Use for 'who is in a data centre in/around <place>' or to find cross-connect candidates in a metro. Give latitude+longitude (+radius_km) or a city/country. |
| find_networks_on_ixps_near | Networks (ASNs) peering at IXPs in an area, with port capacity. Use for 'who is reachable on an exchange in/around <place>' or to find peering candidates in a metro. IXPs are located via their facilities. Give latitude+longitude (+radius_km) or a city/country. |
| get_events | The change feed: ASNs newly registered, IP blocks newly allocated, resources transferred between organisations, networks joining/leaving IXPs, IXP port-speed changes, facility presence added/removed by a NETWORK, an EXCHANGE becoming present at or leaving a facility, a NETWORK gaining or losing a CDN cache, an EXCHANGE first appearing in or being delisted from PeeringDB, and a FACILITY doing the same (all #150). Filter by ASN, country, IXP, facility, event type and date range. Use for 'what changed for AS X', 'who joined IXPs in <country> recently', 'who bought address space recently', or 'what new networks appeared since <date>'. CAVEATS you must pass on: ixp_facility_added/ixp_facility_removed start EMPTY - ix_facility has no date column, so the history table took its first observation on 2026-07-27 and zero events means 'nothing has moved since we started looking', not 'no exchange has ever gained a facility'. cdn_cache_added/cdn_cache_removed start EMPTY for the same reason - cdn_cache_node is current state only, its first baseline was taken on 2026-07-27, and its granularity is the (ASN, programme) pair, so a cache farm growing from 3 nodes to 4 emits nothing. ixp_first_seen/ixp_delisted and facility_first_seen/facility_delisted are the EXCEPTION and do NOT start empty - they are derived from the monthly CAIDA PeeringDB archive and carry 2,347 events from 2010-08-01, though the series is monthly with three gaps so 111 delistings have a window up to five months wide. The facility pair adds 6,978 events on the same basis, derived from a first-seen/last-seen WINDOW rather than per-snapshot presence, which means it cannot express a gap and has no 'relisted' - measured at 6 disagreements in 1,965 when the same method is checked against exchanges. And ixp_speed_changed's 1,364 existing rows were all derived on 2026-07-25 from a membership table that has since been replaced; the current builder re-derives none of them. |
| find_growing_networks | Networks ranked by how fast they are GROWING or DECLINING - net new data-centre facility presence, new IXP presence, and new address space over a 30/90/365-day window. Combine with a location (latitude+longitude+radius_km, or city/country) to answer the sales question directly: 'which fast-growing networks have a presence where I can reach them'. Set direction=declining to find networks contracting. Caveat: IXP membership history only starts 2026-04, so IXP figures are not yet a true year-over-year comparison. |
| get_asn_growth | Growth/decline detail for one ASN: net facility and IXP presence change and new address space over 30/90/365 days, with current totals for context. |
| get_ixp_info | Search Internet Exchange Points by name/country/operator, with min_peers/min_facilities filters. Each result carries its operator (the PeeringDB organisation that runs it - always present) and, where we could establish one, the registry organisation behind it with the method and confidence that link rests on. |
| get_ixp_members | List the ASNs that peer at a given IXP (by its PeeringDB id from get_ixp_info) |
| get_facility_info | Search data centers/facilities by name/country/city, with a count of how many ASNs are present |
| get_facility_members | List the ASNs present in a data-center facility (by its PeeringDB id from get_facility_info) |
| get_facility_events | One building's change feed and the exchanges inside it - the same data as the /facilities/<id> page (#27). Returns the facility record, the IXPs physically in it, and the merged event log for both, with counts so a capped feed is never mistaken for the total. Events reached via an exchange are labelled: an IXP join at a multi-site exchange is not a statement about this one building. |
| find_near | Find facilities, IXPs and CDN caches within a radius of a location (latitude/longitude in degrees, radius in km) |
| search_cdn_caches | Find CDN edge caches by country/provider/city. provider: ggc | oca | fna | akamai | aws_cloudfront | microsoft | apple. Node-level LOCATIONS exist only for ggc, oca, fna and akamai; for aws_cloudfront, microsoft and apple we know which ASNs host their caches but never collected node locations (#191), so those providers return the hosting ASNs with location_data='not_collected' instead of an empty list. An empty result for them means WE DID NOT COLLECT IT, never that the caches do not exist. |
| search_traceroutes | Search traceroutes by source/dest ASN, country, destination host, category, boomerang, or quality score |
| get_traceroute | Get one traceroute with its full hop-by-hop path |
| get_my_traceroutes | Your own submitted traceroute batches, or the traces in one owned batch. Unlike search_traceroutes, this reads your private submission corpus and always scopes by your user_id. |
| get_asn_traces | Get traceroute data for an ASN |
| get_route_heatmap | Busiest city-to-city links observed in traceroute data (internet route heatmap) |
| get_country_scoreboard | Countries ranked by routing quality (boomerang rate, cross-border rate) |
| get_tier1_comparison | The 11 curated Tier-1 transit providers, ranked by BGP-wide downstream network count (RIB-derived, so the order does not depend on where our probes are). Returns each provider's 90-day traceroute figures (traces, destinations, source networks, path length, and the latency it adds between its own first and last observed hop) plus traceroute-observed customer networks and handoff cities from a separate 180-day weekly snapshot. Same population, window and ranking as the /traceroutes/analysis/tier1 page. Traceroute counts are corpus floors, not traffic shares |
| get_common_routes | Most frequently observed source-ASN → destination-ASN traffic flows |
| get_boomerang_stats | Get boomerang routing stats for a country |
| find_co_located | Networks that share a data-center facility with a given ASN (cross-connect / peering candidates) |
| find_transit_customers | Networks downstream of a given transit ASN (reverse of get_transit_providers). Returns traceroute-observed handoffs (with cities) and BGP AS_PATH downstreams (far wider coverage, no location, and adjacency may be peering rather than transit). |
| get_org_asns | List all ASNs under the same organization. Pass an asn (finds its siblings) or an org_id. |
| find_prospects | Find sales-prospect networks by use case. use_case: transit | colocation | ixp | ixp_competitive | network_health. Same engine as the web prospecting tool. Dismissed/tagged leads are hidden by default, matching /prospect; set hide_dismissed=false to include them. |
| find_long_haul_customers | Networks with long-haul routes (potential transport/backbone customers) |
| find_transport | Networks observed carrying long-haul traffic between two regions (transport/backbone providers). Filter by from/to country or city. |
| get_cloud_connect_prospects | Networks that are candidates for cloud on-ramp / direct connect |
| get_prospect_tags | Your saved prospect tags (customer/prospect/not_interested) on ASNs. A dismissed lead is stored as the not_interested tag, so this is also the review list for anything dismissed at /prospect. |
| get_clients | Your CRM clients/accounts and their member ASNs and IXPs - the list behind /prospect/clients. This is where a client_id for add_asn_to_client comes from. Scoped to your own clients plus your sales org's, exactly as the web page is. |
| get_search_templates | The seller profile, linked assets and target countries used to personalize /templates search recommendations. Requires access level 100, matching the page. |
| generate_outreach_templates | Generate the personalized routing, peering and general outreach copy shown by /sales-lab/outreach for an ASN. Admin only, matching that page. |
| get_asn_lead_score | Sales lead score and opportunity signals for an ASN |
| get_lead_reasons | Why an ASN is flagged as a sales lead - opportunity type and signal breakdown |
| get_buy_signals | Networks showing ready-to-buy signals, ranked by lead score (sales lab) |
| get_rpki_opportunities | Networks without RPKI/ROV (security upsell opportunities) |
| get_industry_verticals | Networks by industry vertical with lead scores. vertical: isp | gov | cdn | corp | uni | biznet | mobile |
| get_new_networks | Recently registered ASNs (new networks), optionally by country |
| get_growing_networks | Fastest-growing networks by facility/IXP expansion |
| get_prefix_growth | Networks with the largest recent IPv4 prefix growth |
| get_country_benchmark | Per-country network/routing benchmark stats (network counts, IPv6 adoption, IX presence) |
| get_top_networks | Top networks in a country ranked by a metric. by: traffic | prefixes | facilities | ixps |
| domain_lookup | Look up which ASN is associated with a domain |
| search_domains | Search the domain→ASN index (which networks host which domains) |
| get_domain_intel | Domain intelligence scan results for a domain (hosting ASNs and records) |
| get_watchlist | Everything you are watching. Each row carries subject_type ('asn' or 'ixp' - the two types the UI can create today) and subject_id; `asn` is filled in only on an ASN row and is null otherwise, which means 'not about a network', not AS0. Adding an IXP to the watchlist is done in the portal at /ixps/<id>, not from MCP yet. |
| get_alerts | Your recent alerts/notifications |
| get_saved_searches | Your saved searches |
| get_auto_scout | Your auto-scout (auto-run saved searches) with the latest result counts AND the identifiers that arrived or left since the previous run - so "3 new" can name the three (#153) |
| get_favorites | Your favorite ASNs |
| get_org_customers | Auto-detected customers for your org, split by what the detection actually means. `customers` are networks downstream of the org's OWN ASNs - strength=observed is a traceroute-observed transit handoff (strongest), strength=adjacency is BGP AS_PATH only and MAY BE PEERING RATHER THAN TRANSIT. `nearby_networks` are ASNs at an IXP or facility the org linked: proximity, not commerce - prospects, not customers. An empty customers list means nothing was observed, not that the org has no customers. |
| get_org_prospects | Get performance targeting prospects |
| get_org_assets | Get linked ASNs, facilities, IXPs |
| get_seller_profile | Your sales org seller profile and its full colo footprint (#56): facility-level service areas, metro/city-level service areas, and the buildings PeeringDB already places the org in as read-only suggestions. A footprint declared only by metro is a real footprint - do not read an empty service_areas as "none". |
| add_to_watchlist | Add an ASN to your watchlist |
| remove_from_watchlist | Remove an ASN from your watchlist |
| list_watch_rule_types | The alert-rule vocabulary: every subject/event combination a rule can be built on, the optional conditions each supports, and - just as importantly - the combinations that are deliberately WITHHELD because nothing in the system emits the event, each with the silent table and the reason. Call this before create_watch_rule. A rule type that is not listed as offered cannot be created, and asking for one returns the reason rather than an empty result. |
| create_watch_rule | Create an alert rule. rule_key comes from list_watch_rule_types; subject_value is the ASN, the PeeringDB exchange or facility id, or a registry key like "arin:C12345678"; predicate_key and predicate_value are optional and must be one of the conditions that rule type supports; frequency is daily | weekly | monthly. Evaluated by the nightly job, so the first result arrives with the next run - a new rule subscribes you to its subject's FUTURE and never replays history. Requires the Search Scout feature. |
| list_watch_rules | Your alert rules and your org-shared ones, each with the outcome of its last evaluation. A status of "unevaluable" means the rule could NOT be run - it is not zero matches. A status of "never_observed" means the rule's event types have never produced a row anywhere, which is different again. |
| delete_watch_rule | Delete one of your alert rules by id, with its evaluation history. Scoped to rules you own or your org shares; a rule you cannot see is reported as not found. |
| tag_prospect | Tag an ASN as a sales prospect. tag: not_interested | prospected | customer | high_priority |
| untag_prospect | Remove your prospect tag from an ASN |
| save_search | Save a search by name and its URL (e.g. "/asns?country=CA&cdn=akamai") |
| create_auto_scout | Create an auto-scout that re-runs a saved search on a schedule and alerts when the result count changes |
| set_auto_scout_frequency | Change an auto-scout run frequency (weekly | monthly) by its id |
| delete_auto_scout | Delete one of your auto-scouts by id. Requires access level 100 and is scoped to your user_id. |
| create_client | Create a CRM client/account in your sales org. tag: customer | prospect | not_interested | partner | high_priority |
| add_asn_to_client | Add an ASN to one of your CRM clients (client_id from get_prospect_tags or create_client) |
| mark_alerts_read | Mark your alerts read - all of them, or one by alert_id |
| archive_alerts | Archive and mark read all alerts belonging to you and your sales org, matching /alerts/archive-all. |
| update_seller_profile | Update your sales org seller profile (sells_transit/colocation/transport/ixp/consulting/cloud_connect booleans; transit_max_speed, transit_focus, transit_regions, target_market_size, notes) |
| set_service_area | Add/update or remove a facility-level service area for your sales org and synchronize the seller-profile map projection. Requires Sales access. |
| update_org_asset | Link or unlink an ASN, facility or IXP to your organization. Requires the same level-250 access as /org and rejects read-only org members. |
| update_org_customer | Acknowledge or dismiss an auto-detected customer belonging to your organization. Requires the same level-250 access as /org and rejects read-only org members. |
| run_sql | Execute a read-only SQL SELECT query (admin only) |
| get_system_stats | Overall system statistics |
| get_data_coverage | Data coverage scores per country |
| get_asn_peers | DEPRECATED ALIAS for get_asn_ixp_colocated - despite the name it returns IXP co-presence, not peers. Prefer get_asn_neighbours for observed BGP adjacency, or get_asn_ixp_colocated for shared exchanges. |
With 108 tools, you can narrow what an assistant loads (e.g. OpenWebUI's Function Name Filter List):
lookup_asn,lookup_ip,lookup_prefix,get_asn_bogons,get_asn_prefixes,get_asn_facilities,get_asn_ixps,search_asns,get_facility_members,find_near,search_allocations,get_asn_allocations,search_transfers,lookup_rir_orgfind_networks_near,find_transit_near,find_upstreams_near,find_networks_at_facilities_near,find_networks_on_ixps_near,find_near,lookup_ip,get_facility_members,get_ixp_membersfind_growing_networks,get_asn_growth,find_networks_at_facilities_near,find_networks_on_ixps_near,lookup_asn,get_eventslookup_asn,search_asns,find_prospects,find_ddos_protected,get_lead_reasons,get_buy_signals,get_top_networks,find_transport,tag_prospect,create_client,add_asn_to_clientlookup_asn,lookup_ip,get_asn_history,get_asn_neighbours,get_transit_providers,find_upstreams_near,search_traceroutes,get_route_heatmap,get_tier1_comparison,get_country_scoreboard,compare_asns