Loading ToolBench
Exposes HackerOne's PUBLIC GraphQL API as Model Context Protocol tools so an AI agent can list newly launched bounty programs and their scopes, look up any program's scope by handle, search programs by name, list recently resolved reports with company + solver, list recently disclosed reports with the report's exact scope, and run arbitrary hacktivity searches and rank by bounty amount
Server exposes 7 read-only tools querying HackerOne's public GraphQL API. Tool naming follows verb_noun convention (list_, get_, search_) and is generally clear. All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with type definitions and parameter descriptions. However, output schemas are not formally documented, responses are inferred from code. Error handling is minimal (generic GraphQL errors, no recovery guidance). No tool annotations (readOnlyHint, etc.). Parameter descriptions lack format constraints and validation rules. Composition is sound (each tool has one responsibility), but descriptions could be more LLM-optimized per pattern:tool-description.
Look up any program's scope and details by handle
Get scopes for a program by handle
Run arbitrary hacktivity searches and rank by bounty amount
List newly launched bounty programs and their scopes
List recently disclosed reports with the report's exact scope
List recently resolved reports with company + solver, and optionally attach the program scope even when the individual report is undisclosed
Search programs by name
Output schemas not formally documented. Code shows responses are dicts with fields like 'count', 'programs', 'scopes', 'error', but no JSON Schema or structured type definitions are visible. LLMs cannot reliably extract fields or plan downstream calls without explicit output schemas.
Error handling lacks recovery guidance. GraphQL errors are caught and truncated to 600 chars, but responses do not tell the LLM what to do next (retry, ask user, or fail). Generic error messages like 'no program found with handle' do not suggest alternatives or next steps.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 7 tools are read-only, but this is not declared in the tool definitions. Clients cannot infer safety properties without explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Parameter descriptions lack format constraints and validation rules. E.g., 'limit' params have no min/max bounds stated in descriptions (code defaults to 15-25, but LLMs cannot see this). 'query_string' has no length or character restrictions documented.
Pagination not explicitly offered. Tools return fixed limits (15-25 items by default) but do not expose next_cursor or offset/page parameters. Large result sets could exhaust context; no guidance on how to fetch more.