Integrates with Baidu search engine to harvest emails and subdomains associated with target domains.
Integrates with Brave search engine for domain reconnaissance, including email and subdomain discovery.
Integrates with DuckDuckGo search engine to discover emails and subdomains related to target domains.
Integrates with GitHub code search to find emails and subdomains in public repositories.
Integrates with SecurityScorecard to gather security-related intelligence and subdomain data.
Integrates with VirusTotal to query domain information and discover associated subdomains and emails.
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., "@theHarvester MCP Server Recon domain example.com for emails and subdomains"
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.
An MCP (Model Context Protocol) server that provides AI assistants with access to theHarvester - a powerful OSINT reconnaissance tool for email and subdomain harvesting during penetration testing.
theHarvester is one of the most widely used OSINT tools for gathering intelligence during the reconnaissance phase of penetration testing. This MCP server wraps theHarvester's capabilities, allowing AI assistants like Claude to perform domain reconnaissance tasks through a structured interface.
The server executes theHarvester commands via SSH on a Kali Linux host, making it ideal for security professionals who maintain a dedicated Kali environment.
Related MCP server: MCP OSINT Server
Email Harvesting - Discover email addresses associated with target domains
Subdomain Discovery - Find subdomains using 40+ public and premium data sources
DNS Brute Force - Enumerate subdomains using wordlist-based brute forcing
Shodan Integration - Query discovered hosts for open ports, services, and banners
Takeover Detection - Check for subdomain takeover vulnerabilities
Virtual Host Discovery - Identify virtual hosts on discovered IP addresses
Kali Linux Host - A Kali Linux system accessible via SSH
SSH Configuration - SSH access configured in ~/.ssh/config
theHarvester - Installed on the Kali host:
sudo apt install theharvesterNode.js - Version 18 or higher
# Clone the repository
git clone https://github.com/schwarztim/sec-theharvester-mcp.git
cd sec-theharvester-mcp
# Install dependencies
npm install
# Build the project
npm run buildAdd to your Claude Desktop or MCP client configuration:
{
"mcpServers": {
"theharvester": {
"command": "node",
"args": ["/path/to/sec-theharvester-mcp/dist/index.js"],
"env": {
"KALI_HOST": "kali"
}
}
}
}Tool | Description |
| Full OSINT search with configurable sources and options |
| List available data sources and API requirements |
| Quick search focused on email harvesting |
| Quick search for subdomain/host discovery |
| DNS brute force enumeration |
| Search with Shodan integration for detailed host info |
| Comprehensive reconnaissance using all features |
| Verify theHarvester availability on Kali host |
anubis, baidu, bing, crtsh, dnsdumpster, duckduckgo
hackertarget, otx, rapiddns, sitedossier, subdomaincenter
threatminer, urlscan, yahoo
bevigil, binaryedge, brave, bufferoverun, censys
criminalip, fullhunt, github-code, hunter, hunterhow
intelx, leakix, netlas, onyphe, pentesttools
projectdiscovery, rocketreach, securityscorecard
securitytrails, shodan, tomba, virustotal, zoomeye
Configure API keys in theHarvester's configuration file on your Kali host.
Variable | Default | Description |
|
| SSH hostname for Kali Linux system |
Ensure your SSH config (~/.ssh/config) includes an entry for your Kali host:
Host kali
HostName 192.168.1.100
User root
IdentityFile ~/.ssh/kali_key{
"tool": "theharvester_search",
"arguments": {
"domain": "example.com",
"sources": ["bing", "crtsh", "dnsdumpster"],
"limit": 500
}
}{
"tool": "theharvester_emails",
"arguments": {
"domain": "example.com",
"sources": ["hunter", "tomba", "bing"]
}
}{
"tool": "theharvester_hosts",
"arguments": {
"domain": "example.com",
"dns_resolve": true,
"dns_brute": true
}
}{
"tool": "theharvester_full_recon",
"arguments": {
"domain": "example.com"
}
}All tools return structured JSON with:
Parsed results (emails, hosts, IPs, URLs, ASNs)
Statistics and metadata
Raw output for detailed analysis
Example response:
{
"domain": "example.com",
"sources": ["bing", "crtsh"],
"emails": ["admin@example.com", "support@example.com"],
"hosts": ["www.example.com", "mail.example.com"],
"ips": ["93.184.216.34"],
"urls": [],
"asns": [],
"interesting_urls": [],
"raw_output": "..."
}This tool is intended for authorized security testing only
Always obtain proper authorization before scanning any domain
Be mindful of rate limits on data source APIs
Some sources may log your queries
# Watch mode for development
npm run dev
# Build for production
npm run build
# Run the server
npm starttheHarvester - The underlying OSINT tool
Model Context Protocol - MCP specification
MIT License - see LICENSE for details.
This tool is provided for educational and authorized security testing purposes only. Users are responsible for ensuring they have proper authorization before scanning any systems or domains. The authors are not responsible for any misuse of this software.
Check if theHarvester is available and working on the Kali host.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description says 'available and working' but doesn't define what that means (e.g., binary exists, service responds). No side effects disclosed, but likely read-only. Adequate for a simple 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?
Single clear sentence with no fluff. Front-loaded with verb and resource.
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 zero parameters and no output schema, the description adequately explains the tool's purpose. Could mention expected return values (e.g., true/false) for completeness, but not critical.
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, so baseline 4 applies. Schema coverage is 100% and the description adds no parameter detail beyond the schema, which is fine.
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 checks availability and working status of theHarvester on the Kali host. Distinguishes from sibling tools like theharvester_search which perform queries.
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?
No explicit guidance on when to use this tool vs alternatives. It implies a prerequisite check but lacks 'use before other tools' or 'if theHarvester is misbehaving' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform DNS brute force enumeration to discover subdomains using a wordlist.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Target domain for DNS brute force | |
| dns_server | No | Custom DNS server to use for lookups |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the action and method (DNS brute force with wordlist) but omits important behavioral details such as potential network impact, duration, rate limits, or required permissions. This lack of transparency could mislead an agent about the tool's implications.
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 a single, concise sentence that front-loads the action and purpose. Every word contributes value; there is no redundancy or fluff.
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?
For a tool with two parameters and no output schema, the description is minimally adequate. It states the purpose but does not clarify the output format, default wordlist behavior, or potential side effects. Given the simplicity, it could be more complete but is not severely lacking.
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 input schema descriptions cover both parameters (domain and dns_server) fully, achieving high schema coverage. The tool description adds the context of using a wordlist, but no additional semantic value beyond what the schema provides. Baseline 3 is appropriate.
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 (Perform), resource (DNS brute force enumeration), and purpose (discover subdomains using a wordlist). It distinguishes itself from sibling tools by specifying DNS brute force for subdomain discovery, unlike others focused on search, emails, or full recon.
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 discovering subdomains but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention conditions or prerequisites. Usage is implied but not clearly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick search focused on harvesting email addresses from a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results per source (default: 200) | |
| domain | Yes | Target domain to search for emails | |
| sources | No | Specific sources to use (default: hunter, tomba, rocketreach, bing, yahoo, duckduckgo) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It only states 'quick search' without disclosing behavioral traits like read-only nature, rate limits, authentication needs, or whether results are paginated. Minimal transparency.
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 a single sentence with 9 words, highly concise. It provides the core purpose without waste. However, it sacrifices useful detail for brevity.
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 the absence of output schema and annotations, the description is insufficient. It does not explain return values, possible limitations, or when to choose this over sibling tools, making it incomplete for effective use.
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% with all parameters described. The description adds no extra meaning beyond reiterating the domain context. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 harvests email addresses from a domain, which is specific and action-oriented. However, it does not explicitly differentiate from sibling tools like theharvester_search, though the name implies specialization.
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?
No guidance on when to use this tool versus alternatives (e.g., theharvester_search, theharvester_full_recon). The description says 'Quick search' but lacks context on appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comprehensive reconnaissance using all available sources and features. Takes longer but provides the most complete results.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Target domain for full reconnaissance | |
| output_file | No | Base filename to save results (will create .json and .xml files) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions it takes longer and provides complete results, but lacks details on safety (e.g., read-only nature), authentication needs, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loading the core purpose and adding a key trade-off about time versus completeness. Every sentence is valuable.
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 the tool's complexity and the presence of sibling tools, the description is adequate but does not explain return values (no output schema) or how it differs from each sibling. It leaves some ambiguity.
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% and both parameters have clear descriptions. The description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
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 performs comprehensive reconnaissance using all sources and features, distinguishing it from siblings like theharvester_search which are likely more targeted.
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 complete results when time allows ('takes longer'), but does not explicitly state when not to use it or mention alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quick search focused on discovering subdomains and hosts for a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Target domain to search for subdomains | |
| sources | No | Specific sources to use (default: crtsh, dnsdumpster, hackertarget, rapiddns, threatminer) | |
| dns_brute | No | Also perform DNS brute force enumeration | |
| dns_resolve | No | Resolve discovered subdomains to verify they're active (default: true) |
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. It only says 'Quick search' without detailing operations (e.g., DNS queries, API calls), whether it is read-only, or required permissions. The parameters imply DNS brute force and resolution, but these behaviors are not described. This lack of transparency is a significant gap given no annotations.
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 a single, concise sentence that immediately communicates the tool's purpose. It is well front-loaded and contains no unnecessary words.
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 tool has 4 parameters, no output schema, and many sibling tools requiring clearer differentiation. The description is too brief to cover what the tool does in detail, what the output looks like, or how to use the parameters effectively. Given the complexity, it falls short of being complete.
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 input schema has 100% description coverage for all 4 parameters, so the schema itself adequately documents them. The description adds no additional context beyond stating the tool's focus on subdomains/hosts. With high schema coverage, a baseline score of 3 is appropriate.
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's purpose: 'Quick search focused on discovering subdomains and hosts for a domain.' It uses a specific verb ('search') and resource ('subdomains and hosts'), and the focus on 'quick' distinguishes it from more comprehensive sibling tools like theharvester_full_recon and theharvester_dns_brute.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for quick subdomain/host discovery, but does not mention when not to use it or suggest other tools for other tasks. Sibling tools like theharvester_search and theharvester_dns_brute overlap, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run theHarvester to gather OSINT on a domain. Collects emails, subdomains, hosts, IPs, and URLs from various public sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 500) | |
| domain | Yes | Target domain to search (e.g., 'example.com') | |
| shodan | No | Query Shodan for discovered hosts | |
| sources | No | Data sources to use. Available: anubis, baidu, bevigil, binaryedge, bing, bingapi, brave, bufferoverun, censys, certspotter, criminalip, crtsh, dnsdumpster, duckduckgo, fullhunt, github-code, hackertarget, hunter, hunterhow, intelx, leakix, netlas, onyphe, otx, pentesttools, projectdiscovery, rapiddns, rocketreach, securityscorecard, securitytrails, shodan, sitedossier, subdomaincenter, subdomainfinderc99, threatminer, tomba, urlscan, virustotal, yahoo, zoomeye. Leave empty for 'all'. | |
| takeover | No | Check for subdomain takeover vulnerabilities | |
| dns_brute | No | Perform DNS brute force enumeration | |
| dns_resolve | No | Perform DNS resolution on discovered subdomains |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not disclose whether the tool is read-only, has side effects, requires special permissions, or has rate limits. Minimal transparency beyond the basic action.
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 a single sentence, which is concise but lacks structure. It front-loads the main action, but could benefit from being broken into multiple sentences or providing more details without becoming 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?
For a tool with 7 parameters and no output schema, the description is too brief. It does not explain return format, error handling, or what happens after execution. Missing context needed for effective use.
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% (all parameters have descriptions). The description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not improve understanding.
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 runs theHarvester for OSINT on a domain and lists collected data types (emails, subdomains, etc.). However, it does not differentiate this general search from sibling tools like theharvester_emails or theharvester_hosts, which may have more specific purposes.
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?
No guidance is provided on when to use this tool versus its siblings. The description only states what it does, not when it is appropriate or what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run theHarvester with Shodan integration to get detailed host information including open ports and banners.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Target domain | |
| sources | No | Additional sources to combine with Shodan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions output content (open ports, banners) but does not describe authorization needs, rate limits, or any side effects. The tool is likely read-only, but this is not explicitly stated.
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 a single sentence of 17 words that front-loads the verb and key information. Every word is necessary; there is no redundancy or clutter.
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?
For a tool with no output schema, the description provides minimal output details (open ports, banners). It does not explain the format or other return values, but it is adequate for a simple reconnaissance tool. The presence of many sibling tools suggests a need for more distinction, which is partially met by the Shodan mention.
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%, so the schema already documents both parameters. The description adds no additional meaning about the parameters beyond the schema fields, achieving the baseline score.
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 runs theHarvester with Shodan integration to obtain detailed host information including open ports and banners. This distinguishes it from sibling tools like theharvester_hosts or theharvester_emails, though it does not explicitly contrast them.
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?
No guidance is provided on when to use this tool versus alternatives such as theharvester_search or theharvester_full_recon. The description only implies usage when Shodan-specific data is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available data sources for theHarvester, with information about API key requirements.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully clarifies the tool's behavior: it is a read-only listing that provides API key requirements. It does not describe any side effects or authentication details, but for a listing tool this is sufficient.
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 a single, concise sentence that delivers all necessary information without any fluff.
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 the tool's simplicity (no parameters, no output schema), the description is complete and provides the agent with all required context to use the tool effectively.
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, so the description does not need to add parameter information. A baseline score of 4 is appropriate as there is no need for compensation.
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 that the tool lists all available data sources for theHarvester and includes information about API key requirements. It distinguishes itself from sibling tools that perform searches or other operations, as it is a listing tool.
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 does not explicitly state when to use this tool versus alternatives, but it implies it is used to obtain a list of data sources before using other tools like theharvester_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct OSINT task (general search, source listing, DNS brute, email search, host search, Shodan integration, full recon, status check) with clear descriptions, making them easily distinguishable.
All tools share the 'theharvester_' prefix and use snake_case, but the suffixes vary between nouns (e.g., emails, hosts) and verbs (e.g., search, check_status), causing slight inconsistency.
With 8 tools, the set is well-scoped for theHarvester's OSINT functionality, covering both broad and focused operations without unnecessary redundancy.
The tool surface covers the major features of theHarvester: general search, source enumeration, DNS brute force, email/host harvesting, Shodan integration, and a comprehensive full recon, with no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
Utility tools for AI agents: hashing, text stats, validation, DNS, currency, GEO audits.
Hyperion — MCP tool marketplace for AI agents: web, OSINT, security, research via one key.
The web capability layer for AI agents: render, extract, DNS, SSL, WHOIS & more via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-theharvester-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
