Skip to main content
Glama
joffreyBerrier

feedbug-mcp

by joffreyBerrier
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List bug reports

feedbug_list_bugs
Read-onlyIdempotent

List bug reports from Feedbug, newest first. Filter by status or page URL to find open issues or review reports for a specific page without needing a bug ID.

Instructions

List the bug reports captured by the Feedbug widget, newest first.

Returns: a JSON array carrying, per bug, its UUID, tracker identifier (e.g. PRE-13), title, status, page URL, framework component path, session replay URL and creation date. Use when: you are looking for a bug to work on, checking what is still open, or reviewing every report filed on one page. Do not use when: you already hold a bug id — feedbug_get_bug returns that one report with its screenshot and DOM context. Behavior: read-only and idempotent. The server authenticates with the FEEDBUG_PROJECT_KEY environment variable and can only ever see that single project. There is no pagination: the API truncates to limit, so narrow the set with status or page_url instead of paging. No match returns an empty array, not an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many bugs to return, newest first. Integer between 1 and 50, defaults to 20; the API clamps anything higher to 50.
statusNoFeedbug status to keep. Omit to get every status. 'in-progress' only ever occurs on bugs tracked in Linear, since a GitHub issue is either open or closed.
page_urlNoSubstring matched case-insensitively against the whole page URL of the report — '/checkout' to inspect one route, 'staging.' to inspect one environment. Omit to search every page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.1.2
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default: 20)"New value: +"How many bugs to return, newest first. Integer between 1 and 50, defaults to 20; the API clamps anything higher to 50."
    • changedInput schema / properties / page_url / description
      Previous value: -"Filter by page URL (substring match)"New value: +"Substring matched case-insensitively against the whole page URL of the report — '/checkout' to inspect one route, 'staging.' to inspect one environment. Omit to search every page."
    • changedInput schema / properties / status / description
      Previous value: -"Filter by status (default: all)"New value: +"Feedbug status to keep. Omit to get every status. 'in-progress' only ever occurs on bugs tracked in Linear, since a GitHub issue is either open or closed."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Adds context beyond annotations: read-only/idempotent restated, auth scope (FEEDBUG_PROJECT_KEY, single project), truncation/no-pagination behavior, and empty-array return. No contradiction with annotations.

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?

Well-structured: purpose, return format, use-when, do-not-use, behavior, edge case. Every sentence adds value; appropriately sized for a tool with rich behavior.

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?

Provides return shape (JSON array with fields), auth scope, truncation, empty-array behavior, and usage boundaries. No output schema, so the description carries the return-format burden – fully covered.

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 already describes all 3 params (100% coverage). Description adds the tip to narrow via status/page_url instead of paging and clarifies truncation, which complements schema. Slight redundancy with schema's clamping note.

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 'List the bug reports captured by the Feedbug widget, newest first' – specific verb+resource+order. Clearly differentiates from feedbug_get_bug by describing when not to use it (when holding a bug id).

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?

Explicitly provides 'Use when' and 'Do not use when' sections, naming the alternative feedbug_get_bug. Also advises narrowing with status/page_url instead of paging, giving clear context.

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

Deploy Server

Other Tools