Skip to main content
Glama
youjunxiaji

gl-mcp-feedback

by youjunxiaji

interactive_feedback

Collects interactive user feedback via a Web UI, enabling AI agents to present summaries or questions, wait for confirmations, and receive additional instructions.

Instructions

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

This tool is the PRIMARY communication channel with the user. The full list of "when to call" scenarios lives in the project's gl-mcp-feedback user rules; this docstring only covers the runtime contract that the tool itself enforces.

Strict prohibitions: - While this tool is available, DO NOT invoke Cursor's built-in AskQuestion. Route every question through summary as a numbered list. - DO NOT end the turn with a plain-text reply when there is substantive content for the user to read. Put it in summary. - When the user skips without feedback, re-call this tool to ask why; only stop on explicit termination (结束 / 不用了 / stop / done). - Allowed parameters: project_directory, summary, timeout, plus conversation_id, which a Cursor hook fills in: never set it yourself. Names like question / choices / options belong to AskQuestion and will fail schema validation here.

summary writing rules: - Markdown: headings (##), lists, tables, code fences, bold for key decisions. Include modified file paths and explicit questions when applicable. - NEVER pass an empty string or the placeholder phrase 我已完成了您请求的任务。 — runtime validation rejects them and you must re-call with a real summary.

Queued messages: While you work between two calls, the user can keep typing in the Web UI; those messages are queued (at most 3) and reach you in one of two ways, both under a header starting with (你工作期间,用户追加了 N 条消息:

- After any tool call, a Cursor hook appends the queue to that
  tool's result. Images are saved as local files whose paths are
  listed in the block: open them with ``Read``.
- On your next call to this tool, the queue is returned
  immediately, without waiting for a new reply.

Either way they are NOT an answer to the ``summary`` you just
passed: treat them as new instructions in the given order, act on
them, then call this tool again.

Args: project_directory: Absolute or relative project path. Defaults to cwd. summary: Required Markdown summary. No empty string, no placeholder. timeout: Seconds to wait for user feedback. Values above 600 are capped, so always pass 600. conversation_id: Filled in by a Cursor hook. Never set it yourself.

Returns: ToolResult: TextContent with the user's text feedback plus MCPImage objects for any uploaded images. An empty result means the user skipped — re-call to ask why. A result starting with [interactive_feedback TIMEOUT] means the user has not replied within the wait limit — re-call to keep waiting.

Input Schema

NameRequiredDescriptionDefault
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.
timeoutNoSeconds to wait for user feedback. Values above 600 are capped, so always pass 600.
conversation_idNoFilled in automatically by a Cursor hook to identify the conversation. NEVER set this yourself; always leave it empty.
project_directoryNoProject directory path..

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.2
    • changedInput schema / properties / timeout / description
      Previous value: -"Seconds to wait for user feedback. Keep >= 600."New value: +"Seconds to wait for user feedback. Values above 600 are capped, so always pass 600."
  2. Changed2 schema fields changedv3.0.1
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "default": "",
      +  "description": "Filled in automatically by a Cursor hook to identify the conversation. NEVER set this yourself; always leave it empty.",
      +  "type": "string"
      +}
    • removedInput schema / properties / title
      Removed value: -{
      -  "default": "",
      -  "description": "Optional 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.",
      -  "type": "string"
      -}
  3. First observedv2.2.3

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: it discloses runtime validation that rejects empty/placeholder summaries, the 600s timeout cap, that conversation_id is hook-injected, and the queued-message behaviour (max 3, delivered via hook result or next call). It also documents the exact return shapes — empty result = skipped, '[interactive_feedback TIMEOUT]' prefix = no reply — which is precisely the behavioural context an agent needs to drive the retry loop.

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?

Well front-loaded — purpose first, then prohibitions, then summary rules, then queue semantics, then Args/Returns. The one deduction is redundancy: the timeout cap and the summary-validation rule are each stated twice, and the Args section duplicates schema descriptions word for word, costing length without new information.

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?

For a tool with no output schema and no annotations, this covers everything: how to write the argument, what the return value looks like in all three outcomes (feedback, skip, timeout), and how out-of-band user messages arrive mid-loop. Nothing an agent needs to invoke it correctly and react to results is missing.

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

Parameters4/5

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

Schema coverage is 100%, so a 3 would be the floor, but the description adds genuine value beyond the schema: it warns that names like question/choices/options will fail schema validation here, which prevents a likely mis-call from prior AskQuestion habit. The Args block otherwise restates the schema descriptions almost verbatim (cwd default, timeout cap).

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?

States a specific verb and resource ('Open a Web UI to collect interactive feedback from the user') and immediately stakes out the role as the PRIMARY user-communication channel. It explicitly distinguishes itself from a near-alternative ('DO NOT invoke Cursor's built-in AskQuestion'), so an agent knows exactly what this tool is and is not.

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

Usage Guidelines4/5

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

Gives unusually concrete routing rules: use this instead of AskQuestion, never end the turn with plain text when there is substantive content, re-call after a skip, re-call after a TIMEOUT. The residual gap is that the full 'when to call' scenario list is deferred to external gl-mcp-feedback user rules, so the positive trigger conditions are not fully self-contained.

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

Deploy Server

Other Tools