Inteligencia de feedback de clientes para agentes de IA y desarrolladores. Sintetiza Issues de GitHub, hilos de Hacker News y reseñas de la App Store en grupos de problemas clasificados con enlaces de evidencia. Pago por llamada mediante micropagos x402 — no requiere registro.
Deja de leer cientos de elementos de feedback manualmente. El MCP de Síntesis de Feedback recopila información de múltiples fuentes, ejecuta una canalización LLM de varias pasadas y devuelve grupos de problemas clasificados con puntuaciones de impacto, enlaces de evidencia y acciones sugeridas — legible por máquinas para agentes y por humanos para fundadores.
Instalación:
pip install feedback-synthesis-mcpConfigura tu clave de billetera (cualquier billetera EVM con USDC en la red principal de Base):
export EVM_PRIVATE_KEY=your_private_key_hereAñadir a Claude Desktop — edita ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Añadir a Cursor — edita .cursor/mcp.json en la raíz de tu proyecto:
{
"mcpServers": {
"feedback-synthesis-mcp": {
"command": "feedback-synthesis-mcp",
"env": {
"EVM_PRIVATE_KEY": "your_private_key_here"
}
}
}
}Reinicia tu cliente. Ahora tienes cuatro herramientas de inteligencia de clientes disponibles.
Related MCP server: NPS Chatbot MCP Server
Herramienta | Qué hace | Precio |
| Síntesis de múltiples fuentes → grupos de problemas clasificados con evidencia | $0.05/llamada |
| Extracción rápida de puntos de dolor de una sola fuente | $0.02/llamada |
| Búsqueda de texto completo en elementos de feedback almacenados en caché | $0.01/llamada |
| Tendencias de sentimiento en series temporales a través de fuentes | $0.03/llamada |
Fuentes compatibles: Issues de GitHub, Hacker News, Reseñas de 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"
)Devuelve:
{
"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"
)Este MCP utiliza micropagos x402 en la red principal de Base (USDC). Necesitas:
Una billetera EVM con USDC en la red principal de Base
La clave privada de la billetera configurada como EVM_PRIVATE_KEY
Cada llamada cuesta entre $0.01 y $0.05 USDC. Los pagos se realizan automáticamente — sin suscripciones, sin claves API.
¿No hay pago configurado? El servidor devuelve un error útil con instrucciones de configuración.
Este paquete es un cliente MCP ligero. Todo el procesamiento ocurre en el backend alojado:
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 verificationEl código del servidor es privado (moat). El cliente ligero es de código abierto.
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.
