Skip to main content
Glama
teacat99

gl-mcp-feedback

by teacat99
OverviewSchemaRelated ServersScoreDiscussions
Hybrid

interactive_feedback

Present AI summaries, plans, or questions to the user via a Web UI and collect feedback or confirmation. Use this tool as the primary communication channel to wait for user input before proceeding.

Instructions

Open a Web UI to collect interactive feedback from the user.

This tool is the PRIMARY communication channel with the user. Route substantive content (analyses, plans, code summaries, questions needing confirmation) through this tool's summary parameter rather than the Cursor chat, because the Web UI renders Markdown far better.

MANDATORY call scenarios — do NOT end the turn without calling: 1. After any code modification — summarize the change, wait for the user to test. 2. Before implementing a new requirement — explain your understanding and approach, wait for confirmation. 3. When a tool call is cancelled/interrupted — ask the user the next step. 4. When this MCP call times out — immediately re-call; do not assume the user has left. 5. When the user explicitly skips without giving feedback — immediately re-call and ask why they skipped. 6. At the end of any multi-step task stage — check in. 7. Whenever you would otherwise ask the user a question in plain chat — route it through this tool's summary instead.

STRICT PROHIBITIONS: - While this tool is available, DO NOT invoke Cursor's built-in AskQuestion / question-picker tool. Every question to the user MUST go through this tool's summary (ask with a numbered list inside the Markdown). - DO NOT end your turn with a plain-text reply when you still have output intended for the user to read. Put that output into summary and call this tool instead. - Allowed parameters: project_directory, summary, title, timeout. title is OPTIONAL — pass a short headline (≤30 chars) for the Web UI's tab title and summary header. Names such as question, choices, options belong to AskQuestion — NEVER forward them to this tool. Passing any other keyword argument will cause the call to fail schema validation on the server.

Only stop calling when the user explicitly says 结束 / 不用了 / stop / done or an equivalent termination phrase.

summary writing rules: - Write in the same language the user is currently using. - Use Markdown: headings (##), lists, tables, code fences for snippets, bold for key decisions. - Include modified file paths, key trade-offs, and explicit questions for the user when applicable. - NEVER pass an empty string or the placeholder phrase 我已完成了您请求的任务。. The tool rejects such values at runtime and returns a correction notice that you must follow by re-calling with a real summary.

title writing rules: - Optional. Leave empty when summary is self-explanatory. - Keep concise (≤30 chars) — it's a headline, not a sentence. - Use the same language as the user. - Examples: 需要你提供更多信息 / 修复完成，请验证 / 实现方案确认 / Need more context.

Args: project_directory: Absolute or relative project path. Defaults to cwd. summary: Required. Markdown summary of the AI's current work / plan / question. No empty string, no placeholder phrase. title: Optional short headline shown in the Web UI tab and summary header. Leave empty if there's no concise headline. timeout: Seconds to wait for user feedback. Keep >= 600.

Returns: ToolResult: TextContent with the user's text feedback plus MCPImage objects for any uploaded images. An empty result means the user skipped — you MUST re-call this tool to ask why.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_directoryNoProject directory path..
summaryNoMarkdown summary of the AI's current work / plan / question, rendered in the Web UI. MUST be filled in with substantive content; empty strings and placeholder phrases (e.g. "我已完成了您请求的任务。") are rejected at runtime.
titleNoOptional short headline (max ~30 chars) for this feedback round, displayed in the browser tab and at the top of the AI summary panel. Should be concise (e.g. "需要你提供更多信息", "修复完成，请验证"). Leave empty when there's no good headline.
timeoutNoSeconds to wait for user feedback. Keep >= 600.

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden and transparently discloses all behavioral traits: it opens a Web UI, expects user feedback, requires re-calling on skip/timeout, rejects empty strings and placeholder phrases, and validates schema strictly. It also explains return format (TextContent with feedback and images) and failure cases.

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

Conciseness4/5

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

The description is long but well-structured with headings, numbered lists, and bold for emphasis. It front-loads the core purpose. While every sentence is informative, it could be more concise as some details (e.g., specific failure messages) are verbose. For the high information density, it earns a 4.

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

Completeness5/5

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

Given the tool has 4 parameters and no output schema, the description covers all necessary context: return type (TextContent with feedback images), empty result meaning skip, runtime rejection of empty summary, and schema validation failure on unknown params. It is complete for an interactive feedback tool.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds significant value: detailed 'summary' writing rules (language, Markdown, what to include, what to avoid), 'title' writing rules (optional, ≤30 chars, examples), 'timeout' minimum (≥600), and a warning against passing 'question'/'choices' etc. It also notes that passing unknown param names causes schema validation failure.

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

Purpose5/5

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

The description clearly states the tool opens a Web UI for collecting interactive feedback, and positions it as the PRIMARY communication channel. It distinguishes from the sibling tool 'get_system_info' by its role. The verb 'open' and resource 'Web UI to collect interactive feedback' are specific and unambiguous.

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

Usage Guidelines5/5

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

The description provides extensive, explicit when-to-use and when-not-to-use guidelines. It lists seven mandatory call scenarios, strict prohibitions (e.g., not using AskQuestion or ending with plain text), and a termination condition. It also names the alternative 'AskQuestion' and explicitly instructs to route questions through this tool instead.

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

Install Server

Other Tools

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/teacat99/gl-mcp-feedback'

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