Skip to main content
Glama
ceciliomichael

Feedback Collector MCP

Feedback Collector MCP Tool

Collect user feedback with text and image support through an Electron app.

Quick Setup

  1. Clone repository:

git clone https://github.com/ceciliomichael/feedback-js.git
cd feedbackjs-mcp
  1. Install dependencies:

npm install
  1. Build the application:

npm run make

Related MCP server: MCP Feedback Collector

Cross-Platform Building

The app can be built for Windows, macOS, and Linux platforms:

# Build for the current platform only
npm run make

# Build for specific platforms
npm run make:win    # Windows only
npm run make:mac    # macOS only
npm run make:linux  # Linux only

# Build for all platforms
npm run make:all

Note: Building for macOS from Windows or Linux requires additional setup:

  • For code signing, you need an Apple Developer account

  • For proper macOS builds from non-macOS platforms, consider using a CI service like GitHub Actions

MCP Configuration

Add to your AI tool configuration (works with Claude Desktop, Cursor, and other MCP clients):

{
  "mcpServers": {
    "feedback-collector": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-server.js"]
    }
  }
}

Tool Parameters

Parameter

Type

Description

Default

prompt

string

Message to display

"Please provide feedback"

title

string

Window title

"AI Feedback Collection"

time_format

enum

Time format (full, iso, date, time, unix)

"full"

timezone

string

Timezone

Local timezone

Features

  • Text feedback with markdown prompt support

  • Image uploads (file selection, drag-and-drop, clipboard paste)

  • Quick response buttons (Submit, Approve, Enough, Cancel)

  • Detailed time information

Available Tools

1 tool
collect_feedbackB

Collect feedback from the user through an Electron app

ParametersJSON Schema
NameRequiredDescriptionDefault
promptNoThe message to display to the user in the feedback windowPlease provide your feedback or describe your issue:
time_formatNoThe format for time informationfull
timezoneNoThe timezone to use (defaults to local)
titleNoThe title of the feedback windowAI Feedback Collection

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the interface (Electron app) but doesn't disclose critical traits like whether this blocks execution, requires user interaction, handles errors, or what happens to collected feedback. For a user-interactive tool with zero annotation coverage, this leaves significant gaps.

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 with zero wasted words. It's appropriately sized for a tool with good schema coverage and no siblings, front-loading the core purpose without unnecessary elaboration.

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

Completeness3/5

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

Given the tool's moderate complexity (user interaction via GUI) and 100% schema coverage but no annotations or output schema, the description is minimally adequate. It identifies the interface but lacks details on behavioral expectations, error handling, or result format, leaving the agent to infer much about how this tool actually operates.

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%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where structured data handles parameter documentation adequately.

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 ('collect feedback') and target ('from the user'), specifying it occurs 'through an Electron app' which adds useful context about the interface. However, it doesn't distinguish from siblings (none exist) and could be more specific about what type of feedback or how it's collected.

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?

No guidance is provided on when to use this tool versus alternatives, prerequisites, or constraints. The description mentions the Electron app context but doesn't explain when this collection method is appropriate or what scenarios warrant its use.

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

TDQS

B3.2/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The single tool 'collect_feedback' has a clearly distinct purpose that cannot be mistaken for any other tool in this server.

Naming Consistency5/5

The single tool name 'collect_feedback' follows a clear verb_noun pattern. With only one tool, there is no inconsistency in naming conventions to evaluate, making it perfectly consistent.

Tool Count2/5

A single tool is too few for most server purposes, as it limits functionality and suggests a thin or incomplete implementation. While it might be appropriate for a very narrow scope, it generally feels insufficient for robust agent interaction.

Completeness1/5

The server appears to be for collecting feedback, but with only a collection tool, there are severe gaps: no tools for viewing, analyzing, updating, or managing feedback. This makes the surface severely incomplete for any meaningful feedback management workflow.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    C
    quality
    D
    maintenance
    Enables collecting contextual user input through a dedicated Electron window interface. Supports drawable image input and other input types, allowing MCP clients to request interactive user submissions.
    1
    21
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to collect interactive user feedback through a modern GUI that supports text input, multiple image uploads (via file selection or clipboard paste), allowing users to provide comprehensive feedback with screenshots and comments.
    1
    MIT
  • F
    license
    A
    quality
    B
    maintenance
    Interactive feedback server for AI-assisted development with Web UI and desktop app support, enabling user feedback collection after AI tasks.
    2

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ceciliomichael/feedbackjs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server