Skip to main content
Glama
Sign In
feedbug-mcp

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "feedbug_list_bugs"
  }
}

Input 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