Read-only access to a Feedback Hub instance's Cloudflare D1 database, using a D1 Read-scoped API token to fetch feedback statistics and individual entries (with type, urgency, sentiment, and limit filters) for analysis by AI assistants.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Feedback Hub MCP Show me the urgent bugs, newest first."
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.
An MCP server that lets AI assistants like Claude read and analyze the data in Feedback Hub, a feedback collection app that classifies incoming feedback with AI.
Once connected, you can ask Claude questions like:
"How many feedback entries do we have, and what's the breakdown by type?"
"Show me the urgent bugs."
"What are people asking for most?"
Claude picks the right tool, queries the live database and answers in plain language, often adding its own prioritization ("#4 blocks a whole team, look at it first").
Tool | What it does |
| Total number of entries, broken down by type and classification status. |
| Individual entries, newest first, with the original message, AI summary and classification. Optional filters: |
Related MCP server: Customer Service Data Analyst MCP Server
Giving an AI access to a database deserves care. This server is built so that safety does not depend on the code being bug-free:
Read-only at the platform level. The Cloudflare API token only has the D1 Read permission. Any attempt to change data is rejected by Cloudflare itself, even if the code or the AI tried to.
No personal data leaves the server. Submitter email addresses are never selected from the database, so they never reach the AI's context.
Constrained inputs. Filters only accept a fixed list of values, and every value is passed to SQL as a bound parameter (?), never concatenated into the query.
No secrets in the repo. All credentials live in a git-ignored .env file. Only an empty template (.env.example) is committed.
A deployed Feedback Hub instance with its D1 database
Node.js 20.12 or later
git clone https://github.com/aydin-omer/feedback-hub-mcp.git
cd feedback-hub-mcp
npm installIn the Cloudflare dashboard, go to My Profile → API Tokens → Create Token and create a custom token with a single permission: Account → D1 → Read. Copy the token; it is only shown once.
cp .env.example .envFill in the three values in .env:
CLOUDFLARE_ACCOUNT_ID: run npx wrangler whoami
D1_DATABASE_ID: run npx wrangler d1 list and copy the ID of your Feedback Hub database
CLOUDFLARE_API_TOKEN: the read-only token from step 2
npx @modelcontextprotocol/inspector node src/index.jsIn the browser window that opens, click Connect, then Tools → List Tools, and run get_feedback_stats.
In Claude Desktop, open Settings → Developer → Edit Config and add a mcpServers entry to claude_desktop_config.json. Use absolute paths; run which node to find yours:
{
"mcpServers": {
"feedback-hub": {
"command": "/usr/local/bin/node",
"args": ["/absolute/path/to/feedback-hub-mcp/src/index.js"]
}
}
}If the file already contains other settings, add mcpServers next to them rather than replacing the file.
Quit Claude Desktop completely (Cmd+Q on macOS), reopen it and start a new chat. Claude reads the server list only on startup, and the tool list at the start of each chat.
Claude doesn't see a new tool: restart Claude Desktop and start a new chat.
Server doesn't start: run npm start in the project folder. A "Missing configuration" message means .env is missing or incomplete.
Logs: on macOS, Claude Desktop writes the server's log to ~/Library/Logs/Claude/mcp-server-feedback-hub.log.
Returns the total number of feedback entries in Feedback Hub, with a breakdown by type (bug, feature request, praise...) and by classification status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the shape of what comes back (total plus breakdowns by type and classification status), which implies a read-only aggregate. It says nothing about scope (all feedback vs. filtered), freshness, permissions, or the format of the breakdown, leaving real gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary fact (it returns a total) and then the secondary breakdown dimensions. No filler, no restatement of the title beyond what is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey the return shape, and it does so at a high level: total count, breakdown by type, breakdown by classification status. It stops short of describing field names or whether the breakdown values are counts vs. percentages, which is the only meaningful remaining gap for a zero-parameter stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4 and there is nothing for the description to compensate for. The one sentence that could matter — whether the stats are global or scoped — is not addressed, but with an empty schema there is no parameter ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Returns the total number of feedback entries in Feedback Hub') and enumerates the breakdown dimensions, so the aggregate nature of the tool is unmistakable. It does not explicitly contrast with the sibling list_feedback, but the count/breakdown framing distinguishes it implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is for summary counts rather than enumerating individual entries, but the description never says when to prefer it over list_feedback or whether the two cover the same data set. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists individual feedback entries from Feedback Hub, newest first. Each entry includes the original message, an AI-generated summary, and its classification (type, sentiment, urgency). Optional filters can be combined. Submitter email addresses are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Only return feedback of this type. | |
| limit | No | Maximum number of entries to return (1-50, default 10). | |
| urgency | No | Only return feedback with this urgency. | |
| sentiment | No | Only return feedback with this sentiment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses sort order (newest first), the fields returned per entry, and a privacy guarantee ('submitter email addresses are never returned'). It omits pagination/truncation behavior at the limit boundary and any auth or rate-limit context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: purpose and ordering first, then return contents, then filter behavior and the privacy note. No redundancy and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by describing the entry fields (message, AI summary, classification). With four optional parameters at full schema coverage, the only real gap is behavior at the limit boundary or total-count semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum descriptions for type, urgency, and sentiment, so the schema already documents every parameter. The description's only added semantic is that filters combine, which does not warrant a higher score than baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists individual feedback entries from Feedback Hub') plus ordering ('newest first') and the shape of each entry. The word 'individual' implicitly contrasts with the get_feedback_stats sibling, though it never names that alternative outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Optional filters can be combined' tells the agent the filters compose, and listing 'individual entries' points at per-item retrieval rather than aggregates. However, there is no explicit when-to-use/when-not guidance and no mention of the get_feedback_stats sibling for summary-level needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0get_feedback_statslist_feedbackScored across 2 tools
The two tools have clearly distinct purposes: get_feedback_stats returns aggregate counts and breakdowns, while list_feedback returns individual entries. An agent can easily choose between summary statistics and detailed records.
Both names use a consistent snake_case verb_noun pattern: get_feedback_stats and list_feedback. The shared 'feedback' noun and clear verb prefixes make the naming predictable.
Two tools is thin for a feedback hub server, even if the intended scope is read-only. The set feels borderline minimal rather than well-scoped for broader feedback workflows.
The surface only supports reading aggregate stats and listing entries. Core lifecycle operations such as submitting feedback, retrieving a single entry, updating classification/status, or resolving feedback are absent, creating significant gaps for a feedback hub.
Query your customer feedback: studies, themes, suggestions, tags, and sentiment trends.
Agent-ready feedback for AI-built apps — read and close UI feedback reports over MCP.
Give AI agents access to form submissions — read, search, update, and process file attachments.
Read AI-gateway analytics, configs, virtual keys, workspaces and users; log request feedback.
