Skip to main content
Glama
duksh

PeerGlass

by duksh

rir_ipv4_stats

Read-onlyIdempotent

Fetch global IPv4, IPv6, and ASN allocation statistics from all five Regional Internet Registries to track adoption and exhaustion states in real time.

Instructions

Fetch global IPv4, IPv6, and ASN allocation statistics from all 5 RIRs.

Parses the NRO Extended Delegation Stats files — the authoritative daily publication of how each RIR has distributed address space:

  • How many IPv4 prefixes allocated (to ISPs) vs assigned (to end users)

  • Remaining free IPv4 pool (where published — most RIRs are exhausted)

  • IPv6 prefix count and growth

  • Total ASNs issued

Why this matters:

  • IPv4 was exhausted at IANA in 2011

  • APNIC exhausted in 2011, RIPE in 2012, ARIN in 2015

  • LACNIC near exhaustion 2020, AFRINIC followed

  • IPv6 transition is the only long-term solution

  • This tool lets you track adoption and exhaustion state in real time

Results are cached for 24 hours (stats files are published once daily).

Args: params (IPv4StatsInput): - rir_filter (str, optional): Filter to one RIR ('AFRINIC', 'APNIC', 'ARIN', 'LACNIC', 'RIPE'). Leave empty for all 5. - include_blocks (bool): Include raw delegated IPv4 blocks for the selected RIR. Requires rir_filter to be set. - status_filter (str, optional): allocated | assigned | available (free is normalized). - country_filter (str, optional): 2-letter country code filter (e.g. 'GH', 'ZA'). - limit (int): Max number of block rows when include_blocks=true. - offset (int): Pagination offset for block rows. - response_format (str): 'markdown' (default) or 'json'

Returns: str: Per-RIR table of IPv4/IPv6/ASN counts with totals and exhaustion context. JSON schema: { "queried_at": str, "rirs": [{"rir": str, "region": str, "ipv4_total_prefixes": int, "ipv4_allocated": int, "ipv4_assigned": int, "ipv4_available": int, "ipv6_total_prefixes": int, "asn_total": int, "stats_date": str}], "global_ipv4_prefixes": int, "global_ipv6_prefixes": int, "global_asns": int, "ipv4_blocks": [ {"rir": str, "country": str|null, "start_ip": str, "end_ip": str, "address_count": int, "date": str|null, "status": str} ], "blocks_total": int, "blocks_returned": int, "blocks_limit": int|null, "blocks_offset": int|null, "blocks_filters": {"rir_filter": str|null, "status_filter": str|null, "country_filter": str|null} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations cover safety (readOnly, idempotent, non-destructive). Description adds significant value: authoritative data source (NRO Extended Delegation Stats files), 24-hour cache policy, and domain-specific context (exhaustion dates by RIR). No contradictions with annotations.

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-loaded with clear purpose statement. Well-structured with logical sections (summary, data source, why it matters, args, returns). Slightly verbose due to embedded JSON schema in Returns section, but every section earns its place for this complex domain tool.

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?

Exceptionally complete for a complex multi-RIR statistics tool. Covers data source authority, historical exhaustion context, all filter parameters, pagination logic, and includes full output JSON schema. Returns section explicitly documents the response structure expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage at root level (single 'params' object), the Args section comprehensively documents all 7 inner parameters including constraints (rir_filter requires include_blocks), valid enums (RIR names), and dependencies. Fully compensates for schema structure.

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?

Description opens with specific verb+resource: 'Fetch global IPv4, IPv6, and ASN allocation statistics from all 5 RIRs.' It clearly distinguishes from sibling 'rir_query_ip' and 'rir_query_asn' (specific resource lookups) by emphasizing global statistics, allocation counts, and exhaustion dashboard functionality.

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 rich context in 'Why this matters' section explaining IPv4 exhaustion timeline and use cases (tracking adoption/exhaustion states). Caching behavior (24 hours) is disclosed. Lacks explicit sibling comparison (e.g., 'for specific IP details use rir_query_ip'), but the global/dashboard scope is clearly differentiated.

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

Install Server

Other Tools

Latest Blog Posts

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/duksh/peerglass'

If you have feedback or need assistance with the MCP directory API, please join our Discord server