Loading ToolBench
MCP server for HackerOne API integration to sync bug bounty reports, programs, and vulnerability data into local SQLite databases
h1-brain is a STDIO-only MCP server with 18 tools accessing HackerOne vulnerability data. While tool naming is generally verb-first and descriptions are present, there are substantial gaps: many tool parameters lack type definitions in visible schemas, input validation descriptions are minimal, output schemas are not documented, error handling guidance is absent, and several tools expose implementation details rather than user-focused abstractions. The codebase shows SQLite database access and HackerOne API integration, but the tool definitions lack the rigor expected for production agent interaction. Most tools fall in the 30 - 50 range; the average across all 18 tools is 38.
Fetch all disclosed vulnerability reports from HackerOne and sync to the disclosed database.
Fetch all eligible HackerOne programs from the API and sync to local database.
Sync your personal bounty-awarded reports from HackerOne API into the local database. Run once, re-run to update.
Fetch all scopes for all programs and sync to the database.
Retrieve a specific disclosed report by its ID from the disclosed database.
List all scopes for a specific program handle.
List all attachments for a specific report.
Output schemas not documented. LLMs cannot plan downstream calls or extract required fields (e.g., what fields are returned by get_report_by_id? Does it include program_handle for chaining to list_reports_by_program?). This forces agents to guess or make discovery calls.
Parameter type definitions missing or incomplete. search_reports_by_title accepts a 'query' param with type 'string' but no minimum/maximum length, pattern, or format constraints. list_programs accepts 'offers_bounties' (boolean, optional) but no description of how it filters or what null means. Input validation cannot be inferred from schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Retrieve a specific report by its ID from the local rewarded reports database.
List reports filtered by severity rating from the rewarded reports database.
List reports filtered by weakness name from the rewarded reports database.
List all programs in the local database with their details.
List all rewarded reports for a specific program handle.
Full-text search in disclosed vulnerability reports database.
Full-text search in report titles and vulnerability information from your local rewarded reports.
Get per-program statistics from the rewarded reports database.
Get per-weakness-type statistics from the rewarded reports database.
Get summary statistics from the disclosed vulnerability reports database.
Get summary statistics from the local rewarded reports database (total reports, bounties, programs, etc).
No error recovery guidance. If fetch_rewarded_reports fails (auth error, network timeout, API limit), the response likely includes a raw HTTP error code or stack trace. No actionable recovery message (e.g., 'Check H1_USERNAME and H1_API_TOKEN env vars' or 'Rate limited, retry in 60s'). Agents cannot self-correct.
No pagination support declared. list_programs, list_reports_by_program, and list_by_* tools may return large result sets, but there are no limit, offset, or cursor parameters visible in the schemas. Results could exceed token budget without agent control.
WRITE tools (fetch_*) lack dry-run, confirmation, or idempotency guarantees. fetch_rewarded_reports syncs rewarded reports into local DB, is it idempotent? Can it be safely retried? No documentation. Agents need to know which calls are safe to retry and which have irreversible side effects.
Tool composition chains unclear. get_report_by_id returns a report, but does it include the program_handle field needed to later call list_reports_by_program? Or does the agent need a separate lookup? Response field naming and chaining IDs are not documented.
Multiple similar tools without clear distinction. Both search_reports_by_title and search_disclosed_reports exist, when should each be used? The descriptions say 'Full-text search' but do not explain the difference (rewarded vs disclosed, different databases). LLMs may conflate them.
No permission gates or scope declarations. These tools access HackerOne data via API credentials (H1_USERNAME, H1_API_TOKEN). No visibility into what permissions are required (e.g., read:reports, write:database). No audit trail mention. For a security-sensitive domain, this is risky.