Submit Feedback
writes
Submit a bug report, feature request, or general feedback about the MCP server.
BEFORE SUBMITTING:
- ALWAYS call check_health first and include the output in the environment field.
- Ask the user for optional contact info (email, Slack, etc.) so the team can follow up.
- For bugs: gather error messages, what was attempted, and what happened vs expected. Include steps to reproduce if possible.
- For features: describe the use case and why it matters.
- Title must be specific and actionable (not “bug report” or “feature request”).
PARAMETERS:
- type: “bug”, “feature”, or “feedback”
- title: Specific, actionable title (10-200 chars)
- description: Detailed description (30-5000 chars)
- severity: Optional severity level (low/medium/high/critical)
- stepsToReproduce: Optional steps to reproduce (for bugs)
- environment: Optional environment info (mode, FIX state — from check_health)
- contact: Optional contact info (email, Slack handle, etc.) for follow-up
Returns a feedback ID for tracking. Use get_feedback_status to check updates.
Parameters
Section titled “Parameters”| Parameter | Type | Required | Description |
|---|---|---|---|
type | "bug", "feature", "feedback" | Yes | Type of feedback: ‘bug’ for issues, ‘feature’ for requests, ‘feedback’ for general comments |
title | string | Yes | Specific, actionable title (not generic like ‘bug report’ or ‘feature request’) |
description | string | Yes | Detailed description. For bugs: what happened vs expected. For features: use case and why it matters. |
severity | "low", "medium", "high", "critical" | No | Severity level (optional, mainly for bugs) |
stepsToReproduce | string | No | Steps to reproduce the issue (for bugs) |
environment | string | No | Environment details (mode, FIX state, etc.) — auto-fill from check_health output |
contact | string | No | Optional contact info (email, Slack handle, etc.) so the team can follow up |