Skip to main content
Glama
duksh

PeerGlass

by duksh

rir_prefix_history

Read-onlyIdempotent

Fetch the complete registration history for an IP prefix or ASN to view ownership transfers, status changes, and initial registration details.

Instructions

Fetch the complete registration history for an IP prefix or ASN.

Returns a chronological timeline of every change ever recorded:

  • Initial registration (who, when, under which RIR)

  • Org / maintainer changes (potential ownership transfers)

  • Status changes (allocated → assigned → available)

  • Last-changed updates

Uses RIPE Stat's historical-whois and allocation-history APIs. Coverage is best for RIPE NCC resources; partial for other RIRs.

Use cases:

  • "Has this IP block ever changed hands?"

  • "When was this ASN first registered?"

  • "What organization historically owned this prefix?"

  • Due diligence, incident response, fraud investigation

Results are cached for 12 hours (historical records are stable).

Args: params (PrefixHistoryInput): - resource (str): IP prefix (e.g. '8.8.8.0/24') or ASN (e.g. 'AS15169') - response_format (str): 'markdown' (default) or 'json'

Returns: str: Chronological event timeline with dates, event types, and attribute changes. JSON schema: { "resource": str, "resource_type": str, "current_holder": str, "current_rir": str, "registration_date": str, "total_events": int, "events": [{"event_date": str, "event_type": str, "attribute": str, "old_value": str, "new_value": str}], "sources": [str], "errors": [str] }

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?

Adds critical behavioral context beyond annotations: explicitly notes RIPE NCC has best coverage while other RIRs are partial (data quality limitation), identifies the specific upstream APIs used (RIPE Stat's historical-whois and allocation-history), and discloses the 12-hour caching behavior. Annotations only cover safety/readonly aspects, while description explains data provenance and limitations.

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?

Well-structured with clear visual hierarchy: purpose statement, bullet list of returned event types, implementation details, coverage caveats, use cases, and Args/Returns sections. Front-loaded with the core action. The JSON schema in Returns is verbose but necessary as no separate output schema is provided in the structured fields.

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 data retrieval tool: covers API sources, RIR coverage limitations, caching policy, specific use cases, input parameter details, and provides a full output schema structure. Given the existence of output schema documentation in the description and the tool's complexity (RDAP/RIR history), no critical gaps remain.

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

Parameters4/5

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

The Args section explicitly documents the nested params (resource, response_format) with clear type annotations and value examples ('8.8.8.0/24', 'AS15169'), effectively compensating for the schema's structure where top-level coverage may appear limited. While the schema has some descriptions, the description provides a consolidated, readable view of the required resource parameter and optional format toggle.

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?

The description opens with a precise action statement: 'Fetch the complete registration history for an IP prefix or ASN.' It specifies the exact resource (registration history), the data scope (complete, chronological timeline), and distinguishes itself from current-state siblings like rir_prefix_overview through its focus on historical changes (ever recorded, initial registration, changes).

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 specific use cases ('Has this IP block ever changed hands?', 'Due diligence, incident response, fraud investigation') that clearly signal when to use this tool versus current-state alternatives. Lacks explicit 'do not use for X, use Y instead' sibling comparisons, but the historical focus is distinct enough to guide selection.

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