Allows browsing HackerOne bug bounty programs, reading policies, fetching structured scope (domains, CIDRs, mobile packages, etc.), and checking whether a target asset matches an active program scope via the HackerOne Hacker API v1.
Allows browsing Intigriti bug bounty programs, reading policies, fetching structured scope, and checking target assets against program scope via the Intigriti Researcher External API v1.
Click on "Deploy 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., "@Bug Bounty Platform MCP Server check if api.example.com is in scope on HackerOne"
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.
A unified Model Context Protocol (MCP) server enabling AI coding assistants and autonomous agents (DeepSeek Harness, Claude Desktop / Claude Code, Cursor, Windsurf, Antigravity) to interact with major bug bounty platforms using personal researcher API keys and access tokens.
Supported platforms:
HackerOne (Hacker API v1)
YesWeHack (Researcher API)
Intigriti (Researcher External API v1)
Unified Multi-Platform Tools: Single point of interaction to browse programs, read policies, and fetch structured scopes across HackerOne, YesWeHack, and Intigriti.
Intelligent Scope Matcher: Check if an IP, CIDR block, domain, wildcard (*.example.com), or URL prefix belongs to an active program scope.
Graceful Fallback: Missing API keys for any platform will not crash the server. Only unconfigured platforms are disabled with helpful reminders.
Token-Efficient & Normalized: All vendor-specific schemas (JSON:API, OpenAPI, REST) are parsed and normalized into compact, standardized Pydantic models.
Live & Stateless: Direct API calls ensure real-time accuracy without stale local caches.
Related MCP server: h1-brain
[ AI Assistant / Agent (DeepSeek Harness, Claude, Cursor) ]
│ (JSON-RPC over stdio)
▼
┌─────────────────────────────┐
│ Bounty Platform MCP Server│
└──────────────┬──────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
[HackerOne Client] [YesWeHack Client] [Intigriti Client]
(Basic Auth) (Bearer Token) (Bearer Token)
│ │ │
▼ ▼ ▼
api.hackerone.com api.yeswehack.com api.intigriti.comClone the repository:
git clone https://github.com/toannguyen3107/bounty_platform_mcp.git
cd bounty_platform_mcpCreate a virtual environment and install dependencies using uv (recommended) or pip:
Using uv:
uv venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
uv pip install -e .Using pip:
python -m venv .venv
source .venv/bin/activate # On Windows: .venv\Scripts\activate
pip install -e .Copy .env.example to .env:
cp .env.example .envEdit .env with your API credentials:
# HackerOne API Credentials (Basic Auth)
# Generate from HackerOne: Settings -> API Tokens
H1_USERNAME=your_hackerone_username
H1_API_KEY=your_hackerone_api_token
# YesWeHack API Token (Bearer Auth)
# Generate from YesWeHack: Profile -> My YesWeHack Tools -> Personal Access Tokens
YWH_API_TOKEN=your_yeswehack_token
# Intigriti Researcher API Token (Bearer Auth)
# Generate from Intigriti: Settings -> API
INTIGRITI_API_TOKEN=your_intigriti_tokenNote: You only need to configure the platforms you use. Any platform without credentials will be gracefully skipped.
dsh)Add the MCP server to your DeepSeek Harness configuration (e.g. ~/.dsh/settings.yaml or harness plugin configuration):
mcpServers:
bounty:
command: "python"
args:
- "C:/Toan/Tools/bounty_platform_mcp/run_server.py"
env:
H1_USERNAME: "your_hackerone_username"
H1_API_KEY: "your_hackerone_api_token"
YWH_API_TOKEN: "your_yeswehack_token"
INTIGRITI_API_TOKEN: "your_intigriti_token"claude_desktop_config.json)On Windows: %APPDATA%\Claude\claude_desktop_config.json
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"bounty-platform": {
"command": "C:\\Toan\\Tools\\bounty_platform_mcp\\.venv\\Scripts\\python.exe",
"args": [
"C:\\Toan\\Tools\\bounty_platform_mcp\\run_server.py"
],
"env": {
"H1_USERNAME": "your_hackerone_username",
"H1_API_KEY": "your_hackerone_api_token",
"YWH_API_TOKEN": "your_yeswehack_token",
"INTIGRITI_API_TOKEN": "your_intigriti_token"
}
}
}
}.cursor/mcp.json){
"mcpServers": {
"bounty-platform": {
"command": "python",
"args": ["C:/Toan/Tools/bounty_platform_mcp/run_server.py"],
"env": {
"H1_USERNAME": "your_hackerone_username",
"H1_API_KEY": "your_hackerone_api_token",
"YWH_API_TOKEN": "your_yeswehack_token",
"INTIGRITI_API_TOKEN": "your_intigriti_token"
}
}
}
}Tool | Parameters | Description |
| (none) | Inspect which platforms are configured and see any missing environment variables. |
|
| Search bug bounty programs across one or all platforms ( |
|
| Fetch detailed program specifications, policies, testing restrictions, and maximum bounties. |
|
| Retrieve all structured in-scope and out-of-scope targets (domains, CIDRs, mobile packages, etc.). |
|
| Determine if an asset ( |
Run the comprehensive unit test suite:
pytest -vOutput:
tests/test_config_models.py ................. [ 10%]
tests/test_matcher.py ....................... [ 28%]
tests/test_http_client.py ................... [ 39%]
tests/test_hackerone.py ..................... [ 53%]
tests/test_yeswehack.py ..................... [ 67%]
tests/test_intigriti.py ..................... [ 82%]
tests/test_manager.py ....................... [ 92%]
tests/test_server.py ........................ [100%]
============================= 28 passed in 1.74s ==============================MIT License. See LICENSE for details.
Verify whether a target domain, IP, CIDR subnet, or URL is in-scope across bug bounty programs. Evaluates wildcards (*.target.com), IP ranges, and path prefixes.
Args: target: The target asset to check (e.g. 'api.example.com', '192.168.1.10', 'https://example.com/v1'). platform: Platform to inspect ('all', 'hackerone', 'yeswehack', or 'intigriti'). Defaults to 'all'.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| platform | No | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by mentioning that it evaluates wildcards, IP ranges, and path prefixes, which informs the agent of the tool's matching logic. However, it does not disclose potential limitations, such as how it handles invalid targets or whether it makes network calls.
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 concise and well-structured, with the purpose stated in the first sentence and evaluation criteria in the second. The Args section is formatted clearly with parameter names, explanations, and examples. No redundant information is present.
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 is reasonably complete for a simple check tool: it defines the inputs and the matching behavior. Since an output schema exists, the description does not need to explain return values. It could mention edge cases like multiple platforms or network requirements, but overall it covers the essential information an agent needs to invoke the tool correctly.
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 description coverage is 0%, so the description must compensate. It does so effectively by explaining the target parameter with examples and specifying allowed values for platform ('all', 'hackerone', 'yeswehack', 'intigriti'), which the schema does not provide. The description adds semantic meaning beyond the raw types.
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 verifies whether a target domain, IP, CIDR subnet, or URL is in-scope across bug bounty programs. It also mentions specific evaluation criteria (wildcards, IP ranges, path prefixes), which distinguishes it from sibling tools like bounty_get_scope that likely focus on a single program's scope.
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 when to use the tool (when you need to check a target against programs), but it does not explicitly contrast it with sibling tools such as bounty_get_scope or bounty_search_programs. There is no mention of when not to use this tool or what alternatives exist for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the credential and operational status of all supported platforms (HackerOne, YesWeHack, Intigriti). Returns which platforms are currently configured and which environment variables are missing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses that the tool checks credential/operational status and returns configured platforms and missing environment variables. This is sufficient for a read-only status operation, though it does not mention any network calls or 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 two short sentences with no fluff. It front-loads the core action and resource, then states the return value clearly.
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 zero-parameter status tool with an output schema, the description gives enough context about what is checked and what is returned. Nothing essential for calling the tool correctly is missing.
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 zero parameters and 100% schema description coverage, so the baseline is 4. There are no parameter semantics to add beyond what the empty schema already communicates.
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 states a specific verb ('Check') and a specific resource: the credential and operational status of all supported platforms, with the platforms named explicitly. This clearly differentiates it from sibling tools that fetch programs, scopes, or target checks.
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 intended use is clear: run it when you need to know which platforms are configured and which environment variables are missing. It does not explicitly discuss alternatives or exclusions, but the context is obvious enough given the zero-parameter status-check purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full details, guidelines, policy, and scope for a specific program.
Args: platform: Platform name ('hackerone', 'yeswehack', or 'intigriti'). identifier: Program handle (HackerOne), slug (YesWeHack), or ID (Intigriti).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | ||
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only conveys a read operation ('Retrieve'). It does not disclose behavior on invalid identifiers, platform unavailability, rate limits, or auth requirements. As a network-backed lookup tool, these gaps are significant.
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 purpose sentence is front-loaded and free of fluff, followed by compact arg documentation. The parameter notes earn their place given the 0% schema coverage, so the length is justified rather than padded.
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?
An output schema exists, so return values need not be described. The description covers purpose and both parameters adequately. The remaining gaps are failure behavior (missing program, invalid identifier) and differentiation from the sibling bounty_get_scope, which a complete definition for a moderate-complexity lookup tool should address.
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 0% and both params lack descriptions, so the description must compensate. It does so well: it enumerates the valid platform values ('hackerone', 'yeswehack', 'intigriti') and explains the identifier format per platform (handle, slug, ID). This adds real meaning beyond the bare schema.
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 states a specific verb (Retrieve) and a specific resource (full details, guidelines, policy, and scope for a program). However, it lists 'scope' among the retrieved items, which overlaps with the sibling tool bounty_get_scope and creates mild ambiguity about which tool to call for scope data.
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?
There is no guidance about when to use this tool versus the siblings (bounty_search_programs, bounty_get_scope, bounty_check_target). The arg documentation implies 'look up one program by its handle', but no explicit when/when-not or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all structured scope items (in-scope and out-of-scope) for a specific program.
Args: platform: Platform name ('hackerone', 'yeswehack', or 'intigriti'). identifier: Program identifier. include_oos: Whether to include explicitly declared out-of-scope assets. Defaults to True.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | ||
| identifier | Yes | ||
| include_oos | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself carries the behavioral burden. 'Retrieve' makes the read-only nature clear, and the include_oos parameter is explained as controlling whether explicitly declared out-of-scope assets are returned, which adds useful behavioral detail. It does not discuss permissions or rate limits, but for a simple read operation this is adequate.
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 opens with a one-sentence purpose statement and then lists the three parameters with clear, relevant semantics. There is no filler, and the most useful information is front-loaded.
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 low-complexity three-parameter tool with an output schema present, the description covers the operation, all parameters, and the main behavioral switch. It could slightly improve by explaining how to obtain or format the identifier, but the existing content is sufficient for correct invocation.
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 description coverage is 0%, so the description must compensate, and it does: platform is given an explicit list of valid values, identifier is identified as the program identifier, and include_oos has its semantics and default stated. The only weakness is that 'program identifier' remains somewhat vague (e.g., slug vs. ID).
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 uses a specific verb and resource: 'Retrieve all structured scope items (in-scope and out-of-scope) for a specific program.' This clearly differentiates it from sibling tools like bounty_get_program (program metadata) or bounty_search_programs (search) by naming scope items as the focus.
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 a known program's scope by requiring platform and identifier, but it never explicitly says when to choose this tool over siblings or when not to use it. There is no comparison to bounty_get_program or bounty_check_target, so the guidance is only implied by the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter bug bounty programs across HackerOne, YesWeHack, and Intigriti.
Args: query: Search keyword to filter program handle or name (e.g. 'google', 'uber', 'crypto'). platform: Platform to search ('all', 'hackerone', 'yeswehack', or 'intigriti'). Defaults to 'all'. bbp_only: If True, only returns programs offering monetary rewards (Bug Bounty Programs). public_only: If True, only returns publicly accessible programs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| bbp_only | No | ||
| platform | No | all | |
| public_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the read/search nature and platform/filter behavior, but does not state side effects, auth requirements, or error behavior. For a read-only search tool this is a moderate gap, but the absence of explicit non-destructive signaling keeps it from being higher.
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?
One-sentence summary plus a focused Args block; every line earns its place and the core verb is front-loaded.
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?
All four optional parameters are described, and the presence of an output schema covers return structure. It lacks only advanced details like pagination or invalid-platform handling, which are minor for a list-search 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 Args section fully explains each parameter: 'query' as keyword, 'platform' with allowed values, and meanings of the two booleans. With 0% schema coverage, this is exactly the compensation needed.
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?
Description opens with a clear verb and object: 'Search and filter bug bounty programs' and delimits scope across three named platforms. This sets it apart from sibling tools like bounty_get_program and bounty_get_scope, which imply single-program retrieval.
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 a discovery/listing use case but never explicitly says when to choose it over siblings like bounty_get_program or bounty_check_target. There is no when-to-use, when-not-to-use, or alternative routing, leaving the agent to infer from names.
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.
v0.1.0bounty_check_targetbounty_get_platforms_statusbounty_get_programbounty_get_scopebounty_search_programsScored across 5 tools
Each tool targets a distinct action (search, get details, get scope, check target, platform status), but there is minor overlap between bounty_get_program (which includes scope) and bounty_get_scope (structured scope only). The descriptions clarify the difference, so agents can reliably choose correctly.
All tool names share the 'bounty_' prefix and follow a consistent verb_noun pattern: search_programs, get_program, get_scope, check_target, get_platforms_status. This makes the API predictable and easy to navigate.
Five tools is well-scoped for this read-only bug bounty program intelligence server. Each tool has a clearly necessary role—searching, retrieving program details, fetching structured scope, verifying targets, and checking platform connectivity—no unnecessary bloat or missing critical operations.
The core workflows of discovering and assessing bug bounty programs are well covered: searching programs, reading full policies, inspecting scope, checking target eligibility, and monitoring platform status. Minor gaps include the lack of a dedicated 'list all programs' endpoint, though this can be achieved via an empty search query, and the server intentionally omits submission or hunting features, which appear outside its scope.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
CVE lookups (NVD) and dependency-manifest audits (OSV) for AI agents. No API keys.
Threat intel + your scans/findings/Shield posture. CVE, EPSS, KEV, package vuln lookup, DAST.
