BugSecure MCP

List reports to triage

list_org_reports

Read-onlyIdempotent

List security reports for your organisation's programmes with filters for status, severity, assignment, and text search.

Instructions

Reports submitted to the programmes of organisations the signed-in user belongs to — only organisations that enabled AI triage access — newest first. Filter by programme, status, severity, assigned triager or text; e.g. status NEW for the untriaged queue. Never includes the user’s own reports as a researcher (a page can hold fewer than limit). Call get_org_report for one report.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Results per page (1–50).
`query`	No	Text to look for in titles and descriptions.
`offset`	No	Results to skip.
`status`	No	Only reports in this status.
`severity`	No	Only reports with this claimed severity.
`programId`	No	Only reports on this programme.
`assignedTriageId`	No	Only reports assigned to this triager (user id).

Output Schema

TableJSON Schema

Name	Required	Description
`limit`	No
`offset`	No
`reports`	No
`nextOffset`	No	Next page’s `offset`; null on the last page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond annotations (readOnly, idempotent, non-destructive), the description adds meaningful behavior: newest-first ordering, hidden filtering to AI-triage-enabled organisations, exclusion of the user's own reports, and the page-size caveat when filters reduce results.

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?

Four tight sentences, no filler, with the most important scoping and ordering information front-loaded. Every sentence contributes a distinct fact needed for correct use.

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 that an output schema exists and all parameters are documented, the description adequately covers scope, ordering, filtering, exclusions, the pagination anomaly, and how to fetch details for one report. Nothing essential for selection or invocation is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds value by grouping filter dimensions (programme, status, severity, assigned triager, text) and clarifying that status NEW represents the untriaged queue—domain meaning not present in the schema.

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?

States a specific verb and resource ('List reports') with an exact scope: reports submitted to programmes of organisations the signed-in user belongs to, restricted to those with AI triage access. This clearly distinguishes it from siblings like list_my_reports and get_org_report.

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?

Provides clear context: the tool is for triage lists, gives a concrete example (status NEW for the untriaged queue), and explicitly routes to get_org_report for a single report. It does not enumerate every alternative, but the scope statement makes the intended use clear.

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