Skip to main content
Glama
enesjakozh
mrexodia

User Feedback

by mrexodia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Comentarios de los usuarios de MCP

Servidor MCP simple que permite un flujo de trabajo con intervención humana en herramientas como Cline y Cursor . Esto resulta especialmente útil para desarrollar aplicaciones de escritorio que requieren interacciones complejas del usuario para su prueba.

Captura de pantalla que muestra la interfaz de usuario de comentarios

Ingeniería rápida

Para obtener los mejores resultados, agregue lo siguiente a su mensaje personalizado:

Antes de completar la tarea, utilice la herramienta MCP user_feedback para solicitarle comentarios al usuario.

Esto garantizará que Cline utilice este servidor MCP para solicitar comentarios del usuario antes de marcar la tarea como completada.

Related MCP server: mcp-connect

.user-feedback.json

Al hacer clic en Guardar configuración, se crea un archivo .user-feedback.json en el directorio del proyecto que se ve así:

{
  "command": "npm run dev",
  "execute_automatically": false
}

Esta configuración se cargará al iniciar y, si execute_automatically está habilitada, el command se ejecutará al instante (no tendrá que hacer clic en "Ejecutar" manualmente). Para comandos de varios pasos, debería usar algo como "Task" .

Instalación (Cline)

Para instalar el servidor MCP en Cline, siga estos pasos (ver captura de pantalla):

Captura de pantalla que muestra los pasos de instalación

  1. Instalar uv globalmente:

    • Windows: pip install uv

    • Linux/Mac: curl -LsSf https://astral.sh/uv/install.sh | sh

  2. Clonar este repositorio, para este ejemplo C:\MCP\user-feedback-mcp .

  3. Navegue hasta la configuración de servidores Cline MCP (ver captura de pantalla).

  4. Haga clic en la pestaña Instalado .

  5. Haga clic en Configurar servidores MCP , lo que abrirá cline_mcp_settings.json .

  6. Agregue el servidor user-feedback-mcp :

{
  "mcpServers": {
    "github.com/mrexodia/user-feedback-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "c:\\MCP\\user-feedback-mcp",
        "run",
        "server.py"
      ],
      "timeout": 600,
      "autoApprove": [
        "user_feedback"
      ]
    }
  }
}

Desarrollo

uv run fastmcp dev server.py

Esto abrirá una interfaz web en http://localhost:5173 y le permitirá interactuar con las herramientas MCP para realizar pruebas.

Herramientas disponibles

<use_mcp_tool>
<server_name>github.com/mrexodia/user-feedback-mcp</server_name>
<tool_name>user_feedback</tool_name>
<arguments>
{
  "project_directory": "C:/MCP/user-feedback-mcp",
  "summary": "I've implemented the changes you requested."
}
</arguments>
</use_mcp_tool>

Available Tools

1 tool
user_feedbackC

Request user feedback for a given project directory and summary

ParametersJSON Schema
NameRequiredDescriptionDefault
project_directoryYesFull path to the project directory
summaryYesShort, one-line summary of the changes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'requests' feedback but doesn't explain how this is done (e.g., via UI prompt, email, logging), what permissions are needed, whether it's interactive or automated, or what happens after the request. This leaves critical behavioral aspects unspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how feedback is requested or what the tool returns, leaving gaps in understanding the tool's operation and results. This is inadequate for a tool with potential complexity in feedback mechanisms.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for both parameters (project directory path and summary). The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Request user feedback') and specifies the target ('for a given project directory and summary'), making the purpose understandable. However, it doesn't distinguish from siblings since none exist, and 'request' could be interpreted as initiating a feedback collection process rather than retrieving existing feedback, which is somewhat ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool, such as the context for requesting feedback, prerequisites, or alternatives. With no sibling tools, this isn't a major issue, but it lacks any usage context, leaving the agent to infer appropriate scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • First observeduser_feedback
Deploy Server
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

B3.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'user_feedback' has a singular, clear purpose, so an agent cannot misselect among alternatives.

Naming Consistency5/5

The single tool name 'user_feedback' follows a consistent snake_case pattern. Since there is only one tool, there is no inconsistency in naming conventions to evaluate.

Tool Count2/5

A single tool is too few for most server purposes, as it limits functionality and suggests a thin or incomplete surface. For a server named 'User Feedback', one tool may not adequately cover potential operations like viewing, managing, or analyzing feedback.

Completeness2/5

The tool set is severely incomplete for a 'User Feedback' domain. It only provides a way to request feedback, missing essential operations such as retrieving, updating, deleting, or listing feedback, which are necessary for a full CRUD lifecycle.

Maintenance

ActivityInactive
ResponsivenessResponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches