Skip to main content
Glama
enesjakozh
mrexodia

User Feedback

by mrexodia
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

사용자 피드백 MCP

Cline 및 Cursor 와 같은 도구에서 휴먼 인더 루프(Human-in-the-Loop) 워크플로를 구현하는 간단한 MCP 서버입니다 . 특히 복잡한 사용자 상호작용을 테스트해야 하는 데스크톱 애플리케이션 개발에 유용합니다.

피드백 UI를 보여주는 스크린샷

신속한 엔지니어링

최상의 결과를 얻으려면 사용자 지정 프롬프트에 다음을 추가하세요.

작업을 완료하기 전에 user_feedback MCP 도구를 사용하여 사용자에게 피드백을 요청하세요.

이렇게 하면 클라인이 작업을 완료로 표시하기 전에 이 MCP 서버를 사용하여 사용자 피드백을 요청할 수 있습니다.

Related MCP server: mcp-connect

.user-feedback.json

구성 저장을 클릭하면 프로젝트 디렉토리에 다음과 같은 .user-feedback.json 파일이 생성됩니다.

지엑스피1

이 구성은 시작 시 로드되며, execute_automatically 활성화되어 있으면 command 즉시 실행됩니다( 실행을 수동으로 클릭할 필요가 없습니다). 여러 단계로 구성된 명령의 경우 Task 와 같은 것을 사용해야 합니다.

설치(클라인)

클라인에 MCP 서버를 설치하려면 다음 단계를 따르세요(스크린샷 참조):

설치 단계를 보여주는 스크린샷

  1. uv를 전역적으로 설치합니다.

    • 윈도우: pip install uv

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

  2. 이 저장소를 복제합니다(예 C:\MCP\user-feedback-mcp .

  3. Cline MCP 서버 구성으로 이동합니다(스크린샷 참조).

  4. 설치됨 탭을 클릭합니다.

  5. MCP 서버 구성을 클릭하면 cline_mcp_settings.json 이 열립니다.

  6. 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"
      ]
    }
  }
}

개발

uv run fastmcp dev server.py

이렇게 하면 http://localhost:5173 에서 웹 인터페이스가 열리고 테스트를 위해 MCP 도구와 상호 작용할 수 있습니다.

사용 가능한 도구

<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