Skip to main content
Glama
enesjakozh
w0h1v

mcp-shodan

by w0h1v
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Shodan MCP Server

MCP Registry

A Model Context Protocol (MCP) server for querying the Shodan API and Shodan CVEDB. This server provides comprehensive access to Shodan's network intelligence and security services, including IP reconnaissance, DNS operations, vulnerability tracking, and device discovery. All tools provide structured, formatted output for easy analysis and integration.

Quick Start (Recommended)

Installing via Claude Code

claude mcp add --transport stdio --env SHODAN_API_KEY=your-shodan-api-key shodan -- npx -y @burtthecoder/mcp-shodan

Installing via Codex CLI

codex mcp add shodan --env SHODAN_API_KEY=your-shodan-api-key -- npx -y @burtthecoder/mcp-shodan

Installing via Gemini CLI

gemini mcp add -e SHODAN_API_KEY=your-shodan-api-key shodan npx -y @burtthecoder/mcp-shodan

Installing via Smithery

To install Shodan Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @burtthecoder/mcp-shodan --client claude

Installing Manually

  1. Install the server globally via npm:

npm install -g @burtthecoder/mcp-shodan

  1. Add to your Claude Desktop configuration file:

{
  "mcpServers": {
    "shodan": {
      "command": "mcp-shodan",
      "env": {
        "SHODAN_API_KEY": "your-shodan-api-key"
      }
    }
  }
}

Configuration file location:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  1. Restart Claude Desktop

Related MCP server: Shodan-MCP-Server

Alternative Setup (From Source)

If you prefer to run from source or need to modify the code:

  1. Clone and build:

git clone https://github.com/BurtTheCoder/mcp-shodan.git
cd mcp-shodan
npm install
npm run build

  1. Add to your Claude Desktop configuration:

{
  "mcpServers": {
    "shodan": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-shodan/build/index.js"],
      "env": {
        "SHODAN_API_KEY": "your-shodan-api-key"
      }
    }
  }
}

Features

  • Network Reconnaissance: Query detailed information about IP addresses, including open ports, services, and vulnerabilities

  • DNS Operations: Forward and reverse DNS lookups for domains and IP addresses

  • Vulnerability Intelligence: Access to Shodan's CVEDB for detailed vulnerability information, CPE lookups, and product-specific CVE tracking

  • Device Discovery: Search Shodan's database of internet-connected devices with advanced filtering

Tools

1. IP Lookup Tool

  • Name: ip_lookup

  • Description: Retrieve comprehensive information about an IP address, including geolocation, open ports, running services, SSL certificates, hostnames, and cloud provider details if available

  • Parameters:

    • ip (required): IP address to lookup

  • Returns:

    • IP Information (address, organization, ISP, ASN)

    • Location (country, city, coordinates)

    • Services (ports, protocols, banners)

    • Cloud Provider details (if available)

    • Associated hostnames and domains

    • Tags

2. Shodan Search Tool

  • Name: shodan_search

  • Description: Search Shodan's database of internet-connected devices

  • Parameters:

    • query (required): Shodan search query

    • max_results (optional, default: 10): Number of results to return

  • Returns:

    • Search summary with total results

    • Country-based distribution statistics

    • Detailed device information including:

      • Basic information (IP, organization, ISP)

      • Location data

      • Service details

      • Web server information

      • Associated hostnames and domains

3. CVE Lookup Tool

  • Name: cve_lookup

  • Description: Query detailed vulnerability information from Shodan's CVEDB

  • Parameters:

    • cve (required): CVE identifier in format CVE-YYYY-NNNNN (e.g., CVE-2021-44228)

  • Returns:

    • Basic Information (ID, published date, summary)

    • Severity Scores:

      • CVSS v2 and v3 with severity levels

      • EPSS probability and ranking

    • Impact Assessment:

      • KEV status

      • Proposed mitigations

      • Ransomware associations

    • Affected products (CPEs)

    • References

4. DNS Lookup Tool

  • Name: dns_lookup

  • Description: Resolve domain names to IP addresses using Shodan's DNS service

  • Parameters:

    • hostnames (required): Array of hostnames to resolve

  • Returns:

    • DNS resolutions mapping hostnames to IPs

    • Summary of total lookups and queried hostnames

5. Reverse DNS Lookup Tool

  • Name: reverse_dns_lookup

  • Description: Perform reverse DNS lookups to find hostnames associated with IP addresses

  • Parameters:

    • ips (required): Array of IP addresses to lookup

  • Returns:

    • Reverse DNS resolutions mapping IPs to hostnames

    • Summary of total lookups and results

6. CPE Lookup Tool

  • Name: cpe_lookup

  • Description: Search for Common Platform Enumeration (CPE) entries by product name

  • Parameters:

    • product (required): Name of the product to search for

    • count (optional, default: false): If true, returns only the count of matching CPEs

    • skip (optional, default: 0): Number of CPEs to skip (for pagination)

    • limit (optional, default: 1000): Maximum number of CPEs to return

  • Returns:

    • When count is true: Total number of matching CPEs

    • When count is false: List of CPEs with pagination details

7. CVEs by Product Tool

  • Name: cves_by_product

  • Description: Search for vulnerabilities affecting specific products or CPEs

  • Parameters:

    • cpe23 (optional): CPE 2.3 identifier (format: cpe:2.3:part:vendor:product:version)

    • product (optional): Name of the product to search for CVEs

    • count (optional, default: false): If true, returns only the count of matching CVEs

    • is_kev (optional, default: false): If true, returns only CVEs with KEV flag set

    • sort_by_epss (optional, default: false): If true, sorts CVEs by EPSS score

    • skip (optional, default: 0): Number of CVEs to skip (for pagination)

    • limit (optional, default: 1000): Maximum number of CVEs to return

    • start_date (optional): Start date for filtering CVEs (format: YYYY-MM-DDTHH:MM:SS)

    • end_date (optional): End date for filtering CVEs (format: YYYY-MM-DDTHH:MM:SS)

  • Notes:

    • Must provide either cpe23 or product, but not both

    • Date filtering uses published time of CVEs

  • Returns:

    • Query information

    • Results summary with pagination details

    • Detailed vulnerability information including:

      • Basic information

      • Severity scores

      • Impact assessments

      • References

Requirements

Troubleshooting

API Key Issues

If you see API key related errors (e.g., "Request failed with status code 401"):

  1. Verify your API key:

    • Must be a valid Shodan API key from your account settings

    • Ensure the key has sufficient credits/permissions for the operation

    • Check for extra spaces or quotes around the key in the configuration

    • Verify the key is correctly set in the SHODAN_API_KEY environment variable

  2. Common Error Codes:

    • 401 Unauthorized: Invalid API key or missing authentication

    • 402 Payment Required: Out of query credits

    • 429 Too Many Requests: Rate limit exceeded

  3. Configuration Steps: a. Get your API key from Shodan Account b. Add it to your configuration file:

    {
  "mcpServers": {
    "shodan": {
      "command": "mcp-shodan",
      "env": {
        "SHODAN_API_KEY": "your-actual-api-key-here"
      }
    }
  }
}

    c. Save the config file d. Restart Claude Desktop

  4. Testing Your Key:

    • Try a simple query first (e.g., dns_lookup for "google.com")

    • Check your Shodan account dashboard for credit status

    • Verify the key works directly with curl:

      curl "https://api.shodan.io/dns/resolve?hostnames=google.com&key=your-api-key"

Module Loading Issues

If you see module loading errors:

  1. For global installation: Use the simple configuration shown in Quick Start

  2. For source installation: Ensure you're using Node.js v18 or later

Development

Build the project:

npm install
npm run build

Test interactively with FastMCP's built-in dev tool:

npx fastmcp dev build/index.js

Error Handling

The server includes comprehensive error handling for:

  • Invalid API keys

  • Rate limiting

  • Network errors

  • Invalid input parameters

  • Invalid CVE formats

  • Invalid CPE lookup parameters

  • Invalid date formats

  • Mutually exclusive parameter validation

Version History

  • v1.0.22: Published to the official MCP Registry — added server.json manifest, CLI install support for Claude Code, Codex, and Gemini CLI

  • v1.1.0: Migrated from raw @modelcontextprotocol/sdk to FastMCP — modular tool files, automatic schema validation, simplified error handling

  • v1.0.12: Added reverse DNS lookup and improved output formatting

  • v1.0.7: Added CVEs by Product search functionality and renamed vulnerabilities tool to cve_lookup

  • v1.0.6: Added CVEDB integration for enhanced CVE lookups and CPE search functionality

  • v1.0.0: Initial release with core functionality

Contributing

  1. Fork the repository

  2. Create a feature branch (git checkout -b feature/amazing-feature)

  3. Commit your changes (git commit -m 'Add amazing feature')

  4. Push to the branch (git push origin feature/amazing-feature)

  5. Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

7 tools
cpe_lookupA

Search for Common Platform Enumeration (CPE) entries by product name in Shodan's CVEDB. Supports pagination and can return either full CPE details or just the total count. Useful for identifying specific versions and configurations of software and hardware.

ParametersJSON Schema
NameRequiredDescriptionDefault
productYesThe name of the product to search for CPEs.
countNoIf true, returns only the count of matching CPEs.
skipNoNumber of CPEs to skip (for pagination).
limitNoMaximum number of CPEs to return (max 1000).

TDQS

A3.9/5.0
Behavior3/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 mentions pagination support and the ability to return full details or just counts, which adds useful context beyond basic functionality. However, it does not cover aspects like rate limits, authentication needs, error handling, or response format details, leaving gaps in behavioral understanding.

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 in three sentences: the first states the core functionality, the second adds key features (pagination and output options), and the third provides usage context. Each sentence earns its place without redundancy, making it front-loaded and appropriately sized for the tool's complexity.

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?

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description covers core functionality and some behavioral aspects but lacks details on response format, error cases, or integration with sibling tools. It is adequate as a minimum viable description but has clear gaps in providing a complete operational context.

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 fully documents all parameters. The description adds value by explaining the purpose ('Search for CPE entries by product name') and the utility ('Useful for identifying specific versions and configurations'), which provides semantic context beyond the schema's technical details. Since no parameters are left undocumented, this exceeds the baseline of 3.

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 specific action ('Search for Common Platform Enumeration entries by product name'), identifies the resource ('in Shodan's CVEDB'), and distinguishes it from siblings by focusing on CPE lookup rather than CVE lookup or other Shodan functions. It explicitly mentions what it returns ('full CPE details or just the total count'), making the purpose unambiguous.

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?

The description implies usage context ('Useful for identifying specific versions and configurations of software and hardware') but does not explicitly state when to use this tool versus alternatives like 'cve_lookup' or 'cves_by_product'. It mentions pagination and count options, which provide some guidance on functionality, but lacks direct comparisons or exclusions for sibling tools.

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

cve_lookupA

Query detailed vulnerability information from Shodan's CVEDB. Returns comprehensive CVE details including CVSS scores (v2/v3), EPSS probability and ranking, KEV status, proposed mitigations, ransomware associations, and affected products (CPEs).

ParametersJSON Schema
NameRequiredDescriptionDefault
cveYesThe CVE identifier to query (format: CVE-YYYY-NNNNN).

TDQS

A4/5.0
Behavior3/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 describes the comprehensive data returned (CVSS scores, EPSS, KEV status, etc.), which adds useful context about output behavior, but does not mention rate limits, authentication needs, or error handling, leaving gaps for a tool with external API dependencies.

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 in two sentences: the first states the purpose and source, and the second enumerates the returned details. Every sentence adds essential information with no wasted words, making it highly concise and front-loaded.

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 (querying external vulnerability data) and lack of annotations and output schema, the description does well by detailing the comprehensive return data. However, it could improve by mentioning response format or error scenarios, slightly limiting completeness for an API-dependent 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%, with the single parameter 'cve' well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides, such as examples or edge cases, so it meets the baseline for high schema coverage without extra value.

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 specific action ('Query detailed vulnerability information') and resource ('from Shodan's CVEDB'), distinguishing it from sibling tools like cpe_lookup or cves_by_product by focusing on individual CVE details rather than product-based queries or broader searches.

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?

The description implies usage context by specifying it queries 'detailed vulnerability information' for a CVE identifier, but does not explicitly state when to use this tool versus alternatives like cves_by_product or shodan_search. It provides clear intent but lacks explicit comparison or exclusion guidance.

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

cves_by_productA

Search for vulnerabilities affecting specific products or CPEs. Supports filtering by KEV status, sorting by EPSS score, date ranges, and pagination. Can search by product name or CPE 2.3 identifier. Returns detailed vulnerability information including severity scores and impact assessments.

ParametersJSON Schema
NameRequiredDescriptionDefault
cpe23NoThe CPE version 2.3 identifier (format: cpe:2.3:part:vendor:product:version).
productNoThe name of the product to search for CVEs.
countNoIf true, returns only the count of matching CVEs.
is_kevNoIf true, returns only CVEs with the KEV flag set.
sort_by_epssNoIf true, sorts CVEs by EPSS score in descending order.
skipNoNumber of CVEs to skip (for pagination).
limitNoMaximum number of CVEs to return (max 1000).
start_dateNoStart date for filtering CVEs (format: YYYY-MM-DDTHH:MM:SS).
end_dateNoEnd date for filtering CVEs (format: YYYY-MM-DDTHH:MM:SS).

TDQS

A3.6/5.0
Behavior3/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: filtering capabilities (KEV, EPSS, date ranges), pagination support, and return content ('detailed vulnerability information including severity scores and impact assessments'). However, it omits details like rate limits, authentication needs, error handling, or whether it's read-only/destructive, leaving gaps for a mutation-sensitive agent.

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 with three sentences: purpose, features, and return value. It is front-loaded with the core purpose, and each sentence adds useful information without redundancy. Minor improvement could be made by integrating features more seamlessly, but it's efficient overall.

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?

Given 9 parameters, no annotations, and no output schema, the description provides a good overview of functionality and return content. However, it lacks details on behavioral aspects like rate limits or error cases, and does not fully compensate for the absence of output schema, leaving the agent uncertain about the exact response structure.

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 fully documents all 9 parameters. The description adds minimal value beyond the schema by mentioning filtering and sorting options (e.g., 'KEV status', 'EPSS score') without providing 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 specific action ('Search for vulnerabilities affecting specific products or CPEs') and resource ('CVEs'), distinguishing it from siblings like cve_lookup (likely general CVE lookup) and cpe_lookup (CPE-specific). The verb 'search' with the qualifier 'affecting specific products or CPEs' provides precise scope.

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?

The description implies usage context through 'Supports filtering by KEV status, sorting by EPSS score, date ranges, and pagination,' suggesting when to use it for filtered searches. However, it lacks explicit guidance on when to choose this tool over alternatives like cve_lookup or cpe_lookup, and does not mention exclusions or prerequisites.

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

dns_lookupA

Resolve domain names to IP addresses using Shodan's DNS service. Supports batch resolution of multiple hostnames in a single query. Returns IP addresses mapped to their corresponding hostnames.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostnamesYesList of hostnames to resolve.

TDQS

A3.5/5.0
Behavior2/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 mentions batch resolution and the return format (IP addresses mapped to hostnames), but doesn't cover important aspects like rate limits, authentication requirements, error handling, or whether this is a read-only operation. The description provides basic behavior but lacks critical 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.

Conciseness5/5

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

Three sentences that are front-loaded with core functionality, followed by batch capability, and ending with return format. Every sentence adds value with zero wasted words. The structure efficiently communicates the tool's purpose and capabilities.

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 single-parameter tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and what it returns. However, it lacks important contextual details about authentication, rate limits, error cases, and specific usage scenarios that would help an agent 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%, so the schema already documents the single 'hostnames' parameter. The description adds marginal value by mentioning 'batch resolution of multiple hostnames' which reinforces the array nature of the parameter, but doesn't provide additional syntax, format, or constraint details beyond what the schema provides.

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 specific action ('Resolve domain names to IP addresses'), identifies the resource ('using Shodan's DNS service'), and distinguishes from siblings by focusing on forward DNS resolution (unlike reverse_dns_lookup or IP-based tools like ip_lookup). It provides a complete picture of what the tool does.

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?

The description implies usage for DNS resolution tasks and mentions batch capability, but doesn't explicitly state when to use this tool versus alternatives like reverse_dns_lookup or ip_lookup. No guidance on prerequisites, limitations, or specific scenarios where this tool is preferred over others is provided.

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

ip_lookupA

Retrieve comprehensive information about an IP address, including geolocation, open ports, running services, SSL certificates, hostnames, and cloud provider details if available. Returns service banners and HTTP server information when present.

ParametersJSON Schema
NameRequiredDescriptionDefault
ipYesThe IP address to query.

TDQS

A4/5.0
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 and does well by disclosing behavioral traits: it specifies what information is returned (geolocation, open ports, services, SSL certificates, etc.), mentions conditional returns ('when present'), and indicates cloud provider detection. However, it doesn't cover rate limits, authentication needs, or error conditions.

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 front-loaded with the core purpose and efficiently lists return details in a single, well-structured sentence. Every phrase adds value without redundancy.

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 no annotations and no output schema, the description provides good context about return types and conditions. It could be more complete by mentioning response format or error handling, but it adequately covers the tool's scope for a lookup operation.

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 the single 'ip' parameter. The description doesn't add parameter-specific details beyond implying the IP address is used for comprehensive lookup, maintaining the baseline score of 3.

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 specific action ('Retrieve comprehensive information') and resource ('about an IP address'), distinguishing it from sibling tools like dns_lookup or reverse_dns_lookup by focusing on IP-specific intelligence rather than DNS resolution.

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?

The description implies usage context by listing the types of information returned (geolocation, services, etc.), but doesn't explicitly state when to use this tool versus alternatives like shodan_search or when not to use it (e.g., for domain-based queries).

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

reverse_dns_lookupA

Perform reverse DNS lookups to find hostnames associated with IP addresses. Supports batch lookups of multiple IP addresses in a single query. Returns all known hostnames for each IP address, with clear indication when no hostnames are found.

ParametersJSON Schema
NameRequiredDescriptionDefault
ipsYesList of IP addresses to perform reverse DNS lookup on.

TDQS

A3.9/5.0
Behavior3/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 describes the batch capability, return format (all known hostnames), and handling of missing results. However, it doesn't mention rate limits, authentication needs, or error conditions that would be important for a network tool.

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 perfectly concise with three sentences that each add value: states the core purpose, describes batch capability, and explains return behavior. No wasted words and front-loaded with the main functionality.

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 network lookup tool with no annotations and no output schema, the description provides adequate basic information but lacks details about response format structure, error handling, and operational constraints that would be important for complete 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 the 'ips' parameter. The description adds context about batch lookups and what the parameter represents, but doesn't provide additional syntax or format details beyond what the schema provides.

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 with specific verbs ('perform reverse DNS lookups', 'find hostnames') and resources ('IP addresses'). It distinguishes from sibling tools like 'dns_lookup' and 'ip_lookup' by specifying the reverse direction and batch capability.

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?

The description provides clear context for when to use this tool (to find hostnames from IP addresses with batch support). It doesn't explicitly mention when not to use it or name alternatives, but the context is sufficient for basic differentiation from siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 7 tool updatesv1.0.0
    • Changedcpe_lookup2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcve_lookup2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcves_by_product2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changeddns_lookup2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedip_lookup2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedreverse_dns_lookup2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedshodan_search2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
  2. 7 tool updates
    • First observedcpe_lookup
    • First observedcve_lookup
    • First observedcves_by_product
    • First observeddns_lookup
    • First observedip_lookup
    • First observedreverse_dns_lookup
    • First observedshodan_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: cpe_lookup focuses on CPE entries, cve_lookup on CVE details, cves_by_product on vulnerabilities for specific products, dns_lookup on domain-to-IP resolution, ip_lookup on IP address information, reverse_dns_lookup on IP-to-hostname resolution, and shodan_search on device database searches. The descriptions reinforce these unique scopes, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., cpe_lookup, cve_lookup, dns_lookup), with 'lookup' or 'search' as the verb and a specific noun (cpe, cve, dns, ip, etc.). This predictable naming scheme enhances readability and agent usability, with no deviations in style or convention across the set.

Tool Count5/5

With 7 tools, the count is well-scoped for a Shodan security and reconnaissance server. Each tool earns its place by covering distinct aspects like vulnerability lookups, DNS operations, and IP analysis, avoiding bloat while providing comprehensive functionality for the domain.

Completeness5/5

The tool set offers complete coverage for Shodan's domain, including vulnerability databases (CPE, CVE, product-specific), DNS services (forward and reverse lookups), IP intelligence, and device searches. There are no obvious gaps; agents can perform core workflows from reconnaissance to detailed analysis without dead ends.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Shodan MCP Server

    X3r0K
    F
    license
    Not graded
    quality
    D
    maintenance
    A WebSocket server that provides MCP interface for searching and retrieving information about internet-connected devices, IP addresses, DNS data, and CVE vulnerabilities through the Shodan API.
    3
    -

  • Shodan-MCP-Server

    X3r0K
    F
    license
    Not graded
    quality
    D
    maintenance
    This is a Model Context Protocol (MCP) server that provides access to the Shodan API. It allows you to programmatically query Shodan for information about devices, vulnerabilities, and more.
    2
    -

  • Shodan MCP Server

    irootsec
    F
    license
    Not graded
    quality
    D
    maintenance
    Integrates Shodan search capabilities into MCP-compatible applications for discovering internet-connected devices. Enables domain searches, IP lookups, and advanced queries to identify exposed services, infrastructure mapping, and security analysis.
    3
    -

Appeared in Searches

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/w0h1v/mcp-shodan'

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