How do I use Eidolon?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Eidolon scan my email for data breaches" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Eidolon

by sudohnim

Overview Schema Related Servers Score Discussions

Python

Local

Eidolon

Eidolon is a privacy-first approach to finding and understanding your digital footprint. The stack uses OSINT tools to gather information based on your search parameters, then a local LLM compiles it into a report. The LLM runs on your machine, so no data ever reaches an external service or leaves your box — you own your data.

What it does

Aggregates ~25 OSINT sources — breaches, leaked credentials, data brokers, account enumeration, public records, phone/email intel, exposed hosts — into a single risk report.
Maps findings to MITRE ATT&CK so you see what an attacker could actually do with what's exposed.
Flags AI-training exposure (which platforms may train on your data, and how to opt out).
Risk scoring and the leaked-credential dossier are deterministic — built from scan state, not the LLM — so the report survives an LLM hiccup. The model only writes narrative.
Outputs Markdown, PDF, and JSON.

Related MCP server: OSINT MCP Server

MCP-native

Eidolon runs as an MCP server, so you can drive it from any MCP client (Claude Desktop, Claude Code) — scan a target, list past scans, and read reports conversationally. It runs locally over stdio; your data never leaves the box.

Tools: scan_target, scan_status, list_scans, get_report, reveal_credentials. A scan takes minutes, so scan_target returns a scan_id immediately and runs in the background — poll scan_status(scan_id) until it reports done, then get_report(scan_id). The leaked-credential dossier (plaintext passwords from breach dumps) is redacted by default and only returned when you explicitly call reveal_credentials.

Requirements

Everything below is optional — Eidolon runs with whatever you give it and tells you, per source, what it couldn't check (no token) versus what it checked and found nothing.

Python 3.11+ and uv (required)
Ollama for the local LLM narrative: ollama pull llama3.1:8b — if it's down, the report is still produced deterministically (just no written narrative).
A running SpiderFoot instance — skipped if unreachable.
API keys — see .env.example. Each unlocks one data source and skips cleanly if absent (the report says "not checked — set X"). A scan with no keys is sparse but still runs.

New here? Start with the Setup & Configuration guide — which keys to get, what each one costs, and what it unlocks.

Quickstart

git clone https://github.com/sudohnim/eidolon && cd eidolon
uv sync
cp .env.example .env        # fill in your keys

# scan yourself from the CLI
uv run eidolon --email you@example.com

# or run the MCP server (stdio)
uv run eidolon-mcp

Use from Claude Desktop

Option 1 — from a local clone (loads .env from cwd):

{
  "mcpServers": {
    "eidolon": {
      "command": "uv",
      "args": ["run", "eidolon-mcp"],
      "cwd": "/absolute/path/to/eidolon"
    }
  }
}

Option 2 — from PyPI via uvx (recommended, no clone needed). Pass your keys in the env block:

{
  "mcpServers": {
    "eidolon": {
      "command": "uvx",
      "args": ["--from", "eidolon-osint", "eidolon-mcp"],
      "env": {
        "HIBP_API_KEY": "...",
        "DEHASHED_API_KEY": "...",
        "OLLAMA_HOST": "http://localhost:11434"
      }
    }
  }
}

Option 3 — straight from GitHub (pre-release / latest commit):

{
  "mcpServers": {
    "eidolon": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/sudohnim/eidolon", "eidolon-mcp"],
      "env": {
        "HIBP_API_KEY": "...",
        "DEHASHED_API_KEY": "...",
        "OLLAMA_HOST": "http://localhost:11434"
      }
    }
  }
}

Add only the keys you have — the rest skip cleanly. Then ask Claude to "scan my email"; it calls scan_target, polls scan_status, and reads the report.

How it works

A LangGraph pipeline: intake → wave 1 scans → wave 2 scans → MITRE mapping → correlation → analysis → report. Both the CLI and the MCP server call the same run_scan() core; reads go through a small repository layer. See docs/ROADMAP.md for the architecture and where it's headed (stateful history, continuous monitoring).

Intended use

Eidolon is for scanning yourself, or targets you are explicitly authorized to assess (authorized security testing, your own footprint). It surfaces real secrets, including plaintext passwords from breach dumps. Do not use it to profile or surveil people without their consent. You are responsible for complying with the terms of the data sources you configure and with applicable law.

License

AGPL-3.0. If you run a modified version as a network service, you must offer users its source.

Available Tools

5 tools

get_reportA

Return a scan's report. fmt is 'md' (default) or 'json'.

The markdown is returned with the leaked-credentials section removed; call reveal_credentials(scan_id) to see those.

ParametersJSON Schema

Name	Required	Description	Default
`fmt`	No		md
`scan_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden of disclosure. It clearly states that the markdown output omits the leaked-credentials section, which is a significant behavioral trait not inferable from the schema. It also notes the default format and the alternative for credentials. However, it doesn't mention error handling, permissions, or response structure beyond this.

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 concise sentences, front-loaded with the core purpose, and every sentence adds critical information. No fluff or repetition.

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 tool with two parameters and an output schema, the description covers the essential behavior, including format options and the credential removal caveat. It could benefit from a brief note on when to prefer this over scan_status/list_scans, but the output schema and sibling names fill some gaps.

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 provides no descriptions for the parameters (0% coverage). The description adds meaning to fmt by listing valid values 'md' (default) and 'json', and implicitly explains scan_id through the 'scan's report' context. While scan_id is self-explanatory, the fmt clarification is valuable.

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: returning a scan's report. It distinguishes itself from siblings by focusing on report retrieval, and mentions the fmt parameter for format selection. The verb 'return' and resource 'scan's report' are specific.

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 context by explaining the default format and the crucial caveat that leaked credentials are removed from markdown, directing users to reveal_credentials for that data. It doesn't explicitly contrast with scan_status or list_scans, but the purpose alone makes the distinction clear.

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

list_scansA

List previously run scans (newest first): scan_id, identifier, date, paths.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description adequately discloses the tool's output characteristics (newest first, specific fields). It provides transparency about what the tool returns without any hidden side effects.

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?

A single sentence that is direct and complete, with no wasted words.

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?

The tool is simple, and the description covers its key behavior and output ordering. With an output schema present, the description need not elaborate on return structure.

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 description mentions the output fields, which is sufficient since there is nothing to explain about input semantics.

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 previously run scans with a specific order (newest first), which distinguishes it from sibling tools like scan_status or get_report that serve different purposes.

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 makes it clear this is for retrieving past scans, providing a clear context for when to use it. It does not explicitly exclude other tools, but the context is unambiguous.

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

reveal_credentialsA

Return the leaked-credentials dossier for a scan (plaintext passwords).

This is the explicit gate for the most sensitive output — only call it when the user has clearly asked to see the actual leaked credentials.

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses that the tool exposes the most sensitive data (plaintext passwords) and sets an explicit invocation gate, a critical behavioral trait. However, it does not discuss authorization, logging, or error behavior, so it is not fully 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?

Three short lines with a clear front-loaded purpose followed by a critical gate note. Every sentence serves to clarify the tool's sensitive nature, with no redundant content.

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 single-parameter tool with an output schema, the description provides crucial usage context that helps an agent decide to invoke it. The main gap is the undocumented scan_id, but sibling tools likely provide this identifier. The sensitivity gate is well-covered, making it mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain scan_id beyond referencing 'a scan'. The name and context imply scan_id identifies the scan, but no format, source, or validation details are given. The description must compensate for the sparse schema and largely fails to do so.

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 'Return' and specific resource 'leaked-credentials dossier', clarifying it provides plaintext passwords. It distinguishes from sibling tools by labeling it the explicit gate for the most sensitive output, separating it from get_report or list_scans.

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?

Provides explicit when-to-use guidance: only call when the user clearly asked for actual leaked credentials. This implies when not to use it (e.g., if a user only wants a summary) and frames the tool as a gated operation.

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

scan_statusA

Check a scan started by scan_target: status is running | done | error.

When done, includes the headline result (risk, summary, top risks, report paths) and which sources were skipped because no API token was configured. Then call get_report(scan_id).

ParametersJSON Schema

Name	Required	Description	Default
`scan_id`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses possible statuses, what happens when done (includes headline result fields and skipped sources due to missing API tokens), and implies it's a read-only status check. It does not mention error/timeout behavior, so not a 5.

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 compact and front-loaded: the first clause states the core purpose, followed by concise status values and a clear 'when done' detail plus a direct next-step instruction. Every sentence earns its place with no 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?

Given a simple one-parameter tool with no output schema, the description covers the essential behavior: status outcomes, key result fields when complete, skipped sources, and recommended follow-up. It lacks a full return schema and edge-case behavior, but is reasonably 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only a bare 'scan_id' string with 0% coverage. The description adds context that scan_id refers to a scan initiated by scan_target, but does not clarify format, required source, or how to obtain it beyond implication. This partially compensates for the schema gap but is not fully descriptive.

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: 'Check a scan started by scan_target' with specific status outcomes (running, done, error). It distinguishes itself from siblings by focusing on status checking rather than starting (scan_target), listing (list_scans), reporting (get_report), or credential handling (reveal_credentials).

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 clear sequencing context ('Check a scan started by scan_target' and 'Then call get_report(scan_id)'), indicating when to use this tool in a workflow. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full exclusionary guidance.

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

scan_targetA

Start a privacy-OSINT scan. Returns immediately with a scan_id.

The scan runs in the background and takes several minutes. Poll scan_status(scan_id) until it reports "done", then call get_report(scan_id). Only one scan runs at a time. Provide at least one of email / phone / name (name works best with a city/state). Leaked credentials are never in the headline result — use reveal_credentials(scan_id) for those.

ParametersJSON Schema

Name	Required	Description	Default
`city`	No
`name`	No
`email`	No
`phone`	No
`state`	No
`zip_code`	No

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the scan runs in the background, takes several minutes, returns immediately with a scan_id, allows only one scan at a time, and that leaked credentials are not in the headline result. This is rich, non-obvious behavior beyond what structured fields could convey.

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 three tightly written sentences that deliver all essential information without padding. It front-loads the purpose and immediately follows with actionable workflow steps, constraints, and input requirements. Every sentence 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?

Despite having no output schema and no annotations, the description covers the essential context: the asynchronous nature, the return value (scan_id), the polling workflow, the concurrency limit, input prerequisites, and where to find sensitive data. This is complete for an agent to correctly select and invoke the tool.

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 input schema has 6 optional parameters with no descriptions, and the description compensates for most: it names email, phone, name, city, and state in context, and specifies that at least one of email/phone/name is required, with name working best alongside city/state. However, zip_code is not mentioned at all, leaving a small gap in parameter semantics.

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 opens with 'Start a privacy-OSINT scan,' clearly specifying both the action and the resource. It differentiates itself from sibling tools by mentioning the immediate return of a scan_id and directing users to subsequent tools (scan_status, get_report, reveal_credentials).

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 instructs when to use this tool ('Provide at least one of email / phone / name') and what to do next: 'Poll scan_status(scan_id) until it reports "done", then call get_report(scan_id).' It also states the concurrency limitation and points to reveal_credentials for leaked credentials, providing clear alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 7, 2026
- First observedget_report
- First observedlist_scans
- First observedreveal_credentials
- First observedscan_status
- First observedscan_target

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Disambiguation5/5

Each tool has a unique, clearly defined role: starting a scan, checking its status, listing past scans, retrieving reports, and revealing leaked credentials. No two tools overlap in purpose or output.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (scan_target, scan_status, list_scans, get_report, reveal_credentials), using lowercase with underscores throughout. The convention is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a privacy OSINT server. Each tool covers a necessary step in the scanning workflow without redundancy or bloat, making the set feel complete and manageable.

Completeness5/5

The tool set covers the full scan lifecycle: initiate, monitor, list history, retrieve general report, and access sensitive credentials. There are no obvious dead ends, and the guidance in descriptions ensures agents can navigate the workflow seamlessly.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

outris-identity-mcp
io.github.outris-dev-user
Identity resolution MCP server for phone/email lookups across 31+ services. Global + India coverage.
Customer Data Platforms Search Security
21
openfolio
io.github.dodenbach
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Government Data Open Data Search
1
AgenticSearch B
uk.co.cybersecai.agentsearch
Trust-scored search engine for MCP servers. 1,900+ sources indexed. IETF draft published. Referenced by OWASP MCP Security Cheat Sheet. L0-L4 trust levels based on cryptographic verification.
Legal & Compliance Security
2
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21

Related MCP Servers

mcp-osint-server
Search Web Scraping Shell Access
himanshusanecha
F
license
Not graded
quality
D
maintenance
MCP server to perform various OSINT tasks by leveraging common network reconnaissance tools.
Updated a year ago (2025-03-12 16:44 UTC)
48
-
OSINT MCP Server
Security Research & Data Code Execution
12345678969696969
-
license
Not graded
quality
Not graded
maintenance
Exposes popular OSINT and reconnaissance tools like Sherlock, SpiderFoot, and Holehe through MCP and HTTP APIs for AI assistants. Runs security research tools in sandboxed environments and returns normalized JSON results for investigation and analysis.
Updated a year ago (2025-08-26 06:28 UTC)
1
-
OSINT MCP Server
Security Search Research & Data
CloudWaddie
A
license
D
quality
D
maintenance
A comprehensive MCP server providing tools for IP, domain, email, and image-based open-source intelligence. It integrates services like Shodan, VirusTotal, and HaveIBeenPwned to facilitate advanced security research and data gathering.
Updated 6 months ago (2026-03-09 08:18 UTC)
56
48
ISC
OSINT Tools MCP Server
Open Data Research & Data Security
frishtik
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server that exposes multiple OSINT tools to AI assistants like Claude, enabling sophisticated reconnaissance and information gathering tasks using industry-standard OSINT tools.
Updated a year ago (2025-08-07 13:52 UTC)
237
MIT

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/sudohnim/eidolon'

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