What can you do with this server?

The FeedbackBasket MCP Server enables AI assistants to query and analyze project feedback, bug reports, and AI-enriched data with secure, read-only access. * List Projects (list_projects): Retrieve all projects accessible by your API key, including summary statistics such as feedback counts by status and category. * Get Feedback (get_feedback): Fetch feedback items with optional filtering by project, category (BUG, FEATURE_REQUEST, IMPROVEMENT, QUESTION), status (OPEN, UNDER_REVIEW, PLANNED, IN_PROGRESS, COMPLETE, CLOSED), sentiment (POSITIVE, NEGATIVE, NEUTRAL), priority, and text search. Each item includes AI-generated summaries, priority scores (0–100), category classifications, and browser/OS/device context. Optionally include internal team notes via includeNotes. * Get Bug Reports (get_bug_reports): Retrieve bug reports with filtering by project, status, severity (high, medium, low), and text search. Returns severity/status breakdowns and optionally includes internal notes. * Search Feedback (search_feedback): Perform a text search across all accessible feedback content, with optional filtering by project and category. Returns up to 50 results. * Pagination: Control result sets with limit (up to 100 for feedback/bugs) and offset parameters. * Security: API key authentication with project-level permissions and read-only data access.

How do I use FeedbackBasket MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FeedbackBasket MCP Server show me high severity bug reports from the last week" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

FeedbackBasket MCP Server

by deifos

Overview Schema Related Servers Score Discussions

TypeScript

Remote

FeedbackBasket MCP Server

Model Context Protocol (MCP) server for FeedbackBasket. Version 3.2.0 provides the same 31 product operations as the FeedbackBasket CLI and live Streamable HTTP server.

Use a read key for queries. Use a full key for approved writes. A project-restricted key can access only its allowed projects. Project creation and team operations need an unrestricted full key. Each high-impact operation needs confirm: true.

Use this STDIO package with an MCP key for local processes, CI, servers, and unattended automation. For remote Streamable HTTP, add https://feedbackbasket.com/.well-known/mcp to the host, save it, and select Authenticate. Sign in, select an organization, select Read or Full access, select Selected projects or All projects, and select Allow. Browser OAuth is the recommended remote setup. It is not used by STDIO.

Read is selected by default. Full needs an explicit choice and an owner or administrator role. Selected projects limits access to the approved projects. All projects includes current and future projects and is required for project creation and team operations. Existing unrestricted MCP keys remain compatible. New browser grants never receive All-projects access silently. Never put an access token, refresh token, MCP key, or CLI token in source, prompts, logs, generated configuration, or final output.

Installation & Setup

1. Generate API Key

Log into feedbackbasket.com
Go to Settings (sidebar)
Scroll to MCP API Keys section
Click New API Key
Name your key (e.g., "Claude Code", "Cursor", "Windsurf")
Select projects to grant access to (or leave empty for all projects)
Copy the generated key. It is shown only once. Keep it out of source, logs, prompts, and command history.

2. Configure Your Editor

Claude Code (CLI)

Set FEEDBACKBASKET_API_KEY in the environment that starts Claude Code. Then add the server without putting the key in the command or shell history:

claude mcp add feedbackbasket -- npx -y feedbackbasket-mcp-server@3.2.0

On native Windows, use cmd /c npx as the command because Claude Code cannot start npx directly there.

Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "feedbackbasket": {
      "command": "npx",
      "args": ["-y", "feedbackbasket-mcp-server@3.2.0"],
      "env": { "FEEDBACKBASKET_API_KEY": "${FEEDBACKBASKET_API_KEY}" }
    }
  }
}

Cursor / Windsurf

Add to your MCP config (.cursor/mcp.json or equivalent):

{
  "mcpServers": {
    "feedbackbasket": {
      "command": "npx",
      "args": ["-y", "feedbackbasket-mcp-server@3.2.0"],
      "env": { "FEEDBACKBASKET_API_KEY": "${FEEDBACKBASKET_API_KEY}" }
    }
  }
}

Environment Variable

Use an environment variable instead of the --api-key argument. This keeps the key out of process listings and saved command history.

{
  "mcpServers": {
    "feedbackbasket": {
      "command": "npx",
      "args": ["-y", "feedbackbasket-mcp-server@3.2.0"],
      "env": {
        "FEEDBACKBASKET_API_KEY": "${FEEDBACKBASKET_API_KEY}"
      }
    }
  }
}

Related MCP server: Sentry MCP Server

Usage Examples

Once configured, ask your AI assistant:

Project Overview

"Show me all my FeedbackBasket projects"
"How much feedback does each project have?"

Bug Reports

"Show me all open bug reports"
"Get high severity bugs that haven't been addressed"
"Find bugs related to authentication"

Feedback Analysis

"Show me negative feedback from my project"
"Get all feature requests"
"What are users asking for the most?"
"Show me high priority feedback"

Search

"Search for feedback about 'payment issues'"
"Find feedback mentioning 'mobile'"

Agentic Workflows

"Look at my bug reports and suggest which ones to fix first"
"Summarize this week's feedback trends"
"Are users happy with the new checkout flow?"

Agent capability contract

Agent surface version: 3.2.0. The CLI and both MCP transports implement the same 31 product operations.

Product operation	CLI command	MCP tool	Required access	Confirm
`projects.list`	`projects list`	`list_projects`	`read:projects`	No
`projects.get`	`projects show`	`get_project`	`read:projects; allowed project`	No
`projects.create`	`projects create`	`create_project`	`write:projects; unrestricted key`	No
`projects.update`	`projects update`	`update_project`	`write:projects; allowed project`	No
`projects.delete`	`projects delete`	`delete_project`	`write:projects; allowed project`	Yes
`feedback.list`	`feedback list`	`get_feedback`	`read:feedback; allowed project`	No
`feedback.get`	`feedback show`	`get_feedback_item`	`read:feedback; allowed project`	No
`feedback.search`	`feedback search`	`search_feedback`	`read:feedback; allowed project`	No
`feedback.create`	`feedback create`	`create_feedback`	`write:feedback; allowed project`	No
`feedback.update`	`feedback update`	`update_feedback`	`write:feedback; allowed project`	No
`feedback.delete`	`feedback delete`	`delete_feedback`	`write:feedback; allowed project`	Yes
`feedback.bulkUpdate`	`feedback bulk-update`	`bulk_update_feedback`	`write:feedback; allowed project`	Yes
`feedback.export`	`feedback export`	`export_feedback`	`read:feedback; allowed project`	No
`bugs.list`	`bugs list`	`get_bug_reports`	`read:feedback; allowed project`	No
`bugs.stats`	`bugs stats`	`get_bug_stats`	`read:feedback; allowed project`	No
`notes.create`	`feedback note`	`create_feedback_note`	`write:notes; allowed project`	No
`notes.update`	`feedback note update`	`update_feedback_note`	`write:notes; allowed project`	No
`notes.delete`	`feedback note delete`	`delete_feedback_note`	`write:notes; allowed project`	Yes
`replies.list`	`feedback replies`	`list_feedback_replies`	`read:feedback; allowed project`	No
`replies.send`	`feedback reply`	`send_feedback_reply`	`write:replies; allowed project`	Yes
`widget.getSettings`	`widget settings`	`get_widget_settings`	`read:projects; allowed project`	No
`widget.updateSettings`	`widget updatewidget flow`	`update_widget_settings`	`write:widget; allowed project`	No
`widget.getScript`	`widget script`	`get_widget_script`	`read:projects; allowed project`	No
`mobile.get`	`mobile statusmobile verify`	`get_mobile_integration`	`read:projects; allowed project`	No
`mobile.update`	`mobile setupmobile bundlemobile conversationsmobile disable`	`update_mobile_integration`	`write:mobile; allowed project`	No
`mobile.rotateKey`	`mobile rotate-key`	`rotate_mobile_project_key`	`write:mobile; allowed project`	Yes
`waitlist.list`	`waitlist list`	`get_waitlist`	`read:feedback; allowed project`	No
`waitlist.export`	`waitlist export`	`export_waitlist`	`read:feedback; allowed project`	No
`team.list`	`team list`	`list_team_members`	`write:team; unrestricted key`	No
`team.updateRole`	`team role`	`update_team_member_role`	`write:team; unrestricted key`	Yes
`team.remove`	`team remove`	`remove_team_member`	`write:team; unrestricted key`	Yes

Security & Privacy

Explicit access — Read keys query data. Full keys can use approved write operations.
Project-level permissions — Restricted keys can access only selected projects.
Confirmation — High-impact operations do not run without explicit confirmation.
API key authentication — Secure token-based authentication
Usage tracking — Monitor API key usage from your Settings page
Revokable access — Deactivate or delete API keys instantly

Troubleshooting

"Invalid or missing API key"

Check that your API key starts with fb_key_
Ensure the key is still active in Settings > MCP API Keys
Verify the key has access to at least one project

"No projects found"

Make sure your API key has been granted access to projects
Check that you have projects in your FeedbackBasket account

Connection Issues

Ensure Node.js 18+ is installed
Try clearing npx cache: npx clear-npx-cache
For local development, add --base-url http://localhost:3000

API Key Management

Visit feedbackbasket.com/dashboard/settings to:

Generate new API keys
Manage project access
View usage statistics
Activate/deactivate keys
Delete keys

Available Tools

4 tools

get_bug_reportsC

Get bug reports specifically from your FeedbackBasket projects

ParametersJSON Schema

Name	Required	Description
`projectId`	No	Filter by specific project ID
`status`	No	Filter by bug status
`severity`	No	Filter by computed severity (based on sentiment: negative=high, neutral=medium, positive=low)
`search`	No	Search bug report content for specific text
`limit`	No	Maximum number of results to return (default: 20, max: 100)
`includeNotes`	No	Include internal notes in the response (default: false)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get bug reports', implying a read operation, but lacks details on permissions, rate limits, pagination, or response format. This is a significant gap for a tool with multiple parameters and no output schema, making it inadequate for informed use.

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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 6 parameters, no annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like response format, error handling, or usage constraints, leaving gaps that could hinder an agent's ability to invoke the tool correctly in a broader context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, providing clear details for all 6 parameters, including enums and defaults. The description adds no additional parameter semantics beyond the schema, so it meets the baseline score of 3, as the schema adequately handles the parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('bug reports specifically from your FeedbackBasket projects'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_feedback' or 'search_feedback', which likely operate on similar data, so it falls short of a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does 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 such as 'get_feedback' or 'search_feedback'. It mentions 'specifically from your FeedbackBasket projects', but this doesn't clarify distinctions in usage context or exclusions, leaving the agent with minimal direction.

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

get_feedbackC

Get feedback from your FeedbackBasket projects with filtering options

ParametersJSON Schema

Name	Required	Description
`projectId`	No	Filter by specific project ID
`category`	No	Filter by feedback category
`status`	No	Filter by feedback status
`sentiment`	No	Filter by sentiment analysis result
`search`	No	Search feedback content for specific text
`limit`	No	Maximum number of results to return (default: 20, max: 100)
`includeNotes`	No	Include internal notes in the response (default: false)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions 'filtering options' without explaining important behaviors like whether this is a read-only operation, how results are ordered, pagination details, rate limits, or authentication requirements. For a tool with 7 parameters and no annotation coverage, this is insufficient.

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?

The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the tool's complexity and front-loads the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how results are structured, or provide behavioral context needed for proper usage. The description should do more to compensate for the lack of structured metadata.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions 'filtering options' which aligns with the schema's filtering parameters, but adds no specific semantic information beyond what the 100% schema coverage already provides. The schema descriptions fully document each parameter's purpose, enums, and defaults, so the description doesn't add meaningful value here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get feedback') and resource ('from your FeedbackBasket projects'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'search_feedback' which appears to serve a similar filtering/search function, preventing a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does 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 like 'search_feedback' or 'get_bug_reports'. It mentions 'filtering options' but doesn't specify when these filters are appropriate or what scenarios warrant using this tool over siblings.

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

list_projectsB

List all FeedbackBasket projects accessible by your API key with summary statistics

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the API key access scope and summary statistics inclusion, which adds some context. However, it doesn't address important behavioral aspects like pagination, rate limits, sorting, or what happens with large result sets. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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?

The description is a single, efficient sentence that communicates the core purpose, scope, and additional value ('summary statistics') without any wasted words. It's appropriately sized for a simple list operation and front-loads the essential information. Every element of the sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers what the tool does and its scope, but doesn't address behavioral aspects like response format, pagination, or error conditions. Without annotations or output schema, the description should ideally provide more complete context about what to expect from the operation.

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?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of parameters. The description appropriately doesn't waste space discussing non-existent parameters. It adds value by clarifying what the tool returns ('summary statistics') without needing to detail inputs. The baseline for 0 parameters with full schema coverage is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List all') and resource ('FeedbackBasket projects'), making the purpose immediately understandable. It specifies scope ('accessible by your API key') and includes additional detail ('with summary statistics'). However, it doesn't explicitly differentiate from sibling tools like get_bug_reports or get_feedback, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does 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 like search_feedback or get_feedback. It mentions the scope ('accessible by your API key') but doesn't explain when this listing approach is preferred over more targeted sibling tools. No explicit when/when-not instructions or alternative recommendations are included.

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

search_feedbackB

Search for feedback across all accessible projects using text search

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query to find in feedback content
`projectId`	No	Limit search to specific project
`category`	No	Filter search results by category
`limit`	No	Maximum number of results (default: 10)

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions searching 'across all accessible projects' which hints at scope, but doesn't address important aspects like permissions needed, whether this is a read-only operation, pagination behavior, rate limits, or what the response format looks like. The description is minimal and lacks crucial behavioral context.

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?

The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a search tool and front-loads the essential information about what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 4 parameters and no output schema, the description is insufficient. It doesn't explain what results look like, how they're structured, or what 'accessible projects' means in practice. With no annotations and no output schema, the description should provide more context about the operation's behavior and results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'text search' which aligns with the 'query' parameter but provides no additional context about parameter interactions or usage patterns.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Search') and resource ('feedback across all accessible projects'), specifying text-based search functionality. It distinguishes from 'get_feedback' (which likely retrieves specific feedback) and 'get_bug_reports' (which is category-specific), though it doesn't explicitly mention these siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for text-based searching of feedback, but doesn't explicitly state when to use this tool versus alternatives like 'get_feedback' or 'get_bug_reports'. No guidance is provided about when not to use it or about prerequisites.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Jan 3, 2026
- Changedget_bug_reports1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedget_feedback1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedlist_projects1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedsearch_feedback1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
4 tool updatesSep 26, 2025
- First observedget_bug_reports
- First observedget_feedback
- First observedlist_projects
- First observedsearch_feedback

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Studex MCP ServerOAuth
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
todo.vu AOAuth
io.github.mooball
Model Context Protocol server for todo.vu task management and time tracking.
Payments & Billing Project Management Workplace & Productivity
2

Related MCP Servers

MCP Feishu Project Manager
Project Management App Automation
Roland0511
A
license
B
quality
F
maintenance
A Model Context Protocol server that enables AI assistants to interact with Feishu project management systems, allowing retrieval of project views and work items.
Updated 10 months ago (2025-11-01 07:01 UTC)
6
12
MIT
Sentry MCP Serverofficial
Monitoring Observability
getsentry
F
license
B
quality
F
maintenance
A Model Context Protocol server that lets AI assistants interact with the Sentry API to retrieve and analyze error data, manage projects, and monitor application performance.
Updated a year ago (2025-04-18 16:13 UTC)
11
11
-
GitHub Tools MCP Server
Version Control Developer Tools Search
arjunkmrm
F
license
Not graded
quality
Not graded
maintenance
Model Context Protocol server that enables interaction with GitHub repositories, issues, pull requests, and search functionality through natural language.
Updated a year ago (2025-05-15 07:29 UTC)
1
-
WeWork MCP Server
Project Management RAG Systems Search
FOX2920
F
license
B
quality
D
maintenance
A Model Context Protocol server providing access to WeWork project management data, enabling project search, task analysis, and statistics retrieval through Claude and other LLM clients.
Updated a year ago (2025-07-02 04:54 UTC)
6
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/deifos/feedbackbasket-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

FeedbackBasket MCP Server

Installation & Setup

1. Generate API Key

2. Configure Your Editor

Claude Code (CLI)

Claude Desktop

Cursor / Windsurf

Environment Variable

Usage Examples

Project Overview

Bug Reports

Feedback Analysis

Search

Agentic Workflows

Agent capability contract

Security & Privacy

Troubleshooting

"Invalid or missing API key"

"No projects found"

Connection Issues

API Key Management

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Sentry MCP Serverofficial

Latest Blog Posts

MCP directory API