fingerprint-mcp

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: passive analysis, active scanning (DNS, HTTP, paths, ports, services, TLS, WAF), OSINT, enumeration, correlation, and meta. Descriptions provide detailed technique lists, eliminating ambiguity.
Naming Consistency5/5
All tool names use lowercase with underscores, following a consistent verb_noun pattern (e.g., scan_dns, analyze, osint). No mixing of styles, making the naming predictable.
Tool Count5/5
13 tools cover the fingerprinting domain comprehensively without excess. Each tool represents a core capability, and the count is well-scoped for the server's purpose.
Completeness5/5
The toolset covers passive analysis, multiple scanning layers (DNS, HTTP, ports, services, TLS, WAF, paths), OSINT, enumeration, correlation, and meta-info. No obvious gaps for the fingerprinting domain.
Average 3.6/5 across 13 of 13 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or potential side effects. While the description implies analytic operations, it fails to clarify what happens with invalid inputs or whether it modifies any state.
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 a single sentence that lists multiple capabilities side by side. It is concise but dense, making it harder to parse quickly. There is no use of structure (e.g., bullet points) to separate different correlation types. The core purpose is front-loaded, but the list is somewhat run-on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 31 parameters, complex nested schemas, and no output schema. The description does not explain return values, error handling, or how the 'type' field determines which parameters are relevant. Given the complexity and lack of annotations, the description is insufficient for selecting proper input combinations or interpreting results.
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 each parameter clearly documented (including nested objects). The tool description adds no additional meaning beyond the schema's parameter descriptions. For each parameter, the schema already indicates its purpose (e.g., 'for c2', 'for topology'), so the description does not further enhance semantics.
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 is a 'Cross-layer correlation engine' and lists specific actions like validation, detection, comparison, topology reconstruction, and C2 detection. The verb 'correlate' with specific outcomes is well-defined, but it does not differentiate from sibling tools like 'analyze' or 'enumerate', which may overlap.
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 on when to use this tool versus alternatives. There is no mention of prerequisites, data needed, or scenarios where other tools (e.g., scan_*) would be more appropriate. The description only lists capabilities without context.
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?
With no annotations, the description must disclose behavior. It mentions '7 techniques in a single call' but omits critical details like rate limits, authentication, error handling, or whether it's read-only.
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 a single sentence listing 7 techniques, efficiently conveying scope without wasted words. It could be better structured but is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about return format or usage constraints. It only lists techniques but not what the output contains.
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 has 100% coverage for the single parameter 'domain' described as 'Target domain'. The description adds no extra semantic meaning, so 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 it's a comprehensive DNS intelligence tool, listing 7 specific techniques and differentiating from sibling tools like scan_http and scan_ports.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites.
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?
No annotations are provided, so the description must carry full burden. It mentions 'attack payload probing' which could be destructive, but fails to warn about potential consequences like triggering alarms or legal issues. Conditional origin discovery is noted but not explained.
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 a single sentence that efficiently lists all techniques, though it is somewhat dense. It is front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, and the description does not describe what the tool returns. Given the complexity (four techniques), this is a significant gap. Also lacks safety context.
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?
Only one parameter (url) with 100% schema description coverage. The description adds no extra meaning beyond 'Target URL for WAF/CDN analysis' already in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'WAF and CDN analysis' and lists four specific techniques (WAF identification, CDN detection, WAF fingerprinting, origin IP discovery). It clearly distinguishes from sibling scan tools like scan_ports and scan_http which target different aspects.
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 assessing WAF/CDN configuration but does not explicitly state when to use versus alternatives such as other scan tools. No guidance on prerequisites or when not to use.
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?
No annotations are provided, so description must convey behavioral traits. It mentions 'smart skipping' but does not disclose if the tool is destructive, read-only, requires authentication, or has rate limits. Safety profile is unclear for a scanning 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 efficiently front-loads the purpose and lists techniques in a compact, comma-separated manner. No redundant text, though the list is long; still earns its space.
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 complexity (29 techniques) and lack of output schema, the description omits details on result format, error handling, and usage constraints. Adequate but leaves gaps for an AI 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?
Schema coverage is 100% with a single parameter 'url' described as 'Target URL for HTTP fingerprinting'. The description adds no further parameter-level details, meeting the baseline for high coverage but providing no 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?
Description clearly states the tool performs comprehensive HTTP and web fingerprinting, listing numerous specific techniques. It distinguishes itself from sibling scan tools (like scan_ports, scan_dns) by focusing solely on web-layer reconnaissance.
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 use for in-depth HTTP analysis but does not explicitly contrast with alternatives or state when not to use it. 'Smart skipping' hints at efficiency, but no clear when-to/when-not-to guidance.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It lists techniques but does not mention side effects, resource usage, or any constraints. For a tool performing scans, information on rate limits or read-only nature is missing.
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?
Description is a single, efficient sentence that front-loads the core purpose and lists techniques concisely. No unnecessary words.
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 complex tool with 8 techniques and no output schema, the description adequately summarizes capabilities but lacks detail on output format or return value structure, which may be needed for an agent to fully understand the result.
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 baseline is 3. Description does not add any parameter-level meaning beyond the schema. Parameters are simple and well-documented in 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?
Description clearly states 'Complete TLS/SSL analysis' and enumerates 8 specific techniques, providing a specific verb+resource pair. It distinguishes from sibling scanning tools by focusing solely on TLS.
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?
Description implies comprehensiveness with '8 techniques in a single call' but does not explicitly state when to use this tool over alternatives like scan_ports or scan_http. No when-not or alternative tool advice.
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?
No annotations are provided, so the description must fully disclose behavioral traits. While the description mentions many techniques, it does not state whether the tool is destructive, requires authentication, has rate limits, or provides any output format details. This is a significant gap for a tool performing multiple phases of operations.
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 front-loaded with 'Scope expansion' but then lists 8 techniques in a verbose manner. While informative, it could be more concise. The summary '8 techniques across 3 phases' adds structure but the description overall feels slightly bloated for a parameter of one.
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 complex nature of the tool (8 techniques, 3 phases) and lack of output schema, the description provides a high-level overview of capabilities but omits details on phases, output format, or expected behavior. It partially compensates for missing annotations but is not fully complete for an agent to understand all aspects.
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 schema has 100% coverage for the single 'domain' parameter with description 'Target domain for scope expansion'. The tool description adds additional meaning by listing the specific enumeration techniques applied, providing context that helps the agent understand the scope of operations, going beyond the simple schema 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 clearly states the tool's purpose: scope expansion through various enumeration techniques like subdomain enumeration, wildcard DNS detection, TLD expansion, etc. It uses specific verbs and clearly distinguishes from sibling tools such as scan_dns or analyze, which focus on scanning or analysis.
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 does not explicitly state when to use this tool versus alternatives. While the context of 'scope expansion' implies it is for initial reconnaissance, there is no guidance on prerequisites or when not to use it, leaving the agent to infer usage.
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?
With no annotations provided, the description carries the full burden. It states the tool returns a listing, implying a read-only operation, but does not disclose any behavioral traits like authentication needs, rate limits, or potential side effects. The description is adequate but not detailed.
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 that efficiently conveys the tool's purpose. It is front-loaded with 'Server info' and lists contents without unnecessary 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 absence of annotations and output schema, the description provides a clear idea of what the tool returns. It mentions all key categories (providers, tools, configuration, signature databases). However, it lacks details on output structure or pagination, which would be beneficial for a meta 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 baseline is 3. The description does not add any meaning beyond the schema; the schema already documents the optional 'category' parameter. No enrichment is provided.
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 lists server information including providers, tools, configuration, and signature databases. This is a specific verb-resource combination that distinguishes it from sibling tools which focus on specific actions like scanning or enumeration.
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 on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or context for using this meta tool over action-oriented siblings.
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?
No annotations are provided, so the description must disclose behavioral traits. It lists six techniques but does not explain whether the tool is read-only, has rate limits, requires authentication, or what side effects (if any) occur. The return format is not described.
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 concise sentence that efficiently communicates the tool's functionality without redundant information. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain the return format or structure of results for the six techniques. It fails to do so, leaving the agent uncertain about what to expect from the call.
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%. The description adds value by explaining the 'type' parameter is auto-detected if omitted, which is not in the schema. However, it does not elaborate on the 'target' parameter beyond 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 as OSINT enrichment with a specific list of techniques (Shodan, Censys, etc.) and targets (IP/domain). It distinguishes itself from sibling scanning tools by focusing on external intelligence gathering rather than active scanning.
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 mentions auto-detection of target type but does not provide explicit guidance on when to use this tool versus alternatives like 'recon' or 'scan_ports'. No when-not-to-use or prerequisite information is given.
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: it discloses that it probes ports, reads banners, detects protocols (listing examples), and runs targeted fingerprinting. It does not cover limitations (e.g., firewall impact) or what it does not do, but overall it provides a clear view of the tool's actions.
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 long, no wasted words. It front-loads the core function in the first sentence and elaborates in the second. Every sentence adds value.
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 (two simple params, no output schema), the description covers the main functionality. It mentions detected protocols and fingerprinting. It lacks details on return format or error handling, but for a port scanner the description is largely sufficient.
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 descriptions for 'host' (target host) and 'ports' (default common ports). The description adds that it probes specified ports and defaults to common service ports, aligning with the schema. No additional syntax or constraints are provided, so baseline 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 it performs TCP port scanning with banner grabbing and automatic service detection, listing specific protocols. It is a specific verb+resource combination. While the purpose is clear, it does not explicitly differentiate from sibling tools like scan_services, which also deals with service detection.
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 provides context on what the tool does but offers no guidance on when to use it vs. alternatives, nor does it mention any prerequisites, exclusion criteria, or scenarios where it should not be used. The sibling tools include more specialized scans (scan_dns, scan_http) and analytic tools, but no comparison is made.
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?
With no annotations, the description carries full burden. It lists techniques but does not disclose behavioral traits like read-only nature, authorization requirements, rate limits, or whether results are returned synchronously. The mention of severity ratings hints at output but lacks depth.
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 wasted words. First sentence front-loads the key capabilities. Second sentence emphasizes efficiency. Every sentence earns its place.
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?
No output schema, so description should explain return values. It mentions 'severity ratings' but does not describe the output format or structure. Lacks completeness for an agent to fully understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds context about 200+ paths and 11 categories, but does not add parameter-specific meaning beyond what the schema already provides (e.g., enum values or validation rules).
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: path intelligence probing of sensitive files and directories across multiple categories, with specific techniques like robots.txt parsing, secret detection, and debug endpoint discovery. It distinguishes from siblings by emphasizing 200+ paths and 5 techniques in one call.
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?
No explicit guidance on when to use this tool versus alternatives like 'enumerate' or 'scan_http'. The description implies it's a comprehensive path probe but does not provide exclusions or when-not-to-use scenarios.
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?
Without annotations, the description carries the full burden. It clearly states the tool is passive and makes no network calls, which is transparent. However, it does not disclose error handling, return format, or edge cases, which would be helpful for a multi-mode analysis 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 extremely concise: two sentences that cover purpose, behavioral trait, and the three modes. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, nested objects, and no output schema, the description is too minimal. It does not explain what each analysis mode returns or provide guidance on expected output, which is necessary for an agent to use the tool effectively without external documentation.
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 baseline is 3. The description reinforces the parameter roles by grouping them under the three modes, but does not add significant new meaning beyond the schema descriptions. It clarifies which parameters apply to which mode, which is helpful but not enough to raise the score.
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 passive analysis of pre-collected data, which is a specific verb+resource. It also lists three distinct modes (headers, html, banner), effectively distinguishing it from sibling tools that likely involve active scanning or other operations.
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 indicates the tool is for passive analysis without network calls, implying when to use it (pre-collected data). However, it does not explicitly mention when not to use it or suggest alternative tools, though the sibling context provides some implicit differentiation.
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?
With no annotations, the description must fully convey behavioral traits. It outlines the types of analysis performed and depth options, but lacks details on rate limits, resource intensity, data persistence, or error handling. The description adds moderate value but could be more explicit about potential impacts.
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 concise sentences: purpose, depth guidance, and depth details. No redundancy, front-loaded with key information. Every sentence earns its place.
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 complexity (multiple techniques), the description covers the 'what' but omits the 'what you get back' since no output schema exists. It does not mention return structure or result format, which is a notable gap for an AI agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for both parameters. The description enriches the 'depth' parameter by detailing technique counts per enum value, providing clear decision-making context beyond the schema. For 'url', it adds an example format, reinforcing usage.
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 full target reconnaissance, listing specific techniques (HTTP headers, TLS, DNS, etc.) and distinguishes itself from sibling tools that focus on single aspects. The verb 'recon' is well-explained.
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 explains when to use different depth levels (quick, standard, deep) with technique counts, providing clear guidance on scope. However, it does not explicitly contrast with sibling tools for when to use this combined tool versus individual scans, leaving a slight gap.
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, the description discloses key behaviors: auto-detection, full audit for SSH, TLS check for SMTP. This is valuable beyond the schema.
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, zero waste. Front-loaded with purpose and service types, followed by detection modes and specific probes. Efficiently structured.
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 no output schema, the description adequately explains what the tool does and its capabilities. It covers purpose, detection modes, and service coverage, making it complete for an agent to decide when to use.
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 descriptions. The description adds context about auto-detection and lists all service enum values, enhancing understanding but not adding new parameter specifics.
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 it performs service-level fingerprinting for specific services (databases, caches, remote desktop, SSH, SMTP, IoT). It distinguishes from siblings like scan_ports by focusing on fingerprinting rather than just port scanning.
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 for fingerprinting services, supports auto-detection or explicit selection. It doesn't explicitly state when not to use or name alternatives, but the context from siblings is sufficient.
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:

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

Score Badge

Copy to your README.md:

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

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