Skip to main content
Glama

Interactive Feedback (人机协作反馈)

interactive_feedback

Ask a human for decisions, clarifications, or sign-off via a Web UI when next steps have multiple options or irreversible effects; blocks until they reply.

Instructions

Ask the human user for interactive feedback through the Web UI.

Use this tool whenever you need a human decision, clarification, confirmation, plan approval, design review, or final sign-off before continuing — especially when the next step has multiple valid approaches, irreversible side effects, or significant trade-offs.

Behavior:

  • Renders the resolved message (Markdown) and an optional list of options in a Web UI; the user submits text + selected options + optional images.

  • The call blocks until the user submits, the auto-resubmit countdown expires, or the configured backend timeout is reached.

  • On success, returns a list of MCP content blocks (text + image) that include the user reply, selected options, and an optional prompt suffix.

  • On parameter validation failure, raises ToolError so the agent can retry with corrected arguments. On service / task failure, returns a configurable resubmit prompt instructing the agent to call this tool again, instead of silently dropping the request. After 3 failures in a row it returns the cause instead: stop calling and tell the user.

Cross-tool compatibility:

  • summary / prompt are accepted as aliases for message so the same mcp.json config can target other feedback MCP variants without retraining the agent.

  • options is an alias for predefined_options.

  • project_directory, submit_button_text, timeout, timeout_seconds, feedback_type, priority, language, tags, user_id, task_id are accepted but ignored. They prevent the first-call validation failures observed when an agent reuses arguments shaped for a different feedback MCP server.

Input Schema

NameRequiredDescriptionDefault
tagsNoAccepted for compatibility; ignored by this server.
promptNoCompatibility alias for `message`. Ignored when `message` is provided.
loop_idNoLoop engineering: optional stable identifier shared by every feedback round that belongs to the same goal / outer loop (agent-chosen, e.g. 'auth-refactor-2026-07'). Rounds that carry the same loop_id are grouped in the server's loop ledger (GET /api/loops), which records 'which rounds did this objective go through, and what was decided each time'. The page itself does not display it. Length: clamped to 64 characters server-side. Omit for standalone one-shot questions (default behavior unchanged).
messageNoQuestion, summary, or proposal to display to the human user. MUST be a non-empty string. Supports CommonMark / GitHub-Flavored Markdown (headings, lists, tables, fenced code blocks, links, inline code). To show a screenshot or chart that lives on this machine, embed it as a Markdown image whose destination is the file path, e.g. `![chart](/abs/path/chart.png)` or a path relative to the workspace: png/jpg/gif/webp/bmp/avif files inside the workspace or the temp directory are displayed (max 8 per message, 8 MB each); any other local path is replaced by a short note and never read. Recommended length: 1-2000 characters; soft cap 1,000,000 characters (~1 MB UTF-8); inputs longer than the cap are truncated with a trailing ellipsis marker. Best practices: (1) state the question clearly in the first line; (2) include the recommended/default answer when proposing options; (3) escape special characters properly in JSON (use \" for quotes, \n for newlines). If omitted, the server falls back to `summary` or `prompt` for cross-tool compatibility.
optionsNoCompatibility alias for `predefined_options`. Ignored when `predefined_options` is provided.
summaryNoCompatibility alias for `message` (used by noopstudios/Minidoracat interactive-feedback-mcp variants). Ignored when `message` is provided.
task_idNoAccepted for compatibility (some agents pre-generate a trace ID and pass it through); this server always auto-generates an internal task ID and ignores the externally supplied value. Useful when the same `mcp.json` config also points at MCP variants that *do* honour an externally supplied task ID.
timeoutNoAccepted for compatibility; this server uses its own configured backend timeout and auto-resubmit countdown.
user_idNoAccepted for compatibility; ignored by this server.
languageNoAccepted for compatibility; UI language follows the user's saved settings.
priorityNoAccepted for compatibility; ignored by this server.
loop_phaseNoLoop engineering: optional free-form phase tag for this round, e.g. 'investigate' / 'implement' / 'verify' / 'review'. Stored with the task and the loop ledger, not displayed on the page. Length: clamped to 32 characters server-side.
header_labelNoOptional short chip / tag rendered above the prompt in the task pane to give a one-word context cue (e.g. 'Auth', 'DB', 'Layout', 'CSS', 'i18n'). Length: clamped to 16 characters server-side; single-word recommendation, no spaces if avoidable. Especially useful in multi-task mode where the user juggles 3+ concurrent feedback requests — the chip lets them visually distinguish task domains at a glance. If omitted or empty, no chip is shown (default existing layout).
feedback_typeNoAccepted for compatibility; ignored by this server.
loop_objectiveNoLoop engineering: optional one-sentence description of the loop's goal (e.g. 'Migrate auth/session.py to PyJWT 2.x with green integration tests'). Pass it on the first round of a loop_id; later rounds may omit it. Stored with the task and the loop ledger, not displayed on the page. Length: clamped to 500 characters server-side.
iteration_labelNoLoop engineering: optional round label such as 'iter-3' or 'attempt-2'. Shown as a small badge on the task's tab so multiple rounds of the same loop are distinguishable at a glance. Length: clamped to 32 characters server-side.
timeout_secondsNoCompatibility alias for `timeout` (used by some MCP clients that explicitly suffix the unit). Both fields are accepted for compatibility — this server ignores them and uses its own configured backend timeout / auto-resubmit countdown. When both are provided, this server logs a debug line and discards both, since neither overrides server config.
success_criteriaNoLoop engineering: optional verifiable completion criteria the human should judge the evidence against (e.g. 'pytest all green + no new ruff warnings + docs regenerated'). Stored with the task and the loop ledger but not displayed on the page, so put anything the human must read in `message`. Length: clamped to 500 characters server-side.
project_directoryNoAccepted for compatibility with other feedback MCP variants; this server ignores it (project context is taken from the running Web UI / config).
predefined_optionsNoOptional list of predefined choices the user can pick from (rendered as multi-select checkboxes alongside a free-text reply). Two canonical input shapes (the older parallel-array shape `predefined_options_defaults` has been removed; use the dict form below to mark recommended options): (a) **RECOMMENDED** list[dict] of shape {"label": str, "default": bool} — mark the recommended option with `default: true` so the UI shows a pre-checked checkbox (field aliases accepted: "label"/"text"/"value", "default"/"selected"/"checked"); (b) list[str] — simple labels, all initially unchecked (use this when no recommendation is needed). Non-string and non-{label,...} items are silently dropped. Each option max length: 10000 characters (longer items truncated). Tips: (1) keep options short, action-oriented and mutually distinguishable; (2) PREFER the dict form for ANY recommended option — `{"label": "Apply", "default": true}`. The UI renders real pre-checked checkboxes, so do NOT use text-prefix hacks (adding marker words to the label) for marking recommendations; (3) the user may also ignore options and reply with free text. If omitted, the server falls back to `options` for cross-tool compatibility.
submit_button_textNoAccepted for compatibility; this server uses its own UI labels.
feedback_placeholderNoOptional textarea placeholder hint shown to the user when waiting for free-text feedback. Per-task override of the global ``page.feedbackPlaceholder`` i18n string. Examples: 'Paste the error stack trace', 'Describe the visual glitch', 'Reply 'ok' to approve or 'no' + reason to reject'. Length: clamped to 200 characters server-side (single-line placeholders only; longer text is silently truncated and the tool result does not report it). If omitted or empty, the UI uses its default i18n placeholder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.9.1
    • changedInput schema / properties / iteration_label / description
      Previous value: -"Loop engineering: optional round label such as 'iter-3' or 'attempt-2'. Shown with the loop context so multiple rounds of the same loop are distinguishable at a glance. Length: clamped to 32 characters server-side."New value: +"Loop engineering: optional round label such as 'iter-3' or 'attempt-2'. Shown as a small badge on the task's tab so multiple rounds of the same loop are distinguishable at a glance. Length: clamped to 32 characters server-side."
    • changedInput schema / properties / loop_id / description
      Previous value: -"Loop engineering: optional stable identifier shared by every feedback round that belongs to the same goal / outer loop (agent-chosen, e.g. 'auth-refactor-2026-07'). Rounds that carry the same loop_id are grouped in the UI so the human reviewer can replay 'which rounds did this objective go through, and what was decided each time'. Length: clamped to 64 characters server-side. Omit for standalone one-shot questions (default behavior unchanged)."New value: +"Loop engineering: optional stable identifier shared by every feedback round that belongs to the same goal / outer loop (agent-chosen, e.g. 'auth-refactor-2026-07'). Rounds that carry the same loop_id are grouped in the server's loop ledger (GET /api/loops), which records 'which rounds did this objective go through, and what was decided each time'. The page itself does not display it. Length: clamped to 64 characters server-side. Omit for standalone one-shot questions (default behavior unchanged)."
    • changedInput schema / properties / loop_objective / description
      Previous value: -"Loop engineering: optional one-sentence description of the loop's goal (e.g. 'Migrate auth/session.py to PyJWT 2.x with green integration tests'). Pass it on the first round of a loop_id; later rounds may omit it. Shown to the reviewer as loop context above the prompt. Length: clamped to 500 characters server-side."New value: +"Loop engineering: optional one-sentence description of the loop's goal (e.g. 'Migrate auth/session.py to PyJWT 2.x with green integration tests'). Pass it on the first round of a loop_id; later rounds may omit it. Stored with the task and the loop ledger, not displayed on the page. Length: clamped to 500 characters server-side."
    • changedInput schema / properties / loop_phase / description
      Previous value: -"Loop engineering: optional free-form phase tag for this round, e.g. 'investigate' / 'implement' / 'verify' / 'review'. Helps the reviewer see where in the inner loop the agent currently is. Length: clamped to 32 characters server-side."New value: +"Loop engineering: optional free-form phase tag for this round, e.g. 'investigate' / 'implement' / 'verify' / 'review'. Stored with the task and the loop ledger, not displayed on the page. Length: clamped to 32 characters server-side."
    • changedInput schema / properties / success_criteria / description
      Previous value: -"Loop engineering: optional verifiable completion criteria the human should judge the evidence against (e.g. 'pytest all green + no new ruff warnings + docs regenerated'). Rendered alongside the loop context so the verdict is made against an explicit baseline. Length: clamped to 500 characters server-side."New value: +"Loop engineering: optional verifiable completion criteria the human should judge the evidence against (e.g. 'pytest all green + no new ruff warnings + docs regenerated'). Stored with the task and the loop ledger but not displayed on the page, so put anything the human must read in `message`. Length: clamped to 500 characters server-side."
  2. Changed5 schema fields changedv1.9.0
    • changedInput schema / properties / feedback_placeholder / description
      Previous value: -"Optional textarea placeholder hint shown to the user when waiting for free-text feedback. Per-task override of the global ``page.feedbackPlaceholder`` i18n string. Examples: 'Paste the error stack trace', 'Describe the visual glitch', 'Reply 'ok' to approve or 'no' + reason to reject'. Length: clamped to 200 characters server-side (single-line placeholders only; longer text is silently truncated; the response includes ``placeholder_truncated: true`` + ``placeholder_original_length`` + ``placeholder_max_length`` when clamping activates so callers can warn). If omitted or empty, the UI uses its default i18n placeholder. (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user`` schema.)"New value: +"Optional textarea placeholder hint shown to the user when waiting for free-text feedback. Per-task override of the global ``page.feedbackPlaceholder`` i18n string. Examples: 'Paste the error stack trace', 'Describe the visual glitch', 'Reply 'ok' to approve or 'no' + reason to reject'. Length: clamped to 200 characters server-side (single-line placeholders only; longer text is silently truncated and the tool result does not report it). If omitted or empty, the UI uses its default i18n placeholder."
    • changedInput schema / properties / header_label / description
      Previous value: -"Optional short chip / tag rendered above the prompt in the task pane to give a one-word context cue (e.g. 'Auth', 'DB', 'Layout', 'CSS', 'i18n'). Length: clamped to 16 characters server-side; single-word recommendation, no spaces if avoidable. Especially useful in multi-task mode where the user juggles 3+ concurrent feedback requests — the chip lets them visually distinguish task domains at a glance. If omitted or empty, no chip is shown (default existing layout). (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user.header`` schema.)"New value: +"Optional short chip / tag rendered above the prompt in the task pane to give a one-word context cue (e.g. 'Auth', 'DB', 'Layout', 'CSS', 'i18n'). Length: clamped to 16 characters server-side; single-word recommendation, no spaces if avoidable. Especially useful in multi-task mode where the user juggles 3+ concurrent feedback requests — the chip lets them visually distinguish task domains at a glance. If omitted or empty, no chip is shown (default existing layout)."
    • changedInput schema / properties / message / description
      Previous value: -"Question, summary, or proposal to display to the human user. MUST be a non-empty string. Supports CommonMark / GitHub-Flavored Markdown (headings, lists, tables, fenced code blocks, links, inline code). Recommended length: 1-2000 characters; soft cap 1,000,000 characters (~1 MB UTF-8, R166); inputs longer than the cap are truncated with a trailing ellipsis marker. Best practices: (1) state the question clearly in the first line; (2) include the recommended/default answer when proposing options; (3) escape special characters properly in JSON (use \\\" for quotes, \\n for newlines). If omitted, the server falls back to `summary` or `prompt` for cross-tool compatibility."New value: +"Question, summary, or proposal to display to the human user. MUST be a non-empty string. Supports CommonMark / GitHub-Flavored Markdown (headings, lists, tables, fenced code blocks, links, inline code). To show a screenshot or chart that lives on this machine, embed it as a Markdown image whose destination is the file path, e.g. `![chart](/abs/path/chart.png)` or a path relative to the workspace: png/jpg/gif/webp/bmp/avif files inside the workspace or the temp directory are displayed (max 8 per message, 8 MB each); any other local path is replaced by a short note and never read. Recommended length: 1-2000 characters; soft cap 1,000,000 characters (~1 MB UTF-8); inputs longer than the cap are truncated with a trailing ellipsis marker. Best practices: (1) state the question clearly in the first line; (2) include the recommended/default answer when proposing options; (3) escape special characters properly in JSON (use \\\" for quotes, \\n for newlines). If omitted, the server falls back to `summary` or `prompt` for cross-tool compatibility."
    • changedInput schema / properties / predefined_options / description
      Previous value: -"Optional list of predefined choices the user can pick from (rendered as multi-select checkboxes alongside a free-text reply). Two canonical input shapes (v1.6.0+ — the legacy parallel-array shape `predefined_options_defaults` was removed in R167; use the dict form below to mark recommended options): (a) **RECOMMENDED** list[dict] of shape {\"label\": str, \"default\": bool} — mark the recommended option with `default: true` so the UI shows a pre-checked checkbox (field aliases accepted: \"label\"/\"text\"/\"value\", \"default\"/\"selected\"/\"checked\"); (b) list[str] — simple labels, all initially unchecked (use this when no recommendation is needed). Non-string and non-{label,...} items are silently dropped. Each option max length: 10000 characters (longer items truncated). Tips: (1) keep options short, action-oriented and mutually distinguishable; (2) PREFER the dict form for ANY recommended option — `{\"label\": \"Apply\", \"default\": true}`. The UI renders real pre-checked checkboxes, so do NOT use text-prefix hacks (adding marker words to the label) for marking recommendations; (3) the user may also ignore options and reply with free text. If omitted, the server falls back to `options` for cross-tool compatibility."New value: +"Optional list of predefined choices the user can pick from (rendered as multi-select checkboxes alongside a free-text reply). Two canonical input shapes (the older parallel-array shape `predefined_options_defaults` has been removed; use the dict form below to mark recommended options): (a) **RECOMMENDED** list[dict] of shape {\"label\": str, \"default\": bool} — mark the recommended option with `default: true` so the UI shows a pre-checked checkbox (field aliases accepted: \"label\"/\"text\"/\"value\", \"default\"/\"selected\"/\"checked\"); (b) list[str] — simple labels, all initially unchecked (use this when no recommendation is needed). Non-string and non-{label,...} items are silently dropped. Each option max length: 10000 characters (longer items truncated). Tips: (1) keep options short, action-oriented and mutually distinguishable; (2) PREFER the dict form for ANY recommended option — `{\"label\": \"Apply\", \"default\": true}`. The UI renders real pre-checked checkboxes, so do NOT use text-prefix hacks (adding marker words to the label) for marking recommendations; (3) the user may also ignore options and reply with free text. If omitted, the server falls back to `options` for cross-tool compatibility."
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "items": {},
      -      "type": "array"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "type": "object",
      -  "x-fastmcp-wrap-result": true
      -}New value: +null
  3. Changed1 schema field changedv1.8.12
    • removedInput schema / properties / question_type
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Optional UI mode hint: when ``'yesno'``, the frontend hides the free-text textarea and renders a single-row Yes/No button pair. User's click submits the literal string 'yes' or 'no' as the feedback result — saves typing + Submit-button click for binary decisions (approve/reject, proceed/abort, etc.). Allowed values: ``'yesno'`` (current) or ``None`` (default: keep textarea + optional ``predefined_options`` checkboxes). Unknown values silently treated as None (forward-compat for future types like ``'choice'`` / ``'rating'`` once the frontend supports them). (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user`` schema.)"
      -}
  4. Changed5 schema fields changedv1.8.3
    • addedInput schema / properties / iteration_label
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Loop engineering: optional round label such as 'iter-3' or 'attempt-2'. Shown with the loop context so multiple rounds of the same loop are distinguishable at a glance. Length: clamped to 32 characters server-side."
      +}
    • addedInput schema / properties / loop_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Loop engineering: optional stable identifier shared by every feedback round that belongs to the same goal / outer loop (agent-chosen, e.g. 'auth-refactor-2026-07'). Rounds that carry the same loop_id are grouped in the UI so the human reviewer can replay 'which rounds did this objective go through, and what was decided each time'. Length: clamped to 64 characters server-side. Omit for standalone one-shot questions (default behavior unchanged)."
      +}
    • addedInput schema / properties / loop_objective
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Loop engineering: optional one-sentence description of the loop's goal (e.g. 'Migrate auth/session.py to PyJWT 2.x with green integration tests'). Pass it on the first round of a loop_id; later rounds may omit it. Shown to the reviewer as loop context above the prompt. Length: clamped to 500 characters server-side."
      +}
    • addedInput schema / properties / loop_phase
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Loop engineering: optional free-form phase tag for this round, e.g. 'investigate' / 'implement' / 'verify' / 'review'. Helps the reviewer see where in the inner loop the agent currently is. Length: clamped to 32 characters server-side."
      +}
    • addedInput schema / properties / success_criteria
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Loop engineering: optional verifiable completion criteria the human should judge the evidence against (e.g. 'pytest all green + no new ruff warnings + docs regenerated'). Rendered alongside the loop context so the verdict is made against an explicit baseline. Length: clamped to 500 characters server-side."
      +}
  5. Changed3 schema fields changedv1.7.13
    • addedInput schema / properties / feedback_placeholder
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional textarea placeholder hint shown to the user when waiting for free-text feedback. Per-task override of the global ``page.feedbackPlaceholder`` i18n string. Examples: 'Paste the error stack trace', 'Describe the visual glitch', 'Reply 'ok' to approve or 'no' + reason to reject'. Length: clamped to 200 characters server-side (single-line placeholders only; longer text is silently truncated; the response includes ``placeholder_truncated: true`` + ``placeholder_original_length`` + ``placeholder_max_length`` when clamping activates so callers can warn). If omitted or empty, the UI uses its default i18n placeholder. (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user`` schema.)"
      +}
    • addedInput schema / properties / header_label
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional short chip / tag rendered above the prompt in the task pane to give a one-word context cue (e.g. 'Auth', 'DB', 'Layout', 'CSS', 'i18n'). Length: clamped to 16 characters server-side; single-word recommendation, no spaces if avoidable. Especially useful in multi-task mode where the user juggles 3+ concurrent feedback requests — the chip lets them visually distinguish task domains at a glance. If omitted or empty, no chip is shown (default existing layout). (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user.header`` schema.)"
      +}
    • addedInput schema / properties / question_type
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional UI mode hint: when ``'yesno'``, the frontend hides the free-text textarea and renders a single-row Yes/No button pair. User's click submits the literal string 'yes' or 'no' as the feedback result — saves typing + Submit-button click for binary decisions (approve/reject, proceed/abort, etc.). Allowed values: ``'yesno'`` (current) or ``None`` (default: keep textarea + optional ``predefined_options`` checkboxes). Unknown values silently treated as None (forward-compat for future types like ``'choice'`` / ``'rating'`` once the frontend supports them). (mining-cycle-3 §2.1 — borrowed from gemini-cli ``ask_user`` schema.)"
      +}
  6. Addedv1.6.3
  7. Removedv1.6.2
  8. Changed20 schema fields changedv1.6.0
    • addedInput schema / properties / feedback_type
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; ignored by this server."
      +}
    • addedInput schema / properties / language
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; UI language follows the user's saved settings."
      +}
    • addedInput schema / properties / message / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / message / default
      Added value: +null
    • changedInput schema / properties / message / description
      Previous value: -"向用户展示的具体问题/提示(支持 Markdown)"New value: +"Question, summary, or proposal to display to the human user. MUST be a non-empty string. Supports CommonMark / GitHub-Flavored Markdown (headings, lists, tables, fenced code blocks, links, inline code). Recommended length: 1-2000 characters; hard limit 10000 (longer input is truncated). Best practices: (1) state the question clearly in the first line; (2) include the recommended/default answer when proposing options; (3) escape special characters properly in JSON (use \\\" for quotes, \\n for newlines). If omitted, the server falls back to `summary` or `prompt` for cross-tool compatibility."
    • removedInput schema / properties / message / type
      Removed value: -"string"
    • addedInput schema / properties / options
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {},
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Compatibility alias for `predefined_options`. Ignored when `predefined_options` is provided."
      +}
    • changedInput schema / properties / predefined_options / description
      Previous value: -"可选的预定义选项列表,供用户单选/多选"New value: +"Optional list of predefined choices the user can pick from (rendered as multi-select checkboxes alongside a free-text reply). Three input shapes are accepted (v1.5.20+): (a) list[str] — simple labels, all initially unchecked; (b) list[dict] of shape {\"label\": str, \"default\": bool} — let the recommended option start pre-checked without any extra param (aliases: \"label\"/\"text\"/\"value\", \"default\"/\"selected\"/\"checked\"); (c) list[str] paired with the sibling param `predefined_options_defaults` (parallel boolean array). Non-string and non-{label,...} items are silently dropped. Each option max length: 500 characters (longer items are truncated). Tips: (1) keep options short, action-oriented and mutually distinguishable; (2) prefer the dict form `{\"label\": \"Apply\", \"default\": true}` to mark the recommended/default answer — the UI now renders real pre-checked checkboxes, so do NOT rely on text-prefix hacks for marking recommended options; (3) the user may also ignore options and reply with free text. If omitted, the server falls back to `options` for cross-tool compatibility."
    • addedInput schema / properties / predefined_options_defaults
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {},
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Optional sibling array (v1.5.20+) for the `list[str]` shape of `predefined_options`: each element decides whether the corresponding checkbox starts pre-checked. Truthy aliases (case-insensitive, trimmed): True / 1 / 1.0 / \"true\" / \"yes\" / \"on\" / \"selected\"; everything else (including None / 0 / lists / dicts) → False. Length is silently truncated when longer than `predefined_options` and padded with False when shorter. Ignored when `predefined_options` already uses the {\"label\", \"default\"} dict form (which takes precedence)."
      +}
    • addedInput schema / properties / priority
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; ignored by this server."
      +}
    • addedInput schema / properties / project_directory
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility with other feedback MCP variants; this server ignores it (project context is taken from the running Web UI / config)."
      +}
    • addedInput schema / properties / prompt
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Compatibility alias for `message`. Ignored when `message` is provided."
      +}
    • addedInput schema / properties / submit_button_text
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; this server uses its own UI labels."
      +}
    • addedInput schema / properties / summary
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Compatibility alias for `message` (used by noopstudios/Minidoracat interactive-feedback-mcp variants). Ignored when `message` is provided."
      +}
    • addedInput schema / properties / tags
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {},
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; ignored by this server."
      +}
    • addedInput schema / properties / task_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility (some agents pre-generate a trace ID and pass it through); this server always auto-generates an internal task ID and ignores the externally supplied value. Useful when the same `mcp.json` config also points at MCP variants that *do* honour an externally supplied task ID."
      +}
    • addedInput schema / properties / timeout
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; this server uses its own configured backend timeout and auto-resubmit countdown."
      +}
    • addedInput schema / properties / timeout_seconds
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Compatibility alias for `timeout` (used by some MCP clients that explicitly suffix the unit). Both fields are accepted for compatibility — this server ignores them and uses its own configured backend timeout / auto-resubmit countdown. When both are provided, this server logs a debug line and discards both, since neither overrides server config."
      +}
    • addedInput schema / properties / user_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Accepted for compatibility; ignored by this server."
      +}
    • removedInput schema / required
      Removed value: -[
      -  "message"
      -]
  9. Changed7 schema fields changedv1.4.1
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / message / description
      Previous value: -"The specific question for the user"New value: +"向用户展示的具体问题/提示(支持 Markdown)"
    • removedInput schema / properties / message / title
      Removed value: -"Message"
    • changedInput schema / properties / predefined_options / description
      Previous value: -"Predefined options for the user to choose from (optional)"New value: +"可选的预定义选项列表,供用户单选/多选"
    • removedInput schema / properties / predefined_options / title
      Removed value: -"Predefined Options"
    • removedOutput schema / properties / result / title
      Removed value: -"Result"
    • removedOutput schema / title
      Removed value: -"_WrappedResult"
  10. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important runtime behavior: the call blocks until submission/timeout, returns MCP content blocks, raises ToolError on validation failure, returns a configurable resubmit prompt on service failure, and stops after three failures. This is exactly the kind of behavioral context an agent needs for a human-in-the-loop tool.

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 front-loaded with purpose and usage, then organized into clear Behavior and Cross-tool compatibility sections. Despite its length, the detail is justified by the tool's complexity, blocking behavior, error semantics, and 22-parameter compatibility surface.

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?

There is no output schema, but the description explains the returned content blocks and error paths. Combined with the rich schema and annotations, the definition gives an agent enough context to call the tool correctly and interpret common outcomes.

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% across 22 parameters, so the schema already carries the detailed parameter semantics. The description adds the cross-tool alias rationale and lists ignored compatibility parameters, but it largely restates what the schema documents rather than adding new parameter-level syntax or constraints.

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 states a specific verb and resource: ask the human user for interactive feedback through the Web UI. It immediately clarifies the kinds of decisions this tool is meant for, so an agent can recognize its purpose without needing sibling comparison.

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 gives explicit when-to-use guidance: human decision, clarification, confirmation, plan approval, design review, final sign-off, especially when there are multiple valid approaches, irreversible side effects, or significant trade-offs. No sibling alternatives exist, so the missing 'use instead' clause is not a gap.

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