Skip to main content
Glama
duksh

PeerGlass

by duksh

rir_ixp_lookup

Read-onlyIdempotent

Find Internet Exchange Points (IXPs) by country code or name to identify network interconnection locations. Search PeeringDB for IXP details including city, country, member count, and contact information.

Instructions

Search PeeringDB for Internet Exchange Points (IXPs) by country code or name.

An IXP is a physical location where ISPs and networks directly interconnect. Without IXPs, all traffic between two ISPs would travel via paid transit providers, costing more and adding latency. IXPs are the backbone of regional internet ecosystems.

Searching by country:

  • Use 2-letter ISO country code: 'MU' (Mauritius), 'ZA' (South Africa), 'DE' (Germany), 'US' (United States), 'SG' (Singapore)

Searching by name:

  • Partial name match: 'AMS-IX', 'LINX', 'Nairobi', 'Frankfurt'

Notable IXPs worldwide:

  • DE-CIX Frankfurt (Germany) — Europe's busiest, 13+ Tbps

  • AMS-IX (Netherlands) — 10+ Tbps

  • LINX (UK) — London Internet Exchange

  • JPNAP (Japan) — Asia-Pacific hub

  • Nap.Africa / JINX — African exchanges

  • MAURITIUS-IX — your local exchange!

Results are cached for 12 hours.

Args: params (IXPLookupInput): - query (str): 2-letter country code (e.g. 'MU') or IXP name fragment - response_format (str): 'markdown' (default) or 'json'

Returns: str: Table of matching IXPs with city, country, member count, and contact. JSON schema: { "query": str, "total_found": int, "ixps": [{"name": str, "city": str, "country": str, "member_count": int, "website": str, "tech_email": 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?

Annotations declare readOnly/idempotent/openWorld; description adds critical behavioral context: data source (PeeringDB), cache duration ('12 hours'), and domain explanation (what IXPs are and their role). 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear Args/Returns sections, but includes verbose 'Notable IXPs worldwide' list (7 bullets) with casual editorializing ('your local exchange!'). Educational paragraph on IXPs is useful context but combined with examples makes the description longer than necessary.

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: explains domain concepts (IXP ecosystem), documents parameters (compensating for schema coverage), specifies cache behavior, and provides complete JSON output schema with field definitions. With readOnly/destructive annotations present and output detailed, nothing material is missing.

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?

Context signals indicate 0% schema coverage (top-level param lacks description). Description compensates effectively via Args section documenting both nested parameters ('query' accepting country codes or name fragments, 'response_format' options) and noting the markdown default. Also provides JSON output schema adding return value semantics.

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 ('Search'), resource ('PeeringDB for Internet Exchange Points'), and filter criteria ('by country code or name'). Clearly distinguishes from sibling RIR tools which focus on BGP, ASN relationships, or DNS rather than IXPs.

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 explicit guidance on search syntax (2-letter ISO codes vs. partial name matches) with concrete examples ('MU', 'AMS-IX', 'Nairobi'). Lacks explicit 'when not to use' or sibling alternatives (e.g., doesn't contrast with rir_peering_info), but usage patterns are clearly implied through examples.

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