Skip to main content
Glama

netintel_cloud_fingerprint

Detect a domain's CDN, WAF, hosting, DNS, and email providers, plus TLS issuer, wildcard coverage, and SAN count with confidence scores and an infrastructure security grade.

Instructions

Detect CDN, WAF, hosting, DNS and email provider for a domain, plus TLS certificate issuer, wildcard coverage and SAN count, with confidence scores and an infrastructure security grade. Hosts that resolve but serve nothing on 80/443 return http_reachable:false and grade insufficient_data rather than a low grade.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.61

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose useful edge-case behavior (hosts resolving but serving nothing on 80/443 yield http_reachable:false and grade 'insufficient_data') and the presence of confidence scores, but says nothing about permissions, rate limits, or latency, leaving a meaningful gap for a network-probing 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?

Two sentences, both load-bearing: the first front-loads the capability and output fields, the second captures a genuinely non-obvious edge case. No filler or repetition of the tool name.

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?

With no output schema and no annotations, the description does the heavy lifting by enumerating return fields and the insufficient_data edge case, which is enough to call and interpret the tool. The missing sibling disambiguation and input-format detail keep it from a 5.

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?

There is one parameter ('domain') at 0% schema description coverage, so the description is the only source of meaning. It implies the input is a domain, but does not specify format (bare host vs. URL vs. scheme) or how subdomains are treated, adding little beyond the self-evident schema.

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 names a specific verb ('Detect') and enumerates the exact resources probed (CDN, WAF, hosting, DNS, email provider, TLS issuer, wildcard coverage, SAN count, security grade), so the agent knows precisely what comes back. It falls short of a 5 only because it never distinguishes itself from close siblings like netintel_tech_fingerprint or netintel_ssl_analyze.

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 pick this tool over the overlapping netintel_tech_fingerprint, netintel_ssl_analyze, netintel_dns_lookup or netintel_cert_transparency siblings, and no prerequisites or exclusions stated. The single host-with-nothing-served note is a behavior, not a routing hint.

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

Deploy Server

Other Tools