This server transforms raw customer feedback into structured intelligence using an LLM pipeline. It supports GitHub Issues, Hacker News, and Apple App Store Reviews as data sources.
synthesize_feedback — Multi-source analysis running a multi-pass LLM pipeline to return up to 10 ranked pain clusters with impact scores, evidence links, and suggested actions ($0.05/call)
get_pain_points — Fast single-source extraction of top pain points with frequency counts and sample evidence URLs; cheaper and quicker than full synthesis ($0.02/call)
search_feedback — Full-text search across cached feedback items to drill into specific topics without triggering new LLM processing ($0.01/call)
get_sentiment_trends — Time-series sentiment analysis at weekly or monthly granularity, useful for measuring the impact of releases or bug fixes ($0.03/call)
All tools use pay-per-call micropayments via x402 (USDC on Base mainnet) — no signup or API keys required, just an EVM wallet.
Customer feedback intelligence for AI agents and developers. Synthesize GitHub Issues, Hacker News threads, and App Store reviews into ranked pain clusters with evidence links. Pay-per-call via x402 micropayments — no signup required.
Stop reading through hundreds of feedback items manually. Feedback Synthesis MCP collects from multiple sources, runs a multi-pass LLM pipeline, and returns ranked pain clusters with impact scores, evidence links, and suggested actions — machine-readable for agents, human-readable for founders.
Install:
pip install feedback-synthesis-mcpSet your wallet key (any EVM wallet with USDC on Base mainnet):
export EVM_PRIVATE_KEY=your_private_key_hereAdd to Claude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Add to Cursor — edit .cursor/mcp.json in your project root:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Restart your client. You now have four customer intelligence tools available.
Related MCP server: NPS Chatbot MCP Server
Tool | What it does | Price |
| Multi-source synthesis → ranked pain clusters with evidence | $0.05/call |
| Quick single-source pain point extraction | $0.02/call |
| Full-text search across cached feedback items | $0.01/call |
| Time-series sentiment across sources | $0.03/call |
Supported sources: GitHub Issues, Hacker News, Apple App Store Reviews
synthesize_feedback(
sources=[
{"type": "github_issues", "target": "owner/my-repo", "labels": ["bug", "feature-request"]},
{"type": "hackernews", "target": "Show HN: MyProduct"}
],
since="2026-01-01T00:00:00Z"
)Returns:
{
"job_id": "syn_abc123",
"status": "completed",
"summary": "Analyzed 347 feedback items from 2 sources. Found 6 pain clusters.",
"pain_clusters": [
{
"rank": 1,
"title": "Authentication flow breaks on mobile Safari",
"severity": "critical",
"frequency": 23,
"impact_score": 0.92,
"description": "Users report inability to complete OAuth login on iOS Safari. Affects onboarding conversion.",
"evidence": [
{
"source": "github",
"url": "https://github.com/owner/my-repo/issues/142",
"snippet": "Login fails silently on Safari 17.2+"
}
],
"suggested_actions": [
"Fix Safari WebAuthn polyfill (see issue #142)",
"Add fallback auth flow for mobile browsers"
]
}
]
}get_pain_points(
source={"type": "github_issues", "target": "owner/my-repo", "labels": ["bug"]},
top_n=5
)search_feedback(query="pricing too expensive", sources=["github_issues", "hackernews"])get_sentiment_trends(
sources=[{"type": "appstore", "target": "com.example.myapp"}],
since="2025-10-01T00:00:00Z",
granularity="weekly"
)This MCP uses x402 micropayments on Base mainnet (USDC). You need:
An EVM wallet with USDC on Base mainnet
The wallet's private key set as EVM_PRIVATE_KEY
Each call costs $0.01–$0.05 USDC. Payments are made automatically — no subscriptions, no API keys.
No payment configured? The server returns a helpful error with setup instructions.
This package is a thin MCP client. All processing happens on the hosted backend:
Your Agent / Claude Desktop
│
▼
feedback-synthesis-mcp (this package)
- MCP tool definitions
- x402 payment signing
- Zero business logic
│ HTTPS + x402
▼
Hosted Backend (Railway)
- Multi-source data collection
- 3-stage LLM pipeline (Haiku × N + Sonnet × 1)
- SQLite caching + FTS search
- x402 payment verificationServer code is private (moat). Thin client is open source.
Skip the PyPI package for programmatic/agent access using the hosted MCP endpoint directly:
MCP Server URL: https://feedback-synthesis-mcp-production.up.railway.app/mcp/
For MCP clients that support Streamable HTTP transport (Claude Desktop via HTTP, custom agents):
{
"mcpServers": {
"feedback-synthesis-mcp": {
"type": "streamable-http",
"url": "https://feedback-synthesis-mcp-production.up.railway.app/mcp/"
}
}
}x402 payment is handled automatically by the client SDK. Set EVM_PRIVATE_KEY in your environment.
MIT
Quickly extract top pain points from a single feedback source.
Faster and cheaper than synthesize_feedback — single LLM pass, one source. Returns the top N pain points with frequency counts and sample evidence URLs.
Args: source: Source spec with 'type' (github_issues/hackernews/appstore) and 'target'. Example: {"type": "github_issues", "target": "owner/repo", "labels": ["bug"]} max_items: Max items to collect (default 100) top_n: Number of top pain points to return (default 5)
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| max_items | No | ||
| top_n | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 behavioral traits like 'single LLM pass' (implying computational approach), 'faster and cheaper' (performance/cost), and 'returns... with frequency counts and sample evidence URLs' (output format). However, it lacks details on rate limits, authentication needs, or error handling, which are important for a tool with data collection.
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?
The description is well-structured and concise: first sentence states purpose, second compares to sibling, third describes output, and the 'Args' section lists parameters clearly. Every sentence adds value without waste, and it's front-loaded with key information.
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?
Given 3 parameters with 0% schema coverage, no annotations, and an output schema (which reduces need to explain returns), the description is mostly complete. It covers purpose, usage, parameters, and output hints, but could improve by mentioning potential limitations (e.g., source compatibility) or error cases for better agent guidance.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: 'source' includes types and an example, 'max_items' and 'top_n' have defaults and purposes. This clarifies semantics beyond the bare schema, though it could detail 'source' constraints more (e.g., valid 'target' formats).
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 clearly states the tool's purpose: 'extract top pain points from a single feedback source.' It specifies the verb ('extract'), resource ('pain points'), and scope ('single feedback source'), and distinguishes it from sibling 'synthesize_feedback' by noting it's 'faster and cheaper' with 'single LLM pass, one source.'
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?
The description explicitly provides usage guidance: 'Quickly extract...' implies speed, and it directly compares to 'synthesize_feedback' as an alternative for when you need a faster, cheaper option with a single source. This gives clear context on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time-series sentiment analysis across feedback sources.
Shows how sentiment shifts over time — useful for tracking the impact of releases, bug fixes, or feature launches. Returns weekly/monthly sentiment scores with notable shifts and likely causes.
Args: sources: List of source specs (same format as synthesize_feedback) since: Start date for trend analysis (ISO 8601, default 6 months ago) granularity: Time bucket size — 'weekly' (default) or 'monthly'
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | ||
| since | No | 2025-10-01T00:00:00Z | |
| granularity | No | weekly |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 adds useful context about the tool's output ('Returns weekly/monthly sentiment scores with notable shifts and likely causes'), but it does not cover aspects like rate limits, authentication needs, or error handling, leaving gaps for a tool with no annotation support.
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?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by usage context, output details, and parameter explanations in a structured 'Args' section. Every sentence adds value without redundancy.
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?
Given the tool's complexity (time-series analysis with three parameters) and the presence of an output schema (which reduces the need to explain return values), the description is largely complete. It covers purpose, usage, parameters, and output behavior, though it could benefit from more behavioral details like error cases or performance considerations.
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 schema description coverage is 0%, so the description must compensate fully. It explicitly lists and explains all three parameters (sources, since, granularity), including formats, defaults, and options, adding significant meaning beyond the bare schema, which lacks any descriptions.
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 clearly states the tool's purpose with specific verbs ('Get time-series sentiment analysis') and resources ('across feedback sources'), distinguishing it from siblings like get_pain_points and search_feedback by focusing on temporal trends rather than static analysis or searching.
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?
The description provides clear context for when to use the tool ('tracking the impact of releases, bug fixes, or feature launches'), but it does not explicitly state when not to use it or name alternatives among the sibling tools, such as synthesize_feedback for aggregated insights.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search raw feedback items across cached sources using full-text search.
Useful for drilling into a specific topic after synthesis. Searches previously collected feedback without triggering new LLM processing. Fast and cheap.
Args: query: Search terms (e.g. 'authentication mobile' or 'pricing too expensive') sources: Filter by source types (e.g. ['github_issues', 'appstore']) target: Filter by target repo/app (e.g. 'owner/repo') since: ISO 8601 datetime filter (e.g. '2026-01-01T00:00:00Z') limit: Max results to return (default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| sources | No | ||
| target | No | ||
| since | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that searches are 'fast and cheap,' operate on 'cached sources' and 'previously collected feedback,' and do not trigger 'new LLM processing.' This covers performance, data source, and processing behavior, though it could mention rate limits or auth needs.
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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by usage context and behavioral traits, then a structured parameter section. Every sentence adds value with zero waste, making it easy for an agent to parse quickly.
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?
Given 5 parameters with 0% schema coverage and no annotations, the description provides complete context: purpose, usage guidelines, behavioral traits, and full parameter semantics. With an output schema present, return values need not be explained, making this description comprehensive for tool selection and invocation.
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 description coverage is 0%, so the description must compensate fully. It adds detailed semantics for all 5 parameters: query ('Search terms'), sources ('Filter by source types'), target ('Filter by target repo/app'), since ('ISO 8601 datetime filter'), and limit ('Max results to return'). Examples clarify usage, effectively documenting parameters beyond the bare schema.
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 clearly states the tool's purpose with specific verbs ('search raw feedback items') and resources ('across cached sources using full-text search'). It distinguishes from siblings by specifying it searches 'previously collected feedback without triggering new LLM processing' versus synthesis tools like synthesize_feedback.
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?
Explicit guidance is provided: 'Useful for drilling into a specific topic after synthesis' indicates when to use it, and 'Searches previously collected feedback without triggering new LLM processing' distinguishes it from tools that might process new data. It contrasts with siblings like synthesize_feedback by emphasizing it's for raw search, not synthesis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Synthesize customer feedback from multiple sources into ranked pain clusters.
Collects feedback from GitHub Issues, Hacker News, and/or App Store Reviews, then runs a multi-pass LLM pipeline to extract and rank pain clusters with evidence. Returns up to 10 ranked pain clusters with impact scores, evidence links, and suggested actions. Takes 10-60 seconds depending on volume.
Args: sources: List of source specs. Each has 'type' (github_issues/hackernews/appstore) and 'target' (owner/repo, search query, or app bundle ID). Example: [{"type": "github_issues", "target": "owner/repo"}, {"type": "hackernews", "target": "MyProduct"}] max_items_per_source: Max feedback items to collect per source (default 200) since: ISO 8601 datetime to filter items (e.g. '2026-01-01T00:00:00Z') focus: Analysis focus — 'pain_points' (default) or 'feature_requests'
| Name | Required | Description | Default |
|---|---|---|---|
| sources | No | ||
| max_items_per_source | No | ||
| since | No | ||
| focus | No | pain_points |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: the multi-pass LLM pipeline process, execution time (10-60 seconds), output format (up to 10 ranked pain clusters with impact scores, evidence links, suggested actions), and data collection limits (max items per source). It does not mention rate limits or authentication needs.
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?
The description is appropriately sized and front-loaded, starting with the core purpose, followed by details on sources, process, output, timing, and parameters. Every sentence earns its place by adding essential information without redundancy, structured in logical paragraphs.
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?
Given the tool's complexity (multi-source synthesis with LLM pipeline), no annotations, 0% schema coverage, but with an output schema present, the description is complete enough. It covers purpose, usage, behavior, parameters, and output details, compensating for gaps in structured data and leveraging the output schema for return values.
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 description coverage is 0%, so the description must compensate fully. It successfully adds meaning beyond the schema by explaining all 4 parameters: 'sources' with examples and types, 'max_items_per_source' with default and purpose, 'since' with format and filtering role, and 'focus' with options and default. This provides complete parameter semantics.
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 clearly states the specific action ('synthesize customer feedback from multiple sources into ranked pain clusters'), identifies the resources (GitHub Issues, Hacker News, App Store Reviews), and distinguishes from siblings by emphasizing multi-source synthesis versus single-source retrieval (get_pain_points, search_feedback) or sentiment analysis (get_sentiment_trends).
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?
The description provides clear context for when to use this tool (collecting feedback from multiple sources for synthesis and ranking) and implies alternatives through sibling tool names, but does not explicitly state when not to use it or directly compare to siblings like 'get_pain_points' for single-source analysis.
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. Dates show when Glama detected each change.
v0.1.1get_pain_pointsget_sentiment_trendssearch_feedbacksynthesize_feedbackEach tool has a clearly distinct purpose with minimal overlap: get_pain_points extracts pain points from a single source, get_sentiment_trends analyzes sentiment over time, search_feedback performs full-text searches on cached data, and synthesize_feedback synthesizes multiple sources into pain clusters. The descriptions explicitly differentiate them, such as noting get_pain_points is faster than synthesize_feedback for single sources, eliminating confusion.
All tool names follow a consistent verb_noun pattern with snake_case: get_pain_points, get_sentiment_trends, search_feedback, and synthesize_feedback. This uniformity makes the set predictable and easy to understand, enhancing usability for agents without any deviations in style.
With 4 tools, this server is well-scoped for feedback synthesis, covering key operations like extraction, analysis, search, and synthesis. Each tool serves a unique function, and the count is neither too sparse nor bloated, fitting typical MCP server ranges for a focused domain.
The toolset covers core feedback analysis workflows effectively, including single-source extraction, multi-source synthesis, sentiment tracking, and search. A minor gap exists in lacking explicit update or deletion tools for managing cached feedback, but agents can work around this, and the surface supports comprehensive analysis without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that automatically collects feedback on your MCP server.
Hosted MCP server for the FeedbackRobot customer feedback and reviews platform
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sapph1re/feedback-synthesis-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
