Skip to main content
Glama

ripe_network_info

Read-onlyIdempotent

Retrieve network information for an IP address or prefix from RIPE NCC to identify ownership, allocation, and routing details.

Instructions

Get network information for an IP or prefix from RIPE NCC.

Input Schema

NameRequiredDescriptionDefault
resourceYesIP address or prefix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.11

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the source registry (RIPE NCC) and open-world hint is also annotated. However it does not say what fields 'network information' returns (ASN, netblock, org, abuse contact), leaving the payload opaque.

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?

A single front-loaded sentence with no filler. It is efficient but leaves near-zero room for behavioral context, which is a slightly missed opportunity given the vague 'network information' payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-param read tool with rich annotations and full schema coverage, the definition is minimally viable but underspecified on output: with no output schema, the description should hint at what 'network information' contains (ASN, prefix, holder, contacts) so the agent knows what to expect.

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

Parameters3/5

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

With one required parameter and 100% schema description coverage, the schema already documents 'resource' as an IP address or prefix. The description reinforces the accepted inputs but adds no format examples or CIDR syntax detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (network information) and names the data source (RIPE NCC), which distinguishes it from generic IP lookups like ipinfo_lookup or ip_address_lookup. It does not explicitly differentiate from close siblings such as rdap_ip or bgpview_ip, but the RIPE-specific framing is clear.

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

Usage Guidelines3/5

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

Use is implied by the resource type (an IP or prefix), but there is no explicit when-to-use guidance or exclusion of alternatives like rdap_ip, bgpview_ip, or ripe_asn_neighbours. An agent must infer the choice from the name alone.

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

Deploy Server

Other Tools