Skip to main content
Glama
duksh

PeerGlass

by duksh

rir_check_bgp_status

Read-onlyIdempotent

Check if a prefix or ASN is visible in the global BGP routing table using RIPE Stat data, identifying announcements and visibility percentages for routing security assessment.

Instructions

Check whether a prefix or ASN is currently visible in the global BGP routing table.

Uses RIPE Stat (which aggregates data from RIPE RIS route collectors worldwide). BGP is the internet's routing protocol — the "GPS" that tells traffic how to navigate from one network to another.

For a prefix, returns:

  • Whether it is currently announced in BGP

  • Which ASN(s) are announcing it (multiple = potential hijack)

  • Percentage of global BGP peers that can see it (visibility)

For an ASN, returns:

  • Whether the ASN has any active BGP announcements

  • A list of all announced prefixes (use rir_get_announced_prefixes for details)

Combine with rir_check_rpki for complete routing security assessment. Results are cached for 5 minutes (BGP tables change frequently).

Args: params (BGPStatusInput): - resource (str): Prefix (e.g. '1.1.1.0/24') or ASN (e.g. 'AS15169') - response_format (str): 'markdown' (default) or 'json'

Returns: str: BGP visibility, announcing ASNs, and prefix list. JSON schema: { "resource": str, "resource_type": str, "is_announced": bool, "announcing_asns": [str], "visibility_percent": float, "announced_prefixes": [{"prefix": str, "peers_seeing": int}] }

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 valuable operational context beyond annotations: specifies the 5-minute cache duration ('BGP tables change frequently'), identifies the external data source (RIPE Stat route collectors), and explains the 'potential hijack' interpretation of multiple announcing ASNs. Annotations already cover safety profile (readOnly, idempotent), so this adds temporal and sourcing context.

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 delineation between prefix and ASN return behaviors. The BGP 'GPS' analogy adds educational value without excessive verbosity. The embedded JSON return schema in the Returns section is functional but slightly lengthy; however, it serves as necessary documentation given the complexity of BGP visibility data.

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?

Comprehensive coverage for a complex networking tool: explains RIPE Stat data source, documents both input modes (prefix/ASN) with their respective output structures, includes the JSON output schema, notes caching behavior, and provides sibling tool integration guidance. Complete despite the technical complexity.

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?

With schema description coverage reported at 0% (top-level 'params' lacks description), the Args section compensates effectively by documenting the 'resource' format (prefix or ASN examples) and 'response_format' options (markdown vs json). Provides concrete examples ('1.1.1.0/24', 'AS15169') not explicitly shown in the schema reference.

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 explicitly states the tool 'Check[s] whether a prefix or ASN is currently visible in the global BGP routing table' using RIPE Stat. It clearly distinguishes the resource types (prefix vs ASN) and differentiates from siblings by referencing rir_get_announced_prefixes for ASN details and rir_check_rpki for security assessments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly guides tool selection by stating 'use rir_get_announced_prefixes for details' when querying ASNs, and recommends combining with 'rir_check_rpki for complete routing security assessment.' It clearly delineates different return behaviors for prefixes (visibility check) versus ASNs (prefix listing).

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