Skip to main content
Glama
badchars

osint-mcp-server

by badchars

shodan_dns_resolve

Resolve hostnames to IP addresses using Shodan's DNS resolver for network reconnaissance and mapping.

Instructions

Resolve hostnames to IPs using Shodan's DNS resolver. Requires SHODAN_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostnamesYesHostnames to resolve

Implementation Reference

  • Core handler function that calls the Shodan DNS resolve API. Takes hostnames array and API key, returns a record mapping hostnames to IPs (or null).
    export async function shodanDnsResolve(hostnames: string[], apiKey: string): Promise<Record<string, string | null>> {
      await limiter.acquire();
      const csv = hostnames.join(",");
      const res = await fetch(`https://api.shodan.io/dns/resolve?hostnames=${encodeURIComponent(csv)}&key=${apiKey}`);
      if (!res.ok) throw new Error(`Shodan DNS resolve failed: ${res.status}`);
      return res.json();
    }
  • Zod schema for the shodan_dns_resolve tool: expects an array of hostname strings.
    schema: {
      hostnames: z.array(z.string()).describe("Hostnames to resolve"),
    },
  • ToolDef registration for shodan_dns_resolve: defines name, description, schema, and execute handler that calls shodanDnsResolve.
    const shodanDnsResolveTool: ToolDef = {
      name: "shodan_dns_resolve",
      description: "Resolve hostnames to IPs using Shodan's DNS resolver. Requires SHODAN_API_KEY.",
      schema: {
        hostnames: z.array(z.string()).describe("Hostnames to resolve"),
      },
      execute: async (args, ctx) => {
        const key = requireApiKey(ctx.config.shodanApiKey, "Shodan", "SHODAN_API_KEY");
        return json(await shodanDnsResolve(args.hostnames as string[], key));
      },
    };
  • The tool is included in the allTools array, registering it with the MCP system.
    shodanDnsResolveTool,
  • src/index.ts:36-36 (registration)
    shodan_dns_resolve listed under the 'Shodan' tool category with env requirement SHODAN_API_KEY.
    { label: "Shodan", env: "SHODAN_API_KEY", tools: ["shodan_host", "shodan_search", "shodan_dns_resolve", "shodan_exploits"] },
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not disclose any traits like rate limits, error behavior, or whether the resolver is authoritative. The simple 'resolve hostnames to IPs' lacks depth for an agent to anticipate outcomes 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 extremely concise with two sentences and zero waste. It front-loads the core purpose and follows with a critical prerequisite. Every word earns its place, making it efficient for an AI agent to parse.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description is minimally complete. It covers the basic use case and a dependency. However, it lacks context on how the tool fits among siblings (e.g., why use this over dns_lookup) and omits behavior like batch limits or response structure, which would be helpful for an agent.

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% coverage for the single parameter 'hostnames', which already describes it as 'Hostnames to resolve'. The description reinforces the purpose but adds no new semantic details about the parameter format, limits, or how multiple hostnames are handled. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool resolves hostnames to IPs using Shodan's DNS resolver. It is specific about the action and resource, though it does not differentiate from sibling tools like dns_lookup or shodan_host that might perform similar functions. The mention of Shodan provides context, but clarity could be improved by noting what distinguishes this from other DNS tools.

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

Usage Guidelines2/5

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

The description only mentions a prerequisite (requires SHODAN_API_KEY) but provides no guidance on when to use this tool versus alternatives such as dns_lookup, dns_reverse, or shodan_host. There is no when-not or explicit context for selection, leaving the agent to infer usage from the tool name alone.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/badchars/osint-mcp-server'

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