AI 에이전트와 개발자를 위한 고객 피드백 인텔리전스. GitHub 이슈, Hacker News 스레드, App Store 리뷰를 증거 링크가 포함된 순위별 고충 클러스터로 합성합니다. x402 마이크로페이먼트를 통한 호출당 결제 방식이며, 별도의 가입이 필요 없습니다.
수백 개의 피드백 항목을 수동으로 읽지 마세요. 피드백 합성 MCP는 여러 소스에서 데이터를 수집하고, 다단계 LLM 파이프라인을 실행하여 영향력 점수, 증거 링크, 제안된 조치가 포함된 순위별 고충 클러스터를 반환합니다. 이는 에이전트가 읽을 수 있는 기계 가독성 형식과 창업자가 읽을 수 있는 인간 가독성 형식을 모두 제공합니다.
설치:
pip install feedback-synthesis-mcp지갑 키 설정 (Base 메인넷에 USDC가 있는 모든 EVM 지갑):
export EVM_PRIVATE_KEY=your_private_key_hereClaude Desktop에 추가 — ~/Library/Application Support/Claude/claude_desktop_config.json 파일을 수정하세요:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Cursor에 추가 — 프로젝트 루트의 .cursor/mcp.json 파일을 수정하세요:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}클라이언트를 재시작하세요. 이제 4가지 고객 인텔리전스 도구를 사용할 수 있습니다.
Related MCP server: NPS Chatbot MCP Server
도구 | 기능 | 가격 |
| 다중 소스 합성 → 증거가 포함된 순위별 고충 클러스터 | 호출당 $0.05 |
| 빠른 단일 소스 고충점 추출 | 호출당 $0.02 |
| 캐시된 피드백 항목 전체 텍스트 검색 | 호출당 $0.01 |
| 소스별 시계열 감정 분석 | 호출당 $0.03 |
지원 소스: GitHub 이슈, Hacker News, Apple App Store 리뷰
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"
)반환값:
{
"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"
)이 MCP는 Base 메인넷(USDC)에서 x402 마이크로페이먼트를 사용합니다. 다음이 필요합니다:
Base 메인넷에 USDC가 있는 EVM 지갑
EVM_PRIVATE_KEY로 설정된 지갑의 개인 키
각 호출 비용은 $0.01–$0.05 USDC입니다. 결제는 자동으로 이루어지며, 구독이나 API 키가 필요하지 않습니다.
결제가 설정되지 않았나요? 서버가 설정 지침이 포함된 유용한 오류 메시지를 반환합니다.
이 패키지는 가벼운 MCP 클라이언트입니다. 모든 처리는 호스팅된 백엔드에서 수행됩니다:
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 verification서버 코드는 비공개(moat)입니다. 가벼운 클라이언트는 오픈 소스입니다.
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.
v0.1.1get_pain_pointsget_sentiment_trendssearch_feedbacksynthesize_feedbackScored across 4 tools
Each 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.
An MCP server that automatically collects feedback on your MCP server.
One MCP server over 253 data sources: Reddit, LinkedIn, YouTube, G2, search and AI answers.
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.
