Scans Docker configuration files for registry authentication tokens and other secrets.
Detects leaked GitHub OAuth tokens from CLI configuration and other locations.
Detects leaked Google API keys and credentials in scanned files.
Scans Kubernetes configuration files for cluster credentials and tokens.
Detects leaked npm authentication tokens from .npmrc files.
Detects leaked OpenAI API keys in environment files and shell history.
Detects leaked PyPI authentication tokens from .pypirc files.
Detects leaked SendGrid API keys and credentials in scanned files.
Detects leaked Slack tokens and credentials in files and shell history.
Detects leaked Stripe secret keys (live and test) in environment files and configuration.
Detects leaked Twilio API keys and credentials in scanned files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ghosthunt Scan my machine for leaked secrets"
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.
Find every leaked secret on your machine.
GhostHunt is an MCP server that scans your development machine for API keys, tokens, and credentials hiding in places you forgot to check: .env files scattered across projects, shell history, AWS/SSH/Docker configs, and more.
Everything runs locally. No data leaves your machine.
Environment files — recursively finds every .env, .env.local, .env.production, etc. under your home directory
AWS credentials — ~/.aws/credentials and session tokens
SSH keys — unprotected private keys in ~/.ssh/
Docker config — registry auth tokens in ~/.docker/config.json
npm/PyPI tokens — ~/.npmrc, ~/.pypirc auth tokens
GitHub CLI — OAuth tokens in ~/.config/gh/hosts.yml
Shell history — API keys pasted into bash, zsh, or fish commands
Kubernetes — ~/.kube/config credentials
Netrc — ~/.netrc passwords
35+ secret patterns — AWS, Stripe, GitHub, OpenAI, Anthropic, Google, Slack, Twilio, SendGrid, database connection strings, private keys, and more
Related MCP server: Ghost Security MCP Server
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"ghosthunt": {
"command": "npx",
"args": ["-y", "ghosthunt"]
}
}
}Restart Claude Desktop. Then ask Claude: "Scan my machine for leaked secrets"
npx ghosthuntscan_secretsFull detailed scan. Returns every finding with file paths, line numbers, severity ratings, and remediation steps.
Example prompt: "Run a full GhostHunt scan and show me everything"
scan_summaryQuick health check. Returns your health score (0-100) and a count by severity. Run this first to see if you have a problem.
Example prompt: "Give me a quick GhostHunt health check"
# GhostHunt Scan Report
**Health Score: 37/100** (Critical)
- Secrets found: **12**
- Critical: 3 | High: 5 | Medium: 2 | Low: 2
- Locations scanned: 47
- Scan time: 142ms
## Environment Files (.env)
- **[CRITICAL]** Stripe Live Secret Key
- File: `/Users/you/project-a/.env:4`
- Context: `STRIPE_SECRET_KEY`
- Value: `sk_l****_8xQ`
- **[CRITICAL]** OpenAI API Key
- File: `/Users/you/side-project/.env.local:12`
- Context: `OPENAI_API_KEY`
- Value: `sk-p****kFJ9`
## Shell History
- **[HIGH]** Bearer Token in Header
- File: `/Users/you/.zsh_history:8847`
- Context: `curl -H "Authorization: Bearer sk_live_...`
- Value: `sk_l****_m3K`
## Recommendations
1. **Rotate critical secrets immediately.** Any API key marked CRITICAL
should be revoked and regenerated from the provider's dashboard.
2. **Clear your shell history** of sensitive commands.
3. **Audit your .env files.** Ensure they are in .gitignore.Your score starts at 100 and drops based on what GhostHunt finds:
Finding | Penalty |
Critical secret | -15 |
High severity | -8 |
Medium severity | -3 |
Low severity | -1 |
A score below 50 means you have secrets that need immediate attention.
GhostHunt runs entirely on your local machine. It does not:
Send any data to any server
Phone home or track usage
Store scan results anywhere
Access the internet
Your secrets stay on your machine. The scan results stay in your Claude conversation.
MIT
Fix leaked secrets found on your machine. Auto-cleans shell history (backs up first), adds .env to .gitignore where missing, and provides step-by-step rotation instructions with direct links for secrets that need manual rotation. Returns structured JSON (in a second content block) with before/after health scores for visual rendering. If you have visualization capabilities, render the JSON as a fix report dashboard with before/after health score comparison and auto-fixed item list. Run scan_secrets first to see what will be fixed.
| Name | Required | Description | Default |
|---|---|---|---|
| auto_fix | No | Automatically fix what's possible (shell history cleanup, gitignore). Default: true. | |
| include_low_severity | No | Include low-severity findings in the fix. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: backs up shell history, adds gitignore, returns structured JSON with health scores, and mentions visualization. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding value. Front-loaded with main purpose. Slightly verbose but well-structured. Could be trimmed slightly without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive: explains return format (structured JSON with health scores), workflow (run scan_secrets first), edge cases (backup before cleanup, manual rotation instructions). No output schema, but description compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both params described). The description adds context: auto_fix covers shell history cleanup and gitignore; include_low_severity filters findings. This adds meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fixes leaked secrets with specific actions (auto-cleans shell history, adds .env to .gitignore, provides rotation instructions). It distinguishes from siblings like scan_secrets (scanning) and scan_summary (summarizing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to run scan_secrets first to see what will be fixed, providing clear workflow guidance. Also explains tool scope: auto-fixes and manual rotation instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show GhostHunt version and license status. Displays whether you're on the Free or Pro tier and what Pro includes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation with no side effects, but could elaborate on authorization or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the output (version, license tier, Pro inclusions) for a tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%, so the description adds no further semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows version and license status, distinguishing it from sibling tools that scan or fix secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for checking status, but provides no explicit guidance on when to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan your entire machine for leaked API keys, tokens, and credentials. Checks .env files, AWS/SSH/Docker/npm configs, shell history, and more. Returns a detailed report with risk explanations, rotation URLs, and fix guidance. Also returns structured JSON data (in a second content block) for visual rendering. If you have visualization capabilities, render the JSON as a visual dashboard with a health score gauge, color-coded finding cards, and auto-fix indicators. Everything runs locally -- no data leaves your machine.
| Name | Required | Description | Default |
|---|---|---|---|
| include_low_severity | No | Include low-severity findings (test keys, etc). Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states local execution and no data leaving the machine, and implies non-destructive reading. However, it does not mention performance impact or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and scope. It is moderately concise but includes some extraneous visual rendering instructions. Every sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple schema (1 optional param), no output schema, and no annotations, the description adequately covers purpose, return content, and privacy. Missing details on limitations or edge cases, but sufficient for a scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (include_low_severity) is fully described in the schema (100% coverage). The description adds no further detail beyond mentioning low-severity findings in the report context, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (scan) and resource (entire machine for secrets). It distinguishes from siblings like fix_secrets (fixing) and scan_summary (summarizing) by detailing the scanning scope and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for initial secret detection but lacks explicit guidance on when to use vs alternatives, such as preferring scan_summary for aggregated results or fix_secrets for remediation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick health check -- counts how many secrets are on your machine and gives you a health score (0-100). Faster than a full scan. Run scan_secrets for details, or fix_secrets to clean up.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses it's a quick count and health score, faster than full scan. Lacks explicit read-only or non-destructive assurance, but is fairly transparent for a simple health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, the description fully covers purpose, usage context, and sibling differentiation. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100% empty). Description adds no param info, but none needed. Baseline 4 for zero-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool counts secrets and gives a health score (0-100), with a verb+resource combo. Distinguishes from siblings scan_secrets and fix_secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it's a quick health check, and directs to scan_secrets for details and fix_secrets to clean up, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.0fix_secretsghosthunt_statusscan_secretsscan_summaryEach tool has a distinct purpose: scanning for secrets, fixing them, quick summary, and status. No overlap or ambiguity.
Most tools use a consistent verb_noun pattern (scan_secrets, fix_secrets, scan_summary), but ghosthunt_status deviates slightly from the 'scan' prefix, though it is still descriptive.
Four tools is well-scoped for a focused security scanning server, covering essential workflows without bloat.
Core scan, fix, and health check are covered. Missing perhaps an exclusion or configuration tool, but the essential lifecycle is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/78degrees/ghosthunt'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
