HackerOne MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct resource and action. Report intents, attachments, programs, financial data, and reports are clearly separated. Even similar financial tools (balance, earnings, payouts) have clear distinctions.
Naming Consistency5/5
All tools follow the h1_verb_noun pattern with consistent snake_case. The singular/plural usage for attachments is standard (delete one vs list many). The prefix h1_ is applied uniformly.
Tool Count3/5
21 tools is on the higher end for an MCP server, but each tool corresponds to a specific HackerOne API endpoint. While not over-bloated, the count is borderline heavy compared to typical 3-15 tool servers.
Completeness4/5
The server covers report intents fully (CRUD + submit + attachments), program reads, financial reads, and report creation/listing. However, there is no update or delete operation for submitted reports, which may be a gap for some workflows.
Average 2.8/5 across 21 of 21 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention side effects, irreversibility, authentication needs, or what happens upon submission. The phrase 'submit' implies a final action, but no consequences are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It lacks enough substance to be useful, similar to the 'Process' example in the calibration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations or output schema, the description should still explain the workflow context (e.g., that this submits a previously created report intent) and any consequences. The description is far too sparse to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a clear description for intent_id ('Report intent ID'). The description adds no additional parameter semantics, but the baseline of 3 is appropriate because the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Submit a ready report intent' provides a verb and a vague object, but it does not specify what 'submit' entails or how it differs from sibling tools like create_report_intent or update_report_intent. It is essentially a restatement of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., creating the intent first), the finalization aspect, or that it should be used only after the intent is fully prepared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only says 'List' and gives no information about pagination, filtering, output format, or side effects. The schema reveals pagination and filter parameters, but the description omits any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. For a tool with six parameters and no annotations, a single vague sentence does not earn its place; it is insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no output schema, and no annotations, making it moderately complex. The description provides virtually no context about return values, pagination behavior, or how filters interact. It is far from complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only program_handle has a description). The description does not explain any parameters or add meaning beyond the schema. With such low coverage, the description must compensate but fails to do so, leaving page_size, page_number, created_after, updated_after, and id_greater_than unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List structured scopes' identifies a verb (list) and a resource (scopes), but 'structured scopes' is vague and does not specify that they are program scopes or what 'structured' implies. It does not distinguish from sibling tools like h1_get_scope_exclusions, which likely relate to program scope as well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 h1_get_scope_exclusions or h1_get_program. The description does not mention required program_handle context or any exclusions, leaving the agent without information on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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. 'List earnings.' only restates the tool's action and gives no information about pagination behavior, response format, error cases, or whether this is a safe read-only operation. This is even more minimal than typical low-scoring examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'List earnings.' is extremely brief, but this is under-specification rather than effective conciseness. The description omits essential context and does not organize any usable information, so the brevity does not serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a paginated list tool with no output schema, but the description does not explain what earnings are being listed, how pagination works, or what the response contains. The schema hints at page_size and page_number, but the overall tool behavior remains unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention page_size or page_number. While the parameter names are somewhat self-explanatory, the task requires the description to compensate for low schema coverage, and it completely fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a clear verb and resource: 'List earnings.' This is minimally clear, but it lacks specificity about whose earnings or what scope. It does not distinguish itself from sibling tools like h1_get_payouts or h1_get_balance, which may also involve monetary amounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context for when 'list earnings' is the appropriate choice. The agent is left without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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, but it only states the action. It does not mention pagination, authentication needs, rate limits, result ordering, or whether the list is complete or filtered, which are critical for correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words, earning a high score for conciseness. However, its extreme brevity sacrifices necessary detail, so it is not outstanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the pagination parameters and the absence of an output schema and annotations, the description is incomplete. It does not explain what 'available programs' means (e.g., accessible to the user, active programs), how pagination works, or what the response contains, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the page_size and page_number parameters. The input schema only gives names and constraints, but the description adds no semantic context, leaving the agent to infer the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' targeting 'programs', which indicates the core operation. It is distinguishable from sibling tools like h1_get_program that target a single program, though it does not explicitly make that contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states 'List available programs' with no mention of use cases, prerequisites, or limitations, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. 'Get program details' implies a read-only operation but does not disclose response format, required authentication, error behavior, or any other operational traits beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, but it is under-specified. It is not redundant or verbose, yet it lacks the detail needed to be genuinely useful, so it does not fully earn its place as the sole source of guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description does not specify what fields constitute 'program details', what the return structure looks like, or how this differs from related getter tools. This is insufficient for an agent to invoke the tool with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, program_handle, with 100% description coverage. However, the description 'Program handle' is tautological, and the tool description adds no additional meaning about handle format, source, or relationship to other parameters. The baseline of 3 applies because schema coverage is high, but no extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get program details' uses a specific verb and resource, indicating it retrieves a single program. However, 'details' is vague and does not distinguish it from sibling tools like h1_get_program_weaknesses or h1_get_program_scopes, which also fetch program-related information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 h1_list_programs or h1_get_program_scopes. The only implied usage is when program details are needed, but there are no explicit context cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention required permissions, side effects, or whether this is a final submission versus a draft. The mutation nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded, but it borders on under-specification. It earns its place only as a minimal purpose statement, lacking any additional structure or detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and no output schema, the description is far too thin to provide complete context. It conveys only the basic action and leaves the agent to infer usage, requirements, and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero parameter-level information. The input schema provides descriptions for only 4 of 7 parameters (57% coverage), leaving weakness_id, severity_rating, and structured_scope_id unexplained. The tool description does not compensate for these gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit') and the resource ('a vulnerability report'), making the core purpose unambiguous. However, it does not differentiate from sibling tools like h1_submit_report_intent or h1_create_report_intent, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention scenarios, prerequisites, or when to prefer other report-related tools, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It merely states 'AI-assisted report intent' without explaining side effects, required permissions, reversibility, response format, or any AI-specific processing. It fails to disclose any behavioral traits beyond the act of creation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, which is structurally clean. However, it is overly brief and under-specified. While it is concise, it lacks the detail needed to be considered appropriately sized. It could include a brief note on the purpose of AI assistance without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so complexity is low, but the description does not sufficiently explain the tool's role or completion criteria. It does not describe what happens after creation, how it relates to sibling tools, or what the agent should expect. The context is incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters (description and team_handle) have descriptions. The description adds no additional parameter meaning, so the baseline of 3 applies. It doesn't clarify how 'AI-assisted' affects parameter usage or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Create' on the resource 'report intent', which clearly identifies the tool's function. The qualifier 'AI-assisted' adds some distinction, but it doesn't fully differentiate from sibling tools like h1_submit_report_intent or h1_create_report. The core purpose is clear, but the description lacks explicit clarification on how this tool differs from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. It does not mention any context, prerequisites, or exclusions. For example, it doesn't explain whether it should be used before h1_submit_report_intent or how it relates to h1_create_report. This leaves the agent with no situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but 'List payouts' only implies a read operation. It does not mention pagination behavior, response format, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded, with no wasted words. However, it is under-specified for a tool with pagination parameters and no annotations, making it less than fully appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should compensate by explaining pagination and intended use. It only says 'List payouts,' which is insufficient for a complete understanding of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. The parameter names 'page_size' and 'page_number' are self-explanatory, but the description adds no value beyond the schema's basic constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List payouts'), making the core purpose clear. It is distinct from sibling tools by resource name, though it does not explicitly differentiate 'payouts' from related financial tools like h1_get_balance or h1_get_earnings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or context. The description only states the action without saying when it is appropriate or how it relates to sibling financial tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'Get a report with its relationships' without explaining what relationships are returned, whether the operation is read-only, or any other behavior. This is inadequate for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence and is front-loaded with the verb and resource. It does not contain wasted words, though 'with its relationships' is vague but still compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too minimal. The term 'relationships' is ambiguous and could be critical for the agent to understand what will be returned. A simple get tool still needs to clarify its scope to be effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'report_id' as 'Report ID' (100% coverage). The description adds no additional meaning beyond the schema. For a single required parameter with full schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and the resource 'report', which is clear at a high level. However, 'with its relationships' is vague and does not specify what relationships are included (e.g., attachments, signals, weaknesses), nor does it distinguish this from siblings like h1_get_report_intent or h1_list_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as h1_list_reports for many reports or h1_get_report_intent for report intents. The description provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies a read operation ('List') but does not state permissions, response format, or side effects. It adds no context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence. It is front-loaded with the verb and key noun. No wasted words, though the brevity sacrifices clarity. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description is minimal and ambiguous. It does not explain the return format, the meaning of 'report categories,' or how this relates to program scopes. Given no annotations or output schema, more detail is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter, program_handle, has a description). The description does not add meaning beyond the schema, but the schema already documents the parameter adequately, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a resource ('excluded report categories'), but the resource is vague. The tool name mentions 'scope_exclusions' while the description says 'report categories,' introducing ambiguity. It does not clearly differentiate from sibling tools like h1_get_program_scopes or h1_get_program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided. The one-sentence description gives no usage direction beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It only states the action 'List accepted weaknesses' without disclosing pagination behavior, required program_handle, or the shape of the response. The read-only nature is implied by 'List' but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, its brevity comes at the cost of omitting crucial context, so it's efficient but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and minimal description, leaving the agent without information about response format, pagination limits, or any filtering logic. Given the simple parameter set, a better description could easily provide this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33% (only program_handle has a trivial 'Program handle' description). The tool description does not explain page_size or page_number semantics, nor does it clarify that program_handle is the identifier for the program whose weaknesses are listed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'accepted weaknesses', which clearly distinguishes it from sibling tools like h1_get_program_scopes. However, it doesn't explicitly state that the list is scoped to a program, relying on the program_handle parameter for that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of prerequisites, related tools, or situations where h1_get_program_scopes or h1_get_program would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for behavioral disclosure. It only states 'List report intents,' with no mention of read-only status, pagination behavior, ordering, or potential side effects. The schema implies pagination via page_size and page_number, but the description does not confirm this or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the core verb and resource, making it easily scannable. Although minimal, it is efficiently structured with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with pagination parameters and several sibling tools, the description is incomplete. It does not explain what a report intent is, how the listing is ordered, whether results are paginated, or what the response format includes (especially since no output schema exists). The agent has insufficient context to invoke the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the parameters page_size or page_number at all. Since the schema is minimal and the description adds no meaning, the agent is left without any explanation of how these pagination parameters affect the listing. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List report intents' clearly states the action (list) and the resource (report intents), distinguishing it from siblings like h1_get_report_intent (singular get) and h1_create_report_intent. It is specific and unambiguous, though it lacks any additional context about the scope or content of the listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools such as h1_list_reports, h1_get_report_intent, and h1_list_report_intent_attachments, the description does not clarify the intended use case or selection criteria, offering zero directional support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates a read-only action via the verb 'List', but provides no details about pagination, response format, whether attachment metadata or content is returned, or any authentication requirements. The description is too sparse to inform the agent of expected behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is efficient and front-loaded, though it lacks any supplementary structure or context. It earns its place but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description is minimally viable but lacks important context. It does not explain what attachments are (e.g., files submitted with a report intent), how they relate to other sibling tools, or what the response contains. For a list operation, some expectation of the return value would help, but the simplicity of the tool makes this a borderline adequate description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: intent_id is described as 'Report intent ID'. The tool description adds no further meaning to this parameter. Since the schema fully documents the parameter, the baseline is 3, and the description does not enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List report intent attachments' clearly states the action (list) and resource (report intent attachments). It is specific enough to distinguish from sibling tools like h1_list_report_intents (which lists intents) and h1_get_report_intent (which gets a single intent). However, it does not elaborate on the scope or relationship to other attachment operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, workflow context, or situations where this is preferred over h1_get_report_intent or h1_list_report_intents. The description is purely a definition with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions Lucene syntax and public scope, but does not disclose read-only nature, authentication requirements, rate limits, pagination behavior, or response format. This is a significant gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action and syntax. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and four parameters, the description is too sparse to give an agent sufficient context. It omits return value structure, pagination details, and any constraints or behavior beyond the basic search action. The tool is likely simple, but the description still leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only the query parameter has a description). The tool description adds little beyond the schema—just the Lucene syntax hint. It does not explain sort options, pagination semantics, or default values, so the description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches public Hacktivity reports using Lucene syntax. It is specific about the resource and action, though it does not explicitly contrast with sibling tools like h1_list_reports, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use the tool (searching public reports), but there is no explicit guidance on when to prefer it over alternatives or exclusion criteria. The usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It indicates a read operation via 'Get', but this merely repeats the tool name. It does not mention potential side effects, required permissions, rate limits, or what happens if the intent ID is invalid. The only additional detail is 'pipeline status', which hints at the response content but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is direct and free of unnecessary words. It effectively front-loads the core purpose without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description gives the basic purpose but lacks details about the returned structure (e.g., what 'pipeline status' includes) and does not clarify the relationship to similar tools. It is adequate but leaves gaps that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter (intent_id) with 'Report intent ID', resulting in 100% schema coverage. The tool description adds no extra parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('report intent') while adding 'pipeline status' as an additional output. This distinguishes it from tools like h1_get_report, but it does not explicitly differentiate from h1_list_report_intents or h1_get_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as h1_list_report_intents or h1_get_report. It lacks any context about prerequisites, exclusions, or scenarios where this tool is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'authenticated' as a requirement, but does not disclose whether the operation is read-only, any rate limits, or what the response format looks like. This is minimal disclosure for a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is perfectly concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params) and lack of output schema, the description is adequate but leaves gaps. It does not indicate the return type or format of the balance, nor does it clarify differentiation from financial siblings, so it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the schema is empty and coverage is 100%. The description adds the clarification that the balance is for the authenticated hacker, which is useful context beyond the schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the authenticated hacker's payment balance, using a specific verb and resource. However, it does not differentiate from sibling tools like h1_get_earnings or h1_get_payouts, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the financially-related siblings (e.g., earnings vs. balance). The description simply states what it does without context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the irreversible nature ('permanently delete'), which is valuable. However, it omits other behavioral aspects such as required permissions, idempotency, or effects on related data, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two well-defined parameters and no output schema, the description is largely sufficient. It clearly states the action and irreversibility. The main gap is the lack of usage context, but this is a low-complexity tool, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having basic descriptions ('Report intent ID' and 'Attachment ID'). The tool description adds no additional meaning beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (permanently delete) and the resource (a report intent attachment). It distinguishes itself from sibling tools like h1_delete_report_intent, which deletes the intent itself, and h1_list_report_intent_attachments, which lists attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or that this should be used for attachment deletion instead of intent deletion. The context is entirely implicit from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states the precondition 'unsubmitted' and does not reveal side effects, permissions, error behavior, or whether attachments are appended or replaced. This is insufficient for a mutation tool like an upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the core purpose without any unnecessary words. It is front-loaded with the verb and quickly specifies the target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two parameters and no output schema, so the description covers the basic purpose and the important 'unsubmitted' constraint. However, it omits behavioral details like maximum file size, handling of existing attachments, or failure modes, which leaves the context incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (the file_paths property lacks its own description), but the description adds little beyond the schema. 'Report intent' echoes the schema's 'Report intent ID' and 'local files' repeats 'Local file path' from the items. It does not clarify array behavior, file types, or any other parameter nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the object (local files), and the target (an unsubmitted report intent). It uses a specific verb and resource that distinguishes it from sibling tools like submit or list attachments, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'unsubmitted report intent' provides clear context on when to use the tool: only for draft (unsubmitted) intents. It implies a precondition but does not explicitly mention alternatives or when not to use it, which would be needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states a mutation action and a precondition ('unsubmitted'), but omits details such as permissions, whether the update is a full replacement, side effects on other fields, or error/response behavior. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It earns its place by conveying both the action and a key constraint, making it highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter update with no annotations or output schema, the description is adequate but incomplete. It does not disclose prerequisites (e.g., ownership, status checks), the nature of the update, or expected outcomes. The simplicity of the schema reduces the need for extensive detail, but the description remains thin on behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters having basic descriptions ('Report intent ID' and 'Vulnerability details'). These are somewhat tautological but do convey meaning. The tool description itself adds no additional parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an unsubmitted report intent' uses a specific verb with a clearly identified resource. It distinguishes itself from sibling tools like h1_create_report_intent, h1_delete_report_intent, and h1_submit_report_intent by focusing on the update action and the 'unsubmitted' state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'unsubmitted' qualifier provides clear context for when this tool applies, implying it should not be used for already submitted intents. However, it does not explicitly name alternatives or exclusions, though the sibling list makes the alternatives evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses permanence ('permanently delete') and the requirement that the intent be unsubmitted, which are important safety traits. However, it does not disclose potential cascading effects on attachments, permissions required, or success/failure behavior, leaving some gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of six words. It conveys the core purpose without any unnecessary content, earning a maximum score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the key constraints (permanence, unsubmitted state). However, it does not address potential side effects on related attachments (given there is a separate deletion tool), nor does it describe the return value or error conditions. This leaves the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter (intent_id with type and description). The tool description adds no additional semantic information about the parameter, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete'), the target ('report intent'), and a key constraint ('unsubmitted'). It distinguishes this tool from siblings like h1_delete_report_intent_attachment and h1_create_report_intent by focusing on the report intent entity itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The qualifier 'unsubmitted' provides a clear condition for when this tool is appropriate, and implicitly excludes submitted report intents. However, it does not mention alternative tools or explicitly state when not to use it, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the ownership scope (authenticated hacker) and read-only nature via 'List'. It adds context beyond the schema, though it omits pagination behavior or response format, which are minor for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, conveying the essential task with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is mostly complete: it identifies the resource and scope. However, it does not mention pagination or return format, and with no output schema, a bit more detail could help. The sibling context and schema constraints still allow an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain page_size or page_number. The names are self-explanatory, but the description provides no defaults, semantics, or relation to pagination, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists reports owned by the authenticated hacker, using a specific verb and resource. This distinguishes it from siblings like h1_get_report (single report) and h1_create_report (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing the authenticated user's reports but does not explicitly state when to prefer this over h1_list_report_intents or provide exclusions. No alternatives are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hackerone-mcp MCP server](https://glama.ai/mcp/servers/alpernae/hackerone-mcp/badges/card.svg)](https://glama.ai/mcp/servers/alpernae/hackerone-mcp)

Score Badge

Copy to your README.md:

[![hackerone-mcp MCP server](https://glama.ai/mcp/servers/alpernae/hackerone-mcp/badges/score.svg)](https://glama.ai/mcp/servers/alpernae/hackerone-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alpernae/hackerone-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server