recon
PYPI · RECON-TOOL
Public DNS, certificate transparency, and identity observations.
Available components
Last scanned (2 hours ago)
Scores higher than 69% of PyPI servers
Category Security
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security99
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 5 of 45 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency74
- Repository check failed: the declared repository URL redirects; it must resolve directly. See how to fix → View diagnostics → Fail
- Cryptographically verified build provenance (signed, bound to blisspixel/recon). View diagnostics → Pass
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 1 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability73
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 8279 tokens (~285/item across 29 items; 23 tools + 6 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 25 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Unverified: 1 category
A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 5 Nov 26 +15
- Malware scan: unverified → pass ▲ security
- 30 Oct 26 −21
- Malware scan: pass → unverified ▼ security
- Source repository: pass → fail ▼ security
- 29 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- 28 Oct 26 64
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed pypi/recon-tool@2.27.0
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | blisspixel/recon |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/blisspixel/recon/.github/workflows/release.yml@refs/tags/v2.27.0 |
| Rekor log index | 3529986576 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:28e8a9f639569accb1861ef8bbb8a9d117e34b7766722e888f54fa03e1e87fac |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 45 packages
| Packages resolved | 45 |
|---|---|
| Stale | 4 |
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
analyze_posture Analyze posture ~252
Analyze a domain's configuration posture and return neutral observations. Returns factual observations about the domain's email security, identity, infrastructure, SaaS footprint, certificate activity, and configuration consistency. Observations are neutral - they describe what is, not what should be. Args: domain: A domain name to analyze (e.g., "gamma.invalid") explain: When true, include explanation data for each posture observation. profile: Optional profile name (e.g. "fintech", "healthcare", "saas-b2b", "high-value-target", "public-sector"). Reweights and filters observations to the profile's lens. It may add explicitly profile-relative expectations from already collected evidence, but withholds those expectations when collection is degraded. Returns: A list of observation objects by default. Profile mode returns an envelope with ``observations`` and ``profile_note``. Explain mode returns an envelope with ``observations`` and ``explanations``, plus ``profile_note`` when a profile supplies one.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| explain | boolean | – | – |
| profile | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
assess_exposure Assess exposure ~205
Summarize a domain's public configuration evidence for defensive review. This is a model-bound public-evidence assessment, not an overall security score or certification. Returns a structured JSON object containing public email, identity, infrastructure, configuration-consistency, and hardening observations. The compatibility field ``posture_score`` is a 0-100 index based only on publicly observable controls. The score counts only controls with exact retained evidence, so it is a floor. The ``observability`` block carries the complete weighted component ledger, generation rule, basis state, typed predicates, bounded scope, retained evidence, modeled ceiling, and unavailable controls. Report the floor with its ceiling; a low floor can mean "quiet", not "weak". Args: domain: A domain name to assess (e.g., "gamma.invalid") Returns: JSON object with the full exposure assessment, or an error message.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| consistency_observations | array | yes | – |
| disclaimer | string | yes | – |
| domain | string | yes | – |
| email_posture | – | yes | – |
| evidence | array | yes | – |
| hardening_status | – | yes | – |
| identity_posture | – | yes | – |
| infrastructure_footprint | – | yes | – |
| observability | – | yes | – |
| posture_score | integer | yes | – |
| posture_score_label | string | yes | – |
No examples provided.
build_review_bundle Build review bundle ~232
Build one fresh, evidence-linked NamespaceReviewBundle artifact. The tool bypasses recon's lookup-result cache and performs exactly one ordinary passive resolution for the caller-supplied namespace. Direct probes are always disabled. Certificate-transparency collection remains on by default and can be disabled with ``no_ct``. The explained lookup, source-opportunity states, evidence ledger, and review candidates all derive from the same in-memory result. The returned artifact is a public-metadata handoff, not a security score, vulnerability finding, compliance result, ownership conclusion, or proof of active product use. Its digest detects modification but is not a digital signature or collector authentication. Args: domain: Namespace coordinate to reduce to its registrable apex. no_ct: Skip certificate-transparency providers when true. timeout_seconds: Aggregate resolution timeout, greater than zero and at most 600 seconds. Returns: A schema-version-1 ReviewBundle success or typed collection failure.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| no_ct | boolean | – | – |
| timeout_seconds | number | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| collection | object | yes | – |
| content_digest | string | yes | – |
| generated_at | string | yes | – |
| generator | object | yes | – |
| interpretation_context | object | yes | – |
| limitations | array | yes | – |
| record_type | string | yes | – |
| result | object | yes | – |
| schema_version | string | yes | – |
| scope | object | yes | – |
| scope_statement | string | yes | – |
| source_opportunities | array | yes | – |
| workflow | object | yes | – |
No examples provided.
chain_lookup Follow related domains ~221
Follow all `related_domains` observations; this does not establish ownership or a corporate relationship. Recursively follows every ``related_domains`` observation returned by each ordinary lookup, currently including CT, CNAME, Exchange/identity endpoint, autodiscover, and DKIM tenant-domain breadcrumbs. Each queued name can trigger another full public-metadata lookup. Co-occurrence does not establish common control, company affiliation, or current product use. Args: domain: Starting domain (e.g., "gamma.invalid") depth: Maximum recursion depth (1-3, default 1) result_limit: Optional compact-output cap. ``0`` returns the raw chain JSON. A positive value returns the first N domains in BFS chain order plus ``domains_omitted`` metadata. Returns: JSON object with total_domains, max_depth_reached, truncated flag, and an array of domain intelligence objects with chain_depth.
| Name | Type | Req | Description |
|---|---|---|---|
| depth | integer | – | – |
| domain | string | yes | – |
| result_limit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
clear_ephemeral_fingerprints Clear ephemeral fingerprints ~30
Remove all ephemeral fingerprints from this server process. Returns confirmation with the count of fingerprints removed.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| removed | integer | yes | – |
| status | string | yes | – |
No examples provided.
cluster_verification_tokens Cluster verification tokens ~357
Cluster a list of domains by shared site-verification tokens. For defensive OSINT and vendor due-diligence only. Looks up each domain (using the TTL cache when available) and computes a map of shared TXT verification tokens across the input set. When two domains share a ``google-site-verification=``, ``MS=``, Atlassian, Zoom, or similar token, it reports the exact administrative token reuse and does not infer a relationship. Exact token reuse is consistent with shared administration, copied configuration, a managed-services provider, or stale residue. The public record does not establish a shared account, operator, ownership, or current product use. The tool reports the observation and leaves synthesis to the caller. Zero additional network calls beyond whatever initial resolves are required to populate the cache. Every result is computed from cached TenantInfo. Args: domains: List of domain names to cluster. Must contain at least two distinct domains to be useful. Invalid domains are skipped with an error entry in the response. peer_limit_per_domain: Optional compact-output cap. ``0`` returns every observed peer entry. A positive value returns the first N entries per domain after deterministic ``(token, peer)`` sorting, plus ``peers_omitted`` counts. Returns: JSON object with ``clusters`` (a map from each domain to its peers via shared tokens) and ``errors`` (a list of domains that could not be resolved). Empty ``clusters`` means no shared tokens were observed - not an error.
| Name | Type | Req | Description |
|---|---|---|---|
| domains | array | yes | – |
| peer_limit_per_domain | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| clusters | object | yes | – |
| disclaimer | string | yes | – |
| errors | array | yes | – |
| peer_limit_per_domain | integer | yes | – |
| peers_omitted | object | yes | – |
| raw_request | string | yes | – |
| selection_rule | string | yes | – |
No examples provided.
compare_postures Compare postures ~173
Compare the public configuration evidence of two domains side by side. This is a model-bound comparison of public observations, not an overall security comparison or certification. Returns a structured comparison with side-by-side metrics, control differences, relative observations, and one exact component ledger per namespace. Treat each public-evidence index as a floor and bounded ceiling, never as an overall ranking of the two namespaces. Args: domain_a: First domain to compare (e.g., "gamma.invalid") domain_b: Second domain to compare (e.g., "alpha.invalid") Returns: A structured posture comparison. Raises ToolError (isError) when either domain is invalid or cannot be resolved (both must resolve to compare).
| Name | Type | Req | Description |
|---|---|---|---|
| domain_a | string | yes | – |
| domain_b | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| differences | array | yes | – |
| disclaimer | string | yes | – |
| domain_a | string | yes | – |
| domain_a_observability | – | yes | – |
| domain_b | string | yes | – |
| domain_b_observability | – | yes | – |
| metrics | array | yes | – |
| relative_assessment | array | yes | – |
No examples provided.
discover_fingerprint_candidates Discover fingerprint candidates ~409
Mine unclassified CNAME candidates; each requires independent triage. Bundles ``recon discover`` into one tool call: resolves the domain with unclassified-CNAME-chain capture, applies intra-org and already-covered filters, and returns a ranked candidate list ready for triage. A surviving unclassified suffix does not establish a third-party service, ownership, current use, or a reusable provider pattern. It may be first-party, shared, unrelated, or noise. Require independent vendor documentation or repeated validation evidence before proposing a new ``cname_target`` fingerprint. Use after a regular ``lookup_tenant`` call when you notice unclassified subdomains in the result, or proactively on any domain where you want to grow the catalogue. Pair with the ``/recon-fingerprint-triage`` skill (or apply the same triage rubric inline) to turn the output into YAML stanzas for ``recon_tool/data/fingerprints/surface.yaml``. Args: domain: A domain name to mine (e.g., ``alpha.invalid``). skip_ct: When true, skip cert-transparency providers (crt.sh, CertSpotter). Discovery falls back to common-subdomain probes and apex CNAME walks. Use for high-volume runs. keep_intra_org: When true, retain CNAME chains that look intra- organizational. Default ``false`` - false-positive prone but more inclusive when ``true``. min_count: Drop suffixes seen fewer than N times. Default 1 - for single-domain runs, every distinct chain matters. Returns: JSON array of candidate dicts: ``[{suffix, count, samples: [{subdomain, terminal, chain}]}, ...]``. Sorted by count desc, then suffix.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| keep_intra_org | boolean | – | – |
| min_count | integer | – | – |
| skip_ct | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
explain_dag Explain inference graph ~190
Render the v1.9 Bayesian evidence DAG for a domain. Produces a human-readable narrative of the inference: each node's posterior, the evidence that fired, and the parent dependencies that shaped it. Pair with ``get_posteriors`` when you want both the structured posteriors and the prose explanation. Stable v2.0+. Every posterior is a model-relative diagnostic, not a calibrated probability or a truth claim. Sparse-evidence nodes are flagged so the consumer does not over-interpret a confident-looking number. Args: domain: Apex domain to evaluate. output_format: ``"text"`` (default, plain English) or ``"dot"`` (Graphviz DOT for image rendering). Returns: Rendered DAG as a string in the requested format.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| output_format | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
explain_signal Explain signal ~135
Query a specific signal's trigger conditions and current state for a domain. Without a domain: returns the signal's definition, trigger conditions, and a list of conditions that would weaken or suppress the signal. With a domain: resolves the domain (using cache if available), evaluates the signal, and returns its current state with matched evidence and specific weakening conditions. Args: signal_name: Name of the signal to explain (required). domain: Optional domain to evaluate the signal against. Returns: JSON object with signal definition and evaluation state, or an error.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | – | – | – |
| signal_name | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | – | yes | – |
No examples provided.
export_graph Export infrastructure graph ~377
Return the raw CT co-occurrence graph (nodes + weighted edges). Companion to ``get_infrastructure_clusters``: surfaces the underlying graph that the Louvain pass partitioned. Nodes are SAN hostnames; edges carry the shared-cert count between each pair. Useful for Mermaid / GraphViz / CSV rendering pipelines that want to draw the structure directly. Edges are sorted by weight descending; both nodes and edges are capped - see ``recon_tool/infra_graph.MAX_GRAPH_NODES`` and ``MAX_EDGES_RETAINED`` for the bounds. ``cluster_assignment`` maps every surfaced node to the cluster id from the same report so downstream tools can colour the graph by community without re- running detection. No new network surface - the graph was already built during the last ``lookup_tenant``. Read-only exposure of computed state. Args: domain: Domain whose graph to export. Uses the TTL cache when available; otherwise resolves via the standard pipeline. node_limit: Optional compact-output cap. ``0`` returns every bounded node. A positive value selects top nodes by weighted degree descending, then hostname. edge_limit: Optional compact-output cap after node filtering. ``0`` returns every retained edge among surfaced nodes. Returns: JSON object with ``domain``, ``algorithm`` (mirroring the cluster report), ``node_count``, ``edge_count``, ``nodes`` (a sorted array of hostnames), ``edges`` (array of {source, target, shared_cert_count} records), and ``cluster_assignment`` (object mapping each surfaced node to its cluster_id).
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| edge_limit | integer | – | – |
| node_limit | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| algorithm | string | yes | – |
| cluster_assignment | object | yes | – |
| cluster_assignment_omitted | integer | yes | – |
| disclaimer | string | yes | – |
| domain | string | yes | – |
| edge_count | integer | yes | – |
| edge_limit | integer | yes | – |
| edges | array | yes | – |
| edges_omitted | integer | yes | – |
| node_count | integer | yes | – |
| node_limit | integer | yes | – |
| nodes | array | yes | – |
| nodes_omitted | integer | yes | – |
| raw_request | string | yes | – |
| selection_rule | string | yes | – |
No examples provided.
find_hardening_gaps Find hardening gaps ~188
Identify hardening opportunities in a domain's public configuration. This is a defensive review of public observations, not an overall security assessment or certification. Returns a gap-report object whose ``gaps`` array contains hardening prompts with an exact generator rule, typed metadata predicates, bounded observation scope, supporting evidence, and an ``observation_state``. The state separates observed weak configuration, bounded non-observation, unresolved hideable state, and an observed configuration inconsistency. The compatibility field ``absence_confirmable`` remains present. Report an unresolved hideable state as "not observed within the named scope", never as a confirmed gap. Args: domain: A domain name to analyze (e.g., "gamma.invalid") Returns: JSON object with the gap report, or an error message.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| degraded_sources | array | yes | – |
| disclaimer | string | yes | – |
| domain | string | yes | – |
| gaps | array | yes | – |
| unavailable_controls | array | yes | – |
No examples provided.
get_fingerprints List fingerprints ~232
List all loaded fingerprints with slugs, categories, and detection types. Returns a list of fingerprint summaries from both built-in and custom sources. Each entry includes name, slug, category, confidence, match_mode, provider_group, display_group, and the set of detection types used. The MCP layer surfaces the list as navigable ``structuredContent`` with an ``outputSchema``, alongside the serialized-JSON text block for compatibility. These definitions are not evidence about any queried domain and do not establish product use. Args: category: Optional category filter using a word prefix or phrase. limit: Optional page size. With 800+ fingerprints loaded, an agent that only needs a slice can cap the response; omit (default) for the full list, which keeps the result shape backward-compatible. offset: Starting index for the page (default 0). Ignored without limit. Returns: A list of fingerprint summaries (a page of it when limit is given).
| Name | Type | Req | Description |
|---|---|---|---|
| category | – | – | – |
| limit | – | – | – |
| offset | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
get_infrastructure_clusters List infrastructure clusters ~393
Return the CT co-occurrence community-detection report for a domain. Surfaces the same ``infrastructure_clusters`` envelope that ships in the default ``--json`` output: cluster membership, modularity score, algorithm path, and underlying graph metrics. The report describes observable structure - names that co-occur on the same certificates, grouped by the Louvain co-occurrence heuristic, never an ownership claim. No new network surface: the report was already computed during the last ``lookup_tenant`` (or implicit resolve). This tool just exposes what the deterministic graph pass produced. Args: domain: Domain to look up. Will use the existing TTL cache when available; otherwise resolves via the standard pipeline. member_limit_per_cluster: Optional compact-output cap. ``0`` returns every surfaced member from the already bounded raw report. A positive value returns the first N sorted members from each cluster plus ``members_omitted`` counts. Returns: JSON object matching the ``InfrastructureClusterReport`` schema in ``docs/recon-schema.json``. The ``algorithm`` field reflects which path produced the partition (``louvain`` | ``connected_components`` | ``skipped``); ``skipped`` means the graph was empty or had no edges. ``partition_stability`` (2.2.0+) is the Louvain seed-sweep consensus (mean pairwise adjusted Rand index over ``stability_runs`` seeds; null outside the Louvain path). A value of 1.0 means every seed produced the identical partition; lower values show optimizer seed sensitivity on the same fixed graph. The field does not measure CT data stability, model stability, significance, or partition correctness.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| member_limit_per_cluster | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| algorithm | string | yes | – |
| clusters | array | yes | – |
| domain | string | yes | – |
| edge_count | integer | yes | – |
| member_limit_per_cluster | integer | yes | – |
| modularity | number | yes | – |
| node_count | integer | yes | – |
| partition_stability | – | yes | – |
| raw_request | string | yes | – |
| selection_rule | string | yes | – |
| stability_runs | integer | yes | – |
No examples provided.
get_posteriors Read posteriors ~563
Compute v1.9 Bayesian-network posteriors over high-level claims. Runs a normal recon lookup (cached + rate-limited like ``lookup_tenant``), then layers the Bayesian network at ``recon_tool/data/bayesian_network.yaml`` over the resulting evidence set. Returns a JSON object with one entry per node: ``name`` (str), ``description`` (str), ``posterior`` (float in [0, 1], model-relative), ``interval_low`` / ``interval_high`` (float, 80% evidence-responsive uncertainty band, not a credible or confidence interval), ``evidence_used`` (list of slug/signal bindings that fired), ``n_eff`` (effective display mass used to derive the band), ``sparse`` (bool, True at the display-mass floor), ``entropy_reduction_nats`` (float, 2.2.0+, signed marginal entropy change, not pointwise information gain), ``unit_counterfactuals`` (list, 2.2.0+, exact leave-one-unit-out re-inference per informative evidence unit: ``unit``, ``kind``, ``observed`` ("fired"/"absent"), ``posterior_without``, ``delta``; an evidence counterfactual over the model, never a causal claim, and deltas are not additive across units). The top level includes ``degraded_sources`` and ``collection_masked_units`` so a standalone call preserves collection provenance. A masked unit was structurally unobserved and contributed neither fired evidence nor declarative absence. The top level also carries ``sparse_count`` (how many nodes use the minimum display mass) beside ``evidence_count`` and ``conflict_count``. How to read it: both the mean and band are model-relative diagnostics, not facts. ``sparse=true`` means the display mass is at its floor. Absence of a hideable signal is ignored by explicit policy, not treated as evidence of absence. Inspect evidence and report unresolved when the public channel does not support the claim. Stable v2.0+. The CLI ``--fusion`` path can additionally compute a Beta evidence-strength layer named ``slug_confidences`` over raw evidence weights. This explicit MCP…
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| collection_masked_units | array | yes | – |
| conflict_count | integer | yes | – |
| degraded_sources | array | yes | – |
| domain | string | yes | – |
| entropy_reduction_nats | number | yes | – |
| evidence_count | integer | yes | – |
| posteriors | array | yes | – |
| sparse_count | integer | yes | – |
No examples provided.
get_signals List signals ~207
List reportable public signals with rules, layers, and conditions. Returns the public projection of signal definitions from both built-in and custom sources. Each entry includes name, category, confidence, description, candidates, min_matches, metadata conditions, contradicts, requires_signals, explain, and computed layer. The MCP layer surfaces the list as navigable ``structuredContent`` with an ``outputSchema``, alongside the serialized-JSON text block for compatibility. These definitions are not evidence about any queried domain and do not establish that a signal fired. Layers: 1=basic, 2=composite (has metadata), 3=consistency, 4=meta (requires_signals). Args: category: Optional category filter using a word prefix or phrase. layer: Optional layer filter (1, 2, 3, or 4). Returns: A list of signal definitions.
| Name | Type | Req | Description |
|---|---|---|---|
| category | – | – | – |
| layer | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
inject_ephemeral_fingerprint Inject ephemeral fingerprint ~273
Inject a temporary fingerprint into this server process. The fingerprint is validated through the same pipeline as built-in fingerprints (regex compilation, ReDoS safety, valid detection types). It lives in memory only and is discarded when the server process ends. Scope: process-wide, not per conversation. MCP 2026-07-28 states that a stdio process is not a session, so every request reaching this process sees every injected fingerprint, including requests from a different conversation with the same server. Treat this as server configuration you are changing rather than as private scratch space, and call `clear_ephemeral_fingerprints()` when the experiment is done. Args: name: Display name for the fingerprint (e.g., "Synthetic Delta Platform"). slug: Unique identifier (e.g., "delta-platform"). category: Category name (e.g., "SaaS"). confidence: Detection confidence - "high", "medium", or "low". detections: List of detection rules, each with "type" and "pattern" keys. Returns: Confirmation message or validation error.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | – |
| confidence | string | yes | – |
| detections | array | yes | – |
| name | string | yes | – |
| slug | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| detections_accepted | integer | yes | – |
| name | string | yes | – |
| slug | string | yes | – |
| status | string | yes | – |
No examples provided.
list_ephemeral_fingerprints List ephemeral fingerprints ~49
List all ephemeral fingerprints loaded in this server process. Returns a list of fingerprint summaries (navigable ``structuredContent`` plus the serialized-JSON text block at the MCP layer).
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | array | yes | – |
No examples provided.
lookup_tenant Look up domain ~276
Return compact text by default; JSON returns a detailed serialized record. The default is agent-readable text. Use ``format="json"`` for serialized JSON or ``markdown`` for a Markdown briefing. Public observations can include display label, tenant ID, provider indicators, email-control records, and signal correlations. Works for any domain. Returns catalogued public SaaS and infrastructure indicators plus claim-safe co-observations. A fingerprint match does not establish active use, organizational intent, deployment scope, or maturity. Queries only public DNS and unauthenticated endpoints. Authoritative DNS may observe resolver traffic. MTA-STS is the only default target-owned HTTP request; Google CSE and BIMI certificate probes require explicit opt-in. No credentials or API keys are required. Args: domain: A domain name to look up (e.g., alpha.invalid, gamma.invalid). format: Output format: "text" (default), "json" (structured), or "markdown" (briefing). explain: Include lineage-qualified explanations in the selected format. JSON also includes the structured provenance graph and conflicts. Returns: Domain intelligence in the requested format, or an error message.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| explain | boolean | – | – |
| format | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
reevaluate_domain Reevaluate cached domain ~148
Re-evaluate a previously looked-up domain against current fingerprints. Uses cached raw DNS data from a prior lookup with zero network calls. Newly loaded apex TXT/SPF, MX, NS, and apex/root CNAME rules are replayable. Rule types whose owner-qualified observations are not retained in the cache must be evaluated by a new lookup instead. Useful after injecting ephemeral fingerprints to test detection hypotheses. Args: domain: Domain to re-evaluate (must have been looked up previously). Returns: Updated domain intelligence as a structured object. Raises ToolError (isError) when the domain is invalid or absent from the process lookup cache.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| auth_type | – | yes | – |
| bimi_identity | – | yes | – |
| cert_summary | – | yes | – |
| chain_motifs | array | yes | – |
| cloud_instance | – | yes | – |
| confidence | string | yes | – |
| ct_attempt_outcome | – | yes | – |
| ct_cache_age_days | – | yes | – |
| ct_provider_used | – | yes | – |
| ct_subdomain_count | integer | yes | – |
| default_domain | string | yes | – |
| degraded_sources | array | yes | – |
| detection_scores | object | yes | – |
| display_name | string | yes | – |
| dmarc_pct | – | yes | – |
| dmarc_policy | – | yes | – |
| domain_count | integer | yes | – |
| email_gateway | – | yes | – |
| email_security_score | integer | yes | – |
| evidence | array | yes | – |
| evidence_confidence | string | yes | – |
| evidence_conflicts | array | yes | – |
| fingerprint_metadata | object | yes | – |
| fusion_enabled | boolean | yes | – |
| google_auth_type | – | yes | – |
| google_idp_name | – | yes | – |
| inference_confidence | string | yes | – |
| infrastructure_clusters | – | yes | – |
| insights | array | yes | – |
| lexical_observations | array | yes | – |
| likely_primary_email_provider | – | yes | – |
| msgraph_host | – | yes | – |
| mta_sts_mode | – | yes | – |
| partial | boolean | yes | – |
| posterior_observations | array | yes | – |
| primary_email_provider | – | yes | – |
| provider | string | yes | – |
| queried_domain | string | yes | – |
| record_type | string | yes | – |
| region | – | yes | – |
| related_domains | array | yes | – |
| schema_version | string | yes | – |
| services | array | yes | – |
| site_verification_tokens | array | yes | – |
| slug_confidences | object | yes | – |
| slugs | array | yes | – |
| sources | array | yes | – |
| surface_attributions | array | yes | – |
| tenant_domains | array | yes | – |
| tenant_id | – | yes | – |
| tenant_region_sub_scope | – | yes | – |
No examples provided.
reload_data Reload catalogs ~138
Reload fingerprint, signal, and posture definitions for this server process. Use this after updating the custom fingerprints.yaml / fingerprints/ or signals.yaml overlay in recon's config directory, or the built-in data files. The config directory is resolved, not fixed: an absolute RECON_CONFIG_DIR, else an existing legacy ~/.recon/, else $XDG_CONFIG_HOME/recon (default ~/.config/recon). Run `recon doctor` to print the resolved path. Clears the process lookup cache so subsequent lookups use the new definitions. Preserves the rate limiter and ephemeral catalog. No network request is made by this tool.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
simulate_hardening Simulate hardening ~175
Re-compute the public-evidence index with hypothetical fixes. Accepts a list of fix descriptions (e.g., "DMARC reject", "MTA-STS enforce") and simulates how the model-bound compatibility index would change if those fixes were applied. This is not a prediction of overall security change. Operates purely on cached pipeline data - zero additional network calls beyond the initial domain resolution. Args: domain: A domain name to simulate against (e.g., "gamma.invalid"). fixes: Array of fix descriptions or gap slugs to hypothetically apply. Returns: JSON object with current_score, simulated_score, score_delta, both exact component ledgers, applied_fixes, and remaining_gaps.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| fixes | array | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| applied_fixes | array | yes | – |
| current_observability | – | yes | – |
| current_score | integer | yes | – |
| disclaimer | string | yes | – |
| domain | string | yes | – |
| remaining_gaps | array | yes | – |
| score_delta | integer | yes | – |
| simulated_observability | – | yes | – |
| simulated_score | integer | yes | – |
No examples provided.
test_hypothesis Test hypothesis ~147
Test a theory about a domain against signals and evidence. Proposes a theory and receives related public observations; semantic likelihood remains explicitly unresolved. Passive catalog matches cannot validate active use, organizational intent, topology, or causal explanations. Operates purely on cached pipeline data - zero additional network calls beyond the initial domain resolution. Args: domain: A domain name to test against (e.g., "gamma.invalid"). hypothesis: A theory whose related public indicators should be listed. Returns: JSON object with unresolved likelihood, related and contradicting observations, missing evidence, and collection confidence.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | – |
| hypothesis | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| confidence | string | yes | – |
| contradicting_signals | array | yes | – |
| disclaimer | string | yes | – |
| domain | string | yes | – |
| hypothesis | string | yes | – |
| likelihood | string | yes | – |
| missing_evidence | array | yes | – |
| supporting_signals | array | yes | – |
No examples provided.
How do I install the recon MCP server?
recon runs locally as a PyPI package, launched with uvx recon-tool. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · recon-tool
claude mcp add blisspixel-recon -- uvx recon-tool
What is the recon MCP server?
recon is an MCP server listed in the public MCP registry as io.github.blisspixel/recon. Public DNS, certificate transparency, and identity observations. This page covers its PyPI package (recon-tool).
Is the recon MCP server safe to use?
recon scores 73 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the recon MCP server expose?
recon exposes 23 tools: lookup_tenant, build_review_bundle, analyze_posture, assess_exposure, find_hardening_gaps, and 18 more. Their descriptions and schemas cost roughly 5,370 tokens of context every time the server is loaded.
Is the recon MCP server still maintained?
recon is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the recon MCP server under?
recon declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.