FeedbackBasket MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FEEDBACKBASKET_API_KEY | Yes | Your FeedbackBasket API key (starts with fb_key_) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsB | List all FeedbackBasket projects accessible by your API key with summary statistics |
| get_feedbackC | Get feedback from your FeedbackBasket projects with filtering options |
| get_bug_reportsC | Get bug reports specifically from your FeedbackBasket projects |
| search_feedbackB | Search for feedback across all accessible projects using text search |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The tools are mostly distinct in purpose, with clear separation between listing projects, getting bug reports, getting general feedback, and searching feedback. However, there is some potential overlap between 'get_feedback' and 'search_feedback'—both involve retrieving feedback, which could cause mild confusion if an agent needs to choose between them based on vague criteria.
All tool names follow a consistent verb_noun pattern (e.g., get_bug_reports, get_feedback, list_projects, search_feedback). The naming is uniform and predictable, using snake_case throughout without any deviations in style or structure.
With 4 tools, the count is reasonable for a feedback management server, covering core operations like listing projects and retrieving feedback. It is slightly lean but well-scoped, as each tool serves a distinct function without obvious bloat or redundancy.
The tool set covers read operations well (list, get, search) but lacks any write or update capabilities, such as creating, updating, or deleting feedback or projects. This creates notable gaps for agents needing to perform full CRUD operations, limiting the server to query-only workflows.