feedbug-mcp
Server Quality Checklist
Latest release: v0.1.2
- Disambiguation5/5
Each tool targets a distinct aspect of bug management: retrieving different types of context (HTML, diagnostics, replay), listing vs. getting a single bug, resolving, and commenting. No two tools have overlapping purposes.
Naming Consistency5/5All tools follow a consistent feedbug_verb_noun pattern with underscores. Verbs are uniform (get, list, resolve, add) and clearly indicate action, making the set predictable and easy to navigate.
Tool Count5/5Seven tools is a well-scoped number for a bug triage and resolution server. Each tool serves a necessary function without redundancy or unnecessary complexity.
Completeness4/5The tool set covers the full lifecycle for fixing a reported bug: retrieving all diagnostic info, resolving, and commenting. The only minor gap is the lack of direct update operations for bug metadata (e.g., title, status beyond resolved), but this is unlikely to hinder the core workflow.
Average 3.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description implies a read operation (list), but does not explicitly state that it is non-destructive, does not mention pagination, ordering, or any side effects. For a list tool, this is minimal but acceptable; however, explicit safety context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the action and quickly listing the return fields. Every sentence is necessary and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is adequately minimal. It explains what the tool returns but does not elaborate on output format, default ordering, or the meaning of 'FeedBug widget'. For a simple list tool this is sufficient, but lacks completeness for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add any additional meaning or context for the parameters. Baseline 3 is appropriate as the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'bugs reported via FeedBug widget', and distinguishes from sibling tools like feedbug_get_bug by specifying that it returns multiple bugs. It also lists the fields returned, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of when to prefer list_bugs over get_bug, or any context about prerequisites or typical use cases. The agent must infer from the name alone.
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 provided, the description carries the full burden. It lists the output fields, which gives some behavioral insight, but it does not state whether the operation is read-only, requires authentication, or has any side effects. The description is minimal but adequate for a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence (15 words) that efficiently conveys the tool's purpose and output. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 lists the output fields but does not describe the return format or structure (e.g., JSON object). For a simple tool this is adequate, but it could be more complete by specifying the output structure or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single 'id' parameter is well described in the schema). The tool description adds no additional meaning beyond the schema; it simply repeats the idea of 'for a bug'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'browser diagnostics for a bug', and lists specific output fields (page URL, viewport size, user agent, reporter name). This distinguishes it from sibling tools like feedbug_get_bug (which likely returns full bug details) and feedbug_get_html_context (HTML 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description does not mention when not to use it, nor does it reference sibling tools like feedbug_get_bug, feedbug_get_html_context, or feedbug_get_replay for different diagnostic needs.
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, and the description is minimal. It does not disclose any behavioral traits such as authentication requirements, side effects, constraints (e.g., comment length limits), or error handling. The description carries the full burden but only states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two clear, front-loaded sentences with no extraneous information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema and no annotations. The description does not explain what happens after adding a comment (e.g., return value, placement, permission requirements). Given the simplicity, more context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters (id and body) with descriptions. The tool description adds no additional meaning beyond what is in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Add a comment to a bug', which is a specific verb+resource combination. It clearly distinguishes from sibling tools like feedbug_list_bugs, feedbug_get_bug, and feedbug_resolve_bug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage examples such as 'provide updates, ask questions, or document your fix', giving clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like feedbug_resolve_bug.
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 full burden for behavioral disclosure. It only declares what information is returned, but fails to mention side effects (e.g., read-only nature), authentication requirements, rate limits, or error behavior (e.g., what happens when the bug ID does not exist). The name implies a read operation, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action and key return fields without any wasted words. Every piece of information serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the purpose and main return fields. However, it omits details about the return format (e.g., JSON structure) and error handling (e.g., invalid ID). Given the tool's low complexity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter 'id' with a clear description. The tool description adds no additional meaning beyond what the schema already provides (e.g., formatting constraints, allowed values). Baseline 3 is appropriate since schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'a specific bug', then lists key return fields (HTML context, screenshot URL, viewport, user agent). This clearly distinguishes it from sibling tools like 'feedbug_list_bugs' (which lists many) or 'feedbug_get_html_context' (which gets only part).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but gives no explicit guidance on when to choose it over alternatives. Sibling tool names (e.g., feedbug_get_diagnotics, feedbug_get_replay) imply different specializations, but without explicit when-to-use or when-not-to-use statements, an agent must infer usage context.
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 exist, so the description carries the full burden. It only says 'Mark a bug as resolved' without disclosing side effects, permission requirements, idempotency, or whether the action is reversible. The precondition 'after fixing it' is helpful but insufficient for full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler. The first states the action, the second provides the usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter state-change tool, the description covers the basic purpose and usage condition. However, it lacks information about the return value or confirmation of success, and no output schema exists to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the one parameter 'id' is described in the schema as 'Feedback UUID or Linear identifier'). The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Mark' and the resource 'bug as resolved'. It distinguishes from sibling tools (listing, getting, adding comments) by specifying a state-change action. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit condition: 'Use this when you have fixed the issue reported in a FeedBug bug.' This tells the agent when to invoke the tool, though it doesn't explicitly state when not to use it or mention alternatives (e.g., adding a comment).
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 provided, the description carries the full burden. It discloses the type of data returned (CSS selector path, framework component path, clicked element details, ancestors, siblings) and implies a read-only operation by only listing returns. It does not mention authentication, rate limits, or error handling, but given the tool's nature (a getter), this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: the first clearly states the action and data returned, the second provides a usage directive. Every sentence adds value, and the content is front-loaded with the most important information. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values. It lists the categories of returned data (CSS selector path, framework component path, clicked element details, ancestors, siblings). However, it does not describe the structure (e.g., whether these are separate fields or a combined object), nor does it address error cases (e.g., invalid bug ID). Still, for a single-parameter tool, the coverage is good.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Feedback UUID or Linear identifier (e.g. PRE-13)'. The description adds no additional semantics or usage guidance for the parameter beyond what the schema already provides. Baseline 3 is appropriate given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb ('Get') and resource ('HTML/DOM context captured when the bug was reported'), immediately distinguishing this tool from siblings like feedbug_get_bug (which returns general bug details) or feedbug_get_replay. The list of returned data (CSS selector path, framework component path, clicked element details, ancestor/sibling elements) further clarifies the exact scope of output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use this to trace a bug back to source code,' providing a clear use case. While it does not mention when *not* to use this tool or directly compare to alternatives, the purpose is specific enough that an agent can infer when to choose it over siblings (e.g., when HTML/DOM context is needed rather than diagnostics or replay).
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 full burden. It discloses that the tool returns a URL (not the replay itself) and specifies the replay duration (last 30 seconds). This adds meaningful behavioral context beyond a generic 'get replay'. It does not cover potential expiration or authentication needs, but the core behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous information. The first sentence states the core action, the second adds a critical detail (replay duration). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description is complete. It explains what the tool returns, what the replay contains, and implies the input is a bug identifier. No gaps remain for a typical usage scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the input schema already describes the 'id' parameter as a 'Feedback UUID or Linear identifier'. The description adds no additional parameter detail. Baseline score of 3 is appropriate since the schema handles the explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the session replay URL') and the resource ('for a bug'), with additional context about what the replay contains. It distinguishes itself from siblings like feedbug_get_bug (which returns bug details) and feedbug_list_bugs (which lists bugs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need a session replay showing user activity before a bug was reported. However, it does not explicitly state when not to use it or mention alternatives among siblings, though the purpose is distinct enough to avoid confusion.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/joffreyBerrier/feedbug-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server