BugSecure MCP

Get one of my reports

get_report

Read-onlyIdempotent

Retrieve a full bug bounty report including comments, status history, severity grade, CVSS, reward, reasoning, appeals, and optional disclosure draft.

Instructions

One of the signed-in researcher’s own reports, in full: the report, public comments, status history, the grade in force (severity, CVSS, reward and reasoning, and which side graded it: the organisation, or BugSecure as the neutral third party) and any appeals. raise_appeal needs the grade’s id. Comments and status changes come a page at a time (historyOffset). For reports submitted to your organisation, use get_org_report. With disclosures:write, also its public disclosure draft.

Input Schema

TableJSON Schema

Name	Required	Description
`fullText`	No	Return long text fields whole, not cut at 20,000 characters.
`reportId`	Yes	Report id (from list_my_reports or search).
`historyOffset`	No	Skip this many of the newest comments and status changes, to page back through older ones.

Output Schema

TableJSON Schema

Name	Required	Description
`report`	No
`appeals`	No
`history`	No	Up to 20 of each, newest first, shown oldest first.
`comments`	No
`disclosure`	No	Null without disclosures:write, or if not disclosable.
`transitions`	No
`adjudication`	No	The grade in force; null until graded.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, it discloses pagination via historyOffset, 20,000-character truncation unless fullText is set, inclusion of grade details and appeals, and conditional disclosure-draft access based on disclosures:write.

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 dense but well-structured, front-loading the core purpose and then adding precise behavioral details. Every sentence contributes useful information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, full schema coverage, and output schema, the description covers the essential behavioral context: scope, pagination, truncation, conditional fields, and sibling distinction. Nothing critical is missing.

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%, so the schema already documents all parameters. The description adds minimal extra parameter meaning, mostly restating pagination behavior that the schema already explains.

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 states a specific verb and resource: retrieving one of the signed-in researcher's own reports in full. It also distinguishes itself from get_org_report, making the tool's scope unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use get_org_report for reports submitted to the user's organisation, and notes that raise_appeal needs the grade's id. This gives clear routing guidance relative to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.