shodan-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct Shodan resource and action: CVE lookup, CVE-by-product, host count, DNS resolve/reverse/domain, host lookup, search, filters, account info, and my IP. There is no functional overlap; even similar tools like host_count and search are clearly differentiated by purpose.
Naming Consistency4/5
All tools share the 'shodan_' prefix and mostly follow a descriptive pattern of resource-action or resource-attribute (e.g., cve_lookup, dns_resolve, host_count). Minor exceptions like 'my_ip' and 'cves_by_product' are still predictable and readable.
Tool Count5/5
11 tools is a well-scoped count for a Shodan MCP server. It covers the major Shodan API surfaces (CVE, DNS, host, search, account) without unnecessary bloat or missing essentials.
Completeness4/5
The set covers the core Shodan workflows: search, host details, DNS reconnaissance, CVE intelligence, and credit management. Some advanced features like alerts or exploit lookups are absent, but the surface is complete enough for typical threat intelligence and infrastructure assessment tasks.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which tells the agent this is a safe read operation. The description adds no extra behavioral context such as output format, rate limits, or error conditions. The phrase 'associated hostnames' is the only addition, but that is already implicit in the schema and title, so it adds little value.
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 a single, focused sentence with no fluff or irrelevant details. It is front-loaded with the action and resource, making it easy to parse quickly.
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 1-parameter tool with annotations, the description is adequate but not thorough. There is no output schema, so the description could have clarified the return format (e.g., a mapping of IPs to hostnames) and could have mentioned that this is the reverse counterpart to shodan_dns_resolve. Given its simplicity, the description is minimally complete but leaves room for improvement.
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 coverage is 100% (the single 'ips' parameter has a clear description). The tool description adds no further meaning beyond what the schema provides, only restating that it handles one or more IPs. 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 performs reverse DNS lookup, using a specific verb ('look up') and resource ('hostnames associated with IP addresses'). It does not explicitly differentiate from the sibling tool shodan_dns_resolve (forward lookup), so it doesn't earn a 5, but the purpose is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that shodan_dns_resolve is the forward-lookup counterpart, nor any context like prerequisites or typical use cases. The description implies usage by stating the function, but siblings are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already indicates a safe read operation. The description adds no further behavioral context, such as how resolution is performed (e.g., via Shodan's database), potential rate limits, or failure handling.
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 a single, efficient sentence that directly states the tool's purpose with no redundant text or fluff.
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?
For a simple one-parameter lookup tool, the description adequately indicates the action and result (IP addresses). It does not detail the output format, but the simplicity of the operation makes this less critical. However, there is no mention of error behavior, so a near-perfect score is warranted.
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% and the only parameter (hostnames) is fully described as a comma-separated list. The description's 'one or more' adds a slight nuance but does not significantly exceed schema information, so baseline 3 applies.
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 uses a specific verb ('Resolve') plus resource ('hostnames') and outcome ('to their IP addresses'). It clearly distinguishes from siblings like 'shodan_dns_reverse', which resolves IPs to hostnames.
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?
No guidance is provided about when to use this tool versus alternatives such as shodan_dns_reverse or shodan_dns_domain. The description only states the action without contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read nature is covered. The description adds the 'recent/known' qualifier and an example CPE, but does not disclose return format, pagination behavior, or any potential quirks like CPE format requirements beyond the example. This is similar to the TDQS 4.3 example, which scored a 3.
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 a single sentence with an example and a usage note. It is front-loaded, contains zero filler, and every piece of information earns its place.
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?
For a simple read-only tool with full schema coverage and no output schema, the description sufficiently explains what it does, what input is needed (with a direct example), and when to use it. The agent can confidently invoke the tool with minimal guesswork.
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 coverage is 100% with both 'cpe23' and 'limit' already described. The description's example adds a concrete illustration, but that is a minor addition over the schema. Baseline of 3 is appropriate.
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 a specific action ('List recent/known CVEs') and resource ('given a CPE product+version'), with a concrete example. It does not explicitly contrast with the sibling shodan_cve_lookup tool, but the focus on CPE rather than CVE ID provides implicit differentiation.
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 phrase 'Useful for tracking what's currently going on for a specific technology' provides a clear context for when to use the tool. It does not mention exclusions or alternatives, but the use case is specific enough to guide an agent.
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?
The description adds behavioral context beyond the readOnlyHint annotation by clarifying that data is what 'Shodan has seen,' implying historical/passive DNS data rather than a live query. It does not discuss potential limitations like data staleness or completeness, but the annotation already indicates a non-mutating operation, and the description adds meaningful context above that.
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 two sentences and front-loaded with the core function. The first sentence states the purpose, the second adds usage guidance. There is no redundant information or filler.
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?
The tool is simple with one parameter, and the description conveys the primary output (subdomains and DNS entries) and a clear use case. There is no output schema, but the description provides enough high-level context for an agent to understand what to expect. It could mention output format or that results are based on Shodan's historical database, but the current level is adequate for typical use.
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 fully describes the single 'domain' parameter with a clear example. The description does not add additional parameter-level semantics beyond restating 'for a domain,' so it provides no extra value over the schema's 100% coverage. The baseline of 3 applies.
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 states a specific verb ('Look up') and resource ('subdomains and DNS entries Shodan has seen for a domain'), clearly distinguishing it from sibling tools like shodan_dns_resolve and shodan_dns_reverse. It is immediately obvious 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to map out your own domain's exposed surface.' This gives context for when to use the tool, though it does not explicitly mention alternatives or when not to use it. That is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already discloses the read-only nature. The description adds valuable query syntax examples and a scale hint, but does not detail pagination behavior, rate limits, or output format. With annotations present, this is adequate but not deeply transparent.
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?
Two sentences, front-loaded with action and examples, then a succinct use case. No redundant or vague wording; every word contributes.
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?
For a search tool with 2 simple parameters and a read-only annotation, the description covers the essential query syntax and intended broad use. It omits mention of the return structure, but that is not critical for shaping the query, and pagination is captured in the schema. A small gap prevents a perfect score.
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 coverage is 100% with generic descriptions ('Shodan search query'). The description enriches the query parameter with real examples like 'apache country:DE' and 'vuln:CVE-2021-44228', adding meaning beyond the schema. The page parameter is not elaborated, but its schema description supplies the default.
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 action ('Search') and resource ('Shodan's database of internet-connected devices'), with concrete query examples that illustrate valid syntax. It distinguishes from sibling tools by positioning this as general reconnaissance rather than CVE-specific or DNS-specific lookups.
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 explicitly says 'Use this for general reconnaissance and world-scale intelligence gathering', providing clear when-to-use context. It does not name alternative tools or provide exclusions, but the stated use case is specific enough to guide selection.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context beyond annotations by specifying exactly what data is returned (CVSS score, affected CPEs, and current vulnerable host count), which is useful for an agent deciding whether to call it.
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 a single, front-loaded sentence that immediately states the action and resource. Every word contributes meaning: it names the source (CVEDB), the purpose (specific CVE details), and the key outputs, with no filler.
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?
For a tool with one required parameter and no output schema, the description is sufficiently complete. It explains what the tool does, what it returns, and the main data fields, enabling an agent to select and invoke it correctly without needing further elaboration.
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 coverage is 100%, with the parameter cve_id fully described as 'CVE identifier' and an example provided. The description does not add meaning beyond the schema beyond reinforcing that it is for a specific CVE, which is already implied by the schema field name and description.
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 uses the specific verb 'Fetch' and clearly identifies the resource: 'details for a specific CVE from Shodan's CVEDB'. It enumerates what is included (CVSS score, affected CPEs, host count), which differentiates it from sibling tools like shodan_cves_by_product.
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 clearly implies usage: use this when you have a specific CVE ID and need its details. It does not explicitly state when-not-to-use or mention alternatives, but the phrase 'for a specific CVE' provides clear context.
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 readOnlyHint=true already indicating a safe read operation, the description adds valuable behavioral context: 'without spending query credits' and 'quick' disclose cost and performance traits. It does not detail response format, but the count semantics are implied, so it goes beyond the annotation without contradicting it.
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 two sentences, front-loaded with the core action, and every part earns its place. It is concise and free of redundant wording, achieving high 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?
For a one-parameter tool with no output schema, the description fully covers what the tool does, when to use it, and its cost behavior. The return value (count) is clear from the description, making it contextually complete.
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 coverage is 100% for the single 'query' parameter, matching the description's 'Shodan search query.' The description adds no new syntax or format details beyond the schema, so the baseline 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 counts hosts matching a Shodan search query, distinguishing it from sibling tools like shodan_search by emphasizing it does not spend query credits. The verb 'count' and resource 'hosts' are specific, and the contrast with 'full search' differentiates it from search siblings.
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 explicit usage context: 'Use this for quick world-scale stats ... before running a full search.' It gives an example (CVE exposure) and implies the alternative of a full search, though it does not explicitly name the sibling tool or state when not to use it in detail.
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?
Annotations already declare readOnlyHint=true, and the description adds valuable context about the returned data (open ports, banners, products, vulnerabilities) beyond what annotations provide. It does not discuss rate limits or errors, but for a read-only single-IP lookup, the behavioral picture is adequately transparent.
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 two sentences, front-loaded with the core purpose and followed by concrete detail about what the lookup returns. Every sentence provides useful information with no redundancy or filler.
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?
For a simple read-only tool with one parameter and no output schema, the description effectively explains both the return content (ports, banners, products, vulnerabilities) and the intended use case. No important context is missing for correct selection and invocation.
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 schema covers 100% of the single parameter with a clear description ('IPv4 or IPv6 address to look up'). The tool description adds no additional semantic detail about the parameter beyond restating 'single IP address', so the baseline of 3 applies.
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 uses a specific verb ('Look up') with a clear resource ('single IP address') and enumerates the data returned (open ports, banners, products/versions, vulnerabilities). This clearly distinguishes it from sibling tools like shodan_search (which searches across many IPs) and shodan_cve_lookup (which focuses on CVEs).
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 a clear usage context ('Use this to check what your own infrastructure exposes'), which implies when this tool is appropriate. However, it does not explicitly mention alternatives or when-not-to-use, so it stops short of the highest score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, and the description aligns by stating it lists filters. It adds the example filters and the fact that it's a metadata lookup, but doesn't describe return format or any other behavior. Since this is a trivial read-only operation with no parameters, the description provides adequate but not exceptional transparency.
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?
Two sentences, front-loaded with the main action. The first sentence states function and examples; the second gives usage guidance. No redundant details.
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?
For a zero-parameter, read-only list tool, the description fully covers its purpose and usage context. It doesn't have an output schema, but the description doesn't need to explain return values for a simple list of filter names. The sibling tools are all distinct, and this description positions the tool correctly.
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?
No parameters exist, and the input schema confirms an empty properties object. Per the rubric, 0 parameters yields a baseline of 4. The description doesn't need to explain any parameters.
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 uses a specific verb 'List' with a clear resource 'search filters Shodan supports,' and provides concrete examples (country, port, net, vuln, product). This clearly distinguishes it from sibling tools like shodan_search, which executes queries, while this is about filter metadata.
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?
Explicitly states when to use: 'before writing a shodan_search query' and purpose 'to confirm the right filter name.' This provides clear context for an AI agent. It doesn't explicitly mention alternatives or when not to use it, but the instruction is sufficient.
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?
Beyond the readOnlyHint annotation, the description discloses an important nuance: the IP is from Shodan's perspective ('Shodan sees'), not necessarily the local machine's IP. This adds context about the tool's behavior and helps set expectations for the returned value.
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?
Two sentences, no filler. The first sentence states the core function, and the second provides usage context. Every word earns its place, and the structure is front-loaded with the key verb.
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?
For a read-only, zero-parameter tool with no output schema, the description is complete. It explains what the tool returns, the source of the IP, and a recommended use case. No additional information is necessary for an agent to select and invoke it correctly.
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?
The tool has zero parameters, so the schema covers 100% of the parameter space. The description adds semantic meaning by explaining what the output represents, which is more valuable than a bare schema. Since there are no parameters, a baseline of 4 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 action: 'Returns the public IP address Shodan sees this API key's requests coming from.' This is a specific verb+resource (returns public IP) and distinguishes itself from sibling tools that handle CVEs, DNS, host lookup, and search.
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?
It provides a clear use case: 'Use this as the starting point for scanning your own infrastructure.' This gives the agent context for when to invoke it, though it doesn't explicitly mention alternatives or when-not-to-use. The guidance is sufficient for a simple tool.
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?
The readOnlyHint annotation already ensures the agent knows it's safe. The description adds context about the specific information returned and the operational purpose (monitoring credits), which is useful beyond the annotation.
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?
Two sentences, tightly packed with purpose and usage guidance. No filler words, and the most important information (what it shows) is first.
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?
For a simple, read-only tool with no parameters and no output schema, the description fully communicates what the agent will receive (plan and credits) and why to use it. It is complete for the tool's complexity.
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 zero parameters, the schema is fully covered; the description adds context about what the tool accesses (the API key's plan and credits) rather than parameter syntax, which is not needed. Baseline for 0 params is 4.
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 a specific verb ('Show') and resource ('this API key's plan and remaining query/scan credits'). It is distinct from sibling tools, which all perform lookups or searches, not account-level information queries.
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?
Explicitly advises to 'Check this before running credit-consuming operations,' which tells the agent when to use this tool and why. Though no alternative tool is named, the guidance is clear and actionable.
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:

[![shodan-mcp MCP server](https://glama.ai/mcp/servers/aethrox/shodan-mcp/badges/card.svg)](https://glama.ai/mcp/servers/aethrox/shodan-mcp)

Score Badge

Copy to your README.md:

[![shodan-mcp MCP server](https://glama.ai/mcp/servers/aethrox/shodan-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aethrox/shodan-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/aethrox/shodan-mcp'

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