WHOIS MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with minimal overlap. The server provides contact cards, raw WHOIS queries, route validation, and AS-SET expansion for each RIR, and descriptions explicitly differentiate them (e.g., 'DO NOT use for contact information - use X_contact_card'). This prevents misselection and ensures agents can easily choose the correct tool for specific tasks like incident response or network analysis.
Naming Consistency5/5
Tool names follow a highly consistent pattern: all use snake_case with a structure of 'rir_operation_object' (e.g., arin_contact_card, ripe_validate_route_object). This predictability makes it easy for agents to understand and navigate the toolset, as the naming convention clearly indicates the RIR, operation type, and target resource across all 14 tools.
Tool Count5/5
With 14 tools, the count is well-scoped for a WHOIS server covering multiple RIRs. Each tool earns its place by providing specialized functions (contact retrieval, raw queries, route validation, AS-SET expansion) across five RIRs, ensuring comprehensive coverage without redundancy. This aligns with the server's purpose of detailed network and contact information lookup.
Completeness5/5
The toolset offers complete coverage for WHOIS-related tasks across all major RIRs. It includes contact retrieval, raw data queries, route validation, and AS-SET expansion, addressing key use cases like incident response, network troubleshooting, and compliance. There are no obvious gaps; agents can perform full CRUD-like operations (e.g., query, validate, expand) for each region without dead ends.
Average 4.5/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: automatically resolves organization details, extracts contact information (abuse mailboxes, technical contacts, etc.), and returns structured contact data. It mentions the tool's purpose for incident response and compliance reporting, adding useful context beyond basic functionality.
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?
The description is somewhat verbose with repetitive elements (e.g., multiple contact type listings, keyword repetition). While front-loaded with the main purpose, it could be more streamlined. Sentences like 'Perfect for incident response...' add value but contribute to length. It's adequately structured but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and the presence of an output schema, the description is reasonably complete. It covers purpose, usage, behavioral aspects, and regional specificity. The output schema likely handles return values, so the description doesn't need to detail them. It could improve by more explicitly differentiating from sibling tools beyond regional scope.
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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds value by explaining the tool works with 'IP addresses, ASNs, or organizations' and mentions 'automatically resolves organization details,' but doesn't provide additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when schema coverage is complete.
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 clearly states the tool's purpose: retrieving contact information for IP addresses, ASNs, or organizations from the LACNIC database. It specifies the exact resource (LACNIC database) and distinguishes it from siblings by explicitly mentioning it's for the Latin America and Caribbean region, unlike other RIR-specific tools in the sibling list.
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?
The description provides explicit usage guidance: it's the 'PREFERRED TOOL' for contact retrieval from LACNIC, lists specific use cases (abuse reports, security incidents, network issues, administrative matters), and includes keywords to trigger its use. It implicitly distinguishes from sibling tools by specifying the LACNIC region, though it doesn't explicitly name alternatives for other regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a validation/checking tool (implies read-only, non-destructive), automatically handles IPv4/IPv6 detection, returns a simple exists/not-found status, and is optimized for speed and accuracy compared to raw WHOIS parsing. However, it doesn't mention potential rate limits, authentication needs, or error handling details.
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?
The description is appropriately sized and front-loaded, starting with the primary purpose and usage context. The keyword list adds some redundancy but helps with searchability. It could be slightly more concise by integrating keywords more naturally, but overall it's efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation with two parameters), no annotations, but with a rich input schema (100% coverage) and an output schema (implied by context signals), the description is mostly complete. It covers purpose, usage, and key behaviors, though it could benefit from more explicit details on output format or error cases, which the output schema may address.
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?
Schema description coverage is 100%, so the schema already fully documents both parameters (prefix and origin_asn). The description adds minimal value beyond the schema by reinforcing the validation purpose and mentioning automatic IPv4/IPv6 detection, but doesn't provide additional syntax or format details. This meets the baseline of 3 when schema coverage is high.
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 clearly states the tool's purpose: validating route object registration in the RIPE NCC database for a prefix-ASN pair. It specifies the region (Europe/Middle East/Central Asia) and distinguishes it from sibling tools like arin_validate_route_object by explicitly mentioning RIPE, making it easy to differentiate.
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?
The description explicitly states this is the 'PREFERRED TOOL' for validating route objects in RIPE and provides clear usage context: 'Use this when you need to CHECK, VERIFY, or VALIDATE if a route object exists for a prefix-ASN pair in RIPE.' It also contrasts with alternatives by noting it's 'Much faster and more accurate than parsing raw WHOIS data for route validation in RIPE database.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it 'automatically resolves organization details and extracts contact information,' returns 'structured contact data with clear categorization,' and is 'perfect for incident response, network troubleshooting, and compliance reporting.' However, it lacks details on error handling, rate limits, or authentication needs, which are important for a database query tool.
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?
The description is well-structured and front-loaded, starting with the tool's purpose and usage guidelines. However, it includes some redundant phrasing (e.g., repeating 'contact information' and listing many keywords) that could be trimmed for better conciseness without losing clarity.
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?
Given the tool's complexity (querying a regional database with multiple input types), the description is complete. It covers purpose, usage scenarios, behavioral aspects (like automatic resolution and structured returns), and contextualizes it within sibling tools. With an output schema present, it appropriately omits detailed return value explanations, focusing on high-level outcomes.
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?
The input schema has 100% description coverage, with clear documentation for 'ip,' 'asn,' and 'org' parameters. The description adds minimal value beyond the schema, mentioning 'IP addresses, ASNs, or organizations' but not elaborating on parameter interactions or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 clearly states the tool's purpose: 'retrieving contact information (abuse, NOC, admin, tech) for IP addresses, ASNs, or organizations from the AfriNIC database.' It specifies the verb ('retrieving'), resource ('contact information'), and scope ('AfriNIC database'), and distinguishes it from siblings by emphasizing it's 'specifically for the AfriNIC RIR (African region).'
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?
The description provides explicit guidance on when to use this tool: 'PREFERRED TOOL for retrieving contact information... Use this when you need to CONTACT someone about: abuse reports, security incidents, network issues, or administrative matters.' It also lists keywords and contrasts with siblings by specifying the AfriNIC region, helping differentiate from tools like 'apnic_contact_card' or 'arin_contact_card.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it 'automatically resolves organization details and extracts contact information,' returns 'structured contact data with clear categorization,' and is for 'incident response, network troubleshooting, and compliance reporting.' However, it doesn't mention potential limitations like rate limits, error conditions, or authentication requirements, leaving some gaps in behavioral 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?
The description is appropriately sized and front-loaded, starting with the key purpose and usage context. Most sentences add value, such as specifying the region and use cases. However, it includes some redundancy (e.g., repeating 'contact' in keywords) and could be slightly more streamlined without losing clarity.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but with output schema), the description is complete enough. It clearly explains the tool's purpose, when to use it, behavioral aspects like automatic resolution and structured returns, and distinguishes it from siblings. With an output schema present, it doesn't need to detail return values, and the schema covers parameters fully.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (ip, asn, org) with clear descriptions. The description adds no additional parameter-specific information beyond what's in the schema. It mentions the tool works with 'IP addresses, ASNs, or organizations' but doesn't provide syntax or format details not already covered. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the tool's purpose: 'retrieving contact information for IP addresses, ASNs, or organizations from the APNIC database.' It specifies the resource (APNIC database), the action (retrieving contact information), and distinguishes it from siblings by explicitly stating it's for the APNIC RIR region (Asia-Pacific) and is the 'PREFERRED TOOL' for contact retrieval, unlike whois_query tools.
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?
The description provides explicit guidance on when to use this tool: 'Use this when you need to CONTACT someone about: abuse reports, security incidents, network issues, or administrative matters.' It distinguishes from alternatives by specifying it's for the APNIC region and lists keywords to trigger usage. It also implicitly suggests when not to use it (e.g., for non-APNIC regions, where sibling tools like arin_contact_card would be appropriate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatically resolves organization details, extracts POC information including specific contact types and phone numbers, and returns structured contact data. However, it lacks details on rate limits, error handling, or authentication requirements, which are common for database queries.
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?
The description is well-structured and front-loaded, starting with the tool's purpose and preferred use case. Most sentences add value, such as specifying the ARIN region and contact scenarios. However, it includes some redundant phrasing (e.g., repeating 'contact' and listing many keywords) that slightly reduces efficiency without compromising clarity.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is complete enough. It covers the purpose, usage context, behavioral aspects like data extraction and return format, and regional scope. With an output schema present, it appropriately omits detailed return value explanations, focusing on high-level outcomes like structured contact data.
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?
Schema description coverage is 100%, providing clear documentation for each parameter (ip, asn, org). The description adds minimal value beyond the schema, only implying that these inputs are used to look up contact information in the ARIN database. No additional syntax, format, or interaction details are provided, so the baseline score of 3 is appropriate.
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 clearly states the tool retrieves contact information for IP addresses, ASNs, or organizations from the ARIN database, specifying contact types like abuse, NOC, admin, and tech. It distinguishes from siblings by explicitly mentioning it's for the ARIN RIR (North America region) and is the 'PREFERRED TOOL' for contact retrieval, unlike whois_query tools which may serve broader lookup purposes.
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?
The description provides explicit guidance on when to use this tool: for contacting about abuse reports, security incidents, network issues, or administrative matters in the ARIN region. It lists keywords like 'contact', 'abuse', and 'report' to trigger usage, and implicitly suggests alternatives by specifying the ARIN focus, distinguishing it from sibling tools for other RIRs (e.g., afrinic_contact_card).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it specifies the tool is for ARIN (North America region), handles IPv4/IPv6 detection automatically, returns simple exists/not-found status, and is optimized for speed and accuracy compared to raw WHOIS parsing. However, it doesn't mention rate limits, authentication needs, or error handling.
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?
The description is appropriately sized and front-loaded with key information (purpose, region, when to use). However, the keyword list ('Keywords: ...') is somewhat redundant and could be more integrated into the flow, slightly reducing efficiency.
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?
Given the tool's moderate complexity (2 required parameters), 100% schema coverage, and presence of an output schema, the description is complete enough. It clearly explains purpose, usage context, behavioral traits, and distinguishes from alternatives, providing sufficient context for an agent to use it effectively.
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?
Schema description coverage is 100%, providing detailed parameter documentation. The description adds minimal value beyond the schema, mentioning 'prefix-ASN pair' and 'IPv4/IPv6 detection', but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose: 'validating route object registration in the ARIN database' and specifies it's for 'CHECK, VERIFY, or VALIDATE if a route object exists for a prefix-ASN pair in ARIN'. It distinguishes from siblings by explicitly mentioning ARIN (North America region) and contrasting with 'ripe_validate_route_object' for a different RIR.
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?
The description provides explicit usage guidance: 'PREFERRED TOOL for validating route object registration in the ARIN database', 'Use this when you need to CHECK, VERIFY, or VALIDATE if a route object exists for a prefix-ASN pair in ARIN', and contrasts with alternatives by stating it's 'Much faster and more accurate than parsing raw WHOIS data for route validation in ARIN database'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it returns 'raw LACNIC database records with all attributes for detailed analysis' and 'complete object information in RPSL format.' It also mentions the regional specificity ('LACNIC RIR (Latin America and Caribbean region)'). However, it doesn't cover potential error cases, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific usage guidelines and behavioral details. Every sentence adds value—distinguishing from siblings, specifying regional scope, and describing output format—with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (WHOIS querying), lack of annotations, and presence of an output schema, the description is mostly complete. It covers purpose, usage guidelines, and output behavior well. However, it doesn't address potential errors or operational constraints (e.g., rate limits), which would be helpful for a network tool. The output schema likely handles return values, so that gap is mitigated.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'raw LACNIC database records' which aligns with the query parameter, but doesn't provide additional syntax or format details. The baseline score of 3 is appropriate when the schema does the heavy lifting.
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 clearly states the tool's purpose: 'Perform raw WHOIS queries against the LACNIC database to get complete object information in RPSL format.' It specifies the verb ('perform raw WHOIS queries'), resource ('LACNIC database'), and format ('RPSL format'), and distinguishes it from sibling tools by mentioning 'lacnic_contact_card' for contact information.
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?
The description provides explicit guidance on when to use this tool: 'Use ONLY when you need full object details or administrative data from LACNIC.' It also specifies when not to use it: 'DO NOT use for contact information - use lacnic_contact_card for abuse, NOC, admin, or tech contacts.' This clearly differentiates it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining what the tool does: 'Automatically resolves organization details and extracts abuse mailboxes, NOC contacts, phone numbers, and administrative information from RIPE database.' It specifies the return format ('structured contact data with clear categorization') and use cases, though it doesn't mention rate limits, authentication needs, or error handling.
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?
The description is appropriately sized and front-loaded with the key purpose ('PREFERRED TOOL for retrieving contact information'). Most sentences add value, though some redundancy exists (e.g., repeating contact purposes). It could be slightly more concise but remains well-structured for agent comprehension.
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?
Given the tool's moderate complexity, 100% schema coverage, and presence of an output schema, the description is complete enough. It clearly explains the tool's purpose, usage context, behavioral traits, and return format. The output schema means the description doesn't need to detail return values, and it adequately covers the tool's role among siblings.
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?
Schema description coverage is 100%, so the schema already documents all three parameters (ip, asn, org) with good descriptions. The description doesn't add any parameter-specific details beyond what's in the schema, but it does reinforce that inputs can be 'IP addresses, ASNs, or organizations.' Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the tool retrieves contact information for IP addresses, ASNs, or organizations from the RIPE NCC database, specifying it's for the Europe/Middle East/Central Asia region. It distinguishes from siblings by being 'PREFERRED TOOL for retrieving contact information' and explicitly mentions it's for the RIPE RIR, unlike other regional contact cards like afrinic_contact_card or apnic_contact_card.
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?
The description provides explicit guidance on when to use this tool: 'when you need to CONTACT someone about: abuse reports, security incidents, network issues, or administrative matters.' It lists specific keywords and use cases (incident response, network troubleshooting, compliance reporting), and the 'PREFERRED TOOL' designation helps differentiate it from alternative tools like ripe_whois_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: 'Automatically handles recursive expansion, deduplication, and cycle detection,' mentions performance characteristics ('balance completeness vs speed'), and specifies the geographic scope ('RIPE RIR (Europe/Middle East/Central Asia region)'). It doesn't cover error handling or authentication requirements, but provides substantial operational 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?
The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the first states the purpose, the second specifies regional scope and alternative tool, the third provides critical depth guidance, the fourth explains handling of large AS-SETs, and the fifth describes automation features and use cases. It could be slightly more concise but remains efficient.
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?
Given the tool's complexity (recursive expansion with depth control), the description provides excellent context. It covers purpose, regional scope, when to use vs alternatives, depth guidance, performance considerations, automation features, and use cases. With an output schema present, it doesn't need to explain return values, making this description complete for agent understanding.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds some practical context about depth usage ('For 'top-level', 'direct', or 'immediate' members, use max_depth=1') and performance implications, but doesn't provide significant additional semantic information beyond what's in the schema descriptions.
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 clearly states the tool's purpose: 'Efficiently expand AS-SET objects from the RIPE NCC database into concrete ASNs with configurable depth.' It specifies the verb (expand), resource (AS-SET objects), and distinguishes it from sibling tools by mentioning 'Use this instead of whois_query when you need ASNs from a RIPE AS-SET.'
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?
The description provides explicit guidance on when to use this tool vs alternatives: 'Use this instead of whois_query when you need ASNs from a RIPE AS-SET.' It also gives detailed context on depth selection for different scenarios (e.g., 'For 'top-level', 'direct', or 'immediate' members, use max_depth=1'), and mentions performance trade-offs for large AS-SETs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this tool returns 'raw ARIN database records with all attributes for detailed analysis' and specifies the geographic scope ('ARIN RIR - North America region'). However, it doesn't mention rate limits, authentication requirements, or error behavior, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. It starts with the core purpose, specifies geographic scope, provides clear usage guidelines with explicit alternatives, and ends with output characteristics. Every sentence adds essential information.
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?
Given the tool's moderate complexity (2 parameters), 100% schema coverage, and presence of an output schema, the description provides complete contextual information. It covers purpose, scope, usage guidelines, and output format, making it sufficient for an agent to understand when and how to use this tool.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'ARIN database' context but not providing additional semantic clarification about parameters. This meets the baseline for high schema coverage.
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 clearly states the tool performs 'raw WHOIS queries against the ARIN database to get complete object information in RPSL format.' It specifies the verb ('perform raw WHOIS queries'), resource ('ARIN database'), and output format ('RPSL format'), distinguishing it from sibling tools like contact cards or validation tools.
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?
The description provides explicit guidance on when to use this tool ('Use ONLY when you need full object details or administrative data from ARIN') and when not to use it, listing three specific alternatives for different purposes (arin_contact_card, arin_validate_route_object, arin_expand_as_set). This clearly differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it specifies the tool returns 'raw RIPE database records with all attributes for detailed analysis,' indicates it's for 'complete object information,' and mentions the query scope (domain, IP, ASN, etc.). While it doesn't cover rate limits or error handling, it provides substantial operational context beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by specific usage guidelines and prohibitions. Every sentence earns its place by providing critical differentiation from sibling tools or clarifying behavioral aspects, with zero wasted text.
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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is complete enough. It clearly defines the tool's purpose, usage boundaries, and behavioral output. Since an output schema exists, the description doesn't need to explain return values, and it adequately compensates for the lack of annotations with detailed contextual guidance.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it mentions 'domain name, IP address, ASN, or other identifier' in the context of the tool's purpose but doesn't provide additional syntax or format details. This meets the baseline of 3 when the schema does the heavy lifting.
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 clearly states the tool performs 'raw WHOIS queries against the RIPE NCC database to get complete object information in RPSL format.' It specifies the exact verb ('perform raw WHOIS queries'), resource ('RIPE NCC database'), and output format ('RPSL format'), and distinguishes it from sibling tools by mentioning the specific RIR region (Europe/Middle East/Central Asia).
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?
The description provides explicit guidance on when to use this tool ('Use ONLY when you need full object details or administrative data from RIPE') and when not to use it, with three clear prohibitions and named alternatives for each (e.g., 'DO NOT use for contact information - use ripe_contact_card'). This comprehensive guidance helps the agent select the correct tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns 'raw AfriNIC database records with all attributes for detailed analysis' and specifies the regional scope ('AfriNIC RIR (African region)'). It doesn't mention rate limits, authentication needs, or error behaviors, but provides substantial operational context beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: purpose statement, usage guidelines, and behavioral clarification. Every sentence adds essential information - no wasted words. It's front-loaded with the core purpose and immediately follows with critical usage restrictions.
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?
Given the tool has an output schema (so return values are documented elsewhere), 2 parameters with 100% schema coverage, and no annotations, the description provides excellent completeness. It covers purpose, specific usage context, sibling differentiation, regional scope, output format, and parameter context - everything needed for effective tool selection.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the query parameter accepts 'domain name, IP address, ASN, or other identifier' and clarifies the flags parameter with 'Common AfriNIC flags' examples and usage guidance ('Use empty list [] or null for default query'). This provides practical context beyond the schema.
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 clearly states the tool performs 'raw WHOIS queries against the AfriNIC database to get complete object information in RPSL format.' It specifies the exact resource (AfriNIC database), verb (perform queries), and output format (RPSL format). It distinguishes from sibling tools by explicitly mentioning 'afrinic_contact_card' for contact information.
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?
The description provides explicit guidance: 'Use ONLY when you need full object details or administrative data from AfriNIC. DO NOT use for contact information - use afrinic_contact_card for abuse, NOC, admin, or tech contacts.' This clearly defines when to use this tool versus alternatives, including a specific sibling tool for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a query tool (implied read-only), specifies the regional scope ('APNIC RIR - Asia-Pacific region'), indicates it returns 'complete object information' and 'raw APNIC database records with all attributes for detailed analysis.' It doesn't mention rate limits or authentication requirements, but provides substantial context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero wasted sentences. It starts with the core purpose, specifies the regional scope, provides clear usage guidelines with explicit do-not-use alternatives, and concludes with what the tool returns. Every sentence adds essential information for tool selection and invocation.
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?
Given the tool has an output schema (so return values are documented elsewhere), 100% schema description coverage, and no annotations, the description provides excellent contextual completeness. It covers purpose, regional scope, usage guidelines with specific alternatives, and output characteristics, making it fully adequate for an agent to understand when and how to use this tool versus siblings.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds meaningful context by explaining the tool's regional specificity ('APNIC RIR - Asia-Pacific region') and the nature of the returned data ('complete object information in RPSL format', 'raw APNIC database records'), which helps the agent understand what kind of queries are appropriate and what to expect in results.
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's purpose: 'Perform raw WHOIS queries against the APNIC database to get complete object information in RPSL format.' It specifies the verb ('perform raw WHOIS queries'), resource ('APNIC database'), and output format ('RPSL format'), clearly distinguishing it from sibling tools like apnic_contact_card or apnic_validate_route_object.
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?
The description provides explicit guidance on when to use this tool ('Use ONLY when you need full object details or administrative data from APNIC') and when not to use it, naming three specific alternatives for different purposes (apnic_contact_card for contacts, apnic_validate_route_object for route validation, apnic_expand_as_set for AS-SET expansion). This clearly differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: automatic handling of recursive expansion, deduplication, and cycle detection; performance implications (higher depth takes longer); and practical applications (network analysis, route filtering, policy generation). This provides comprehensive behavioral context beyond basic functionality.
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?
The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: purpose statement, regional specificity, sibling tool differentiation, depth guidance, behavioral traits, and use cases. While slightly dense, it avoids redundancy and maintains focus on essential information.
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?
Given the tool's complexity (recursive expansion with configurable depth), no annotations, and the presence of an output schema, the description provides excellent contextual completeness. It covers purpose, usage guidelines, behavioral traits, parameter semantics, and practical applications, making it fully understandable without relying on structured fields.
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 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the practical implications of max_depth choices with specific examples (depth=1 for top-level, depth=10+ for complete expansion) and warnings about performance trade-offs. However, it doesn't add meaningful semantic context for the setname parameter beyond what's in the schema.
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 clearly states the tool's purpose: 'Efficiently expand AS-SET objects from the ARIN IRR database into concrete ASNs with configurable depth.' It specifies the verb (expand), resource (AS-SET objects), and distinguishes it from sibling tools by mentioning ARIN RIR region and contrasting with whois_query for ASN extraction from AS-SETs.
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?
The description provides explicit guidance on when to use this tool: 'Use this instead of whois_query when you need ASNs from an ARIN AS-SET.' It also offers detailed depth recommendations for different scenarios (e.g., max_depth=1 for top-level members, max_depth=10+ for complete expansion) and warns about balancing completeness vs speed for large AS-SETs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![inet-registry-mcp MCP server](https://glama.ai/mcp/servers/dadepo/inet-registry-mcp/badges/card.svg)](https://glama.ai/mcp/servers/dadepo/inet-registry-mcp)

Score Badge

Copy to your README.md:

[![inet-registry-mcp MCP server](https://glama.ai/mcp/servers/dadepo/inet-registry-mcp/badges/score.svg)](https://glama.ai/mcp/servers/dadepo/inet-registry-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/dadepo/inet-registry-mcp'

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