AIエージェントと開発者のための顧客フィードバックインテリジェンス。GitHub Issues、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 Issues、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サーバーコードは非公開（モート）です。軽量クライアントはオープンソースです。
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.
