Send feedback from the Vercel MCP
By Steven Van ·
The new submit_feedback tool needs sign-in, works on root and project connections, and sends only when the user asks their agent to.
Vercel MCP has a new tool, submit_feedback, for sending bug reports, friction reports and feature requests to the Vercel team from an agent or harness. Vercel described the change in its MCP documentation.
How it works
Feedback can be requested in plain language, for example: "Send Vercel feedback that the deployment error didn't explain which environment variable was missing." The agent can also attach structured context describing the task, the expected behavior and what went wrong. The tool takes a required message (it must contain non-whitespace text) and an optional context object. The vendor's example context uses the fields tool, task, expected, actual and type.
On success the tool returns {"success": true, "message": "Vercel accepted the feedback."}. Acceptance confirms the feedback endpoint took the submission. It does not guarantee delivery to every internal destination or a reply from Vercel.
Availability
- The tool requires sign-in, and it sends feedback only when the user asks the agent to share it.
- It is available on root and project-specific connections when enabled for your account.
- The documentation-only and CLI-only connections do not expose it.
Privacy and limits
Vercel advises leaving out credentials, secrets and full conversations. It applies automatic redaction before forwarding feedback internally. Each submission includes the MCP server version and the OAuth client ID, plus the user ID when available, and the team and project IDs on a project-specific connection. The source is recorded as MCP. A complete submission must be smaller than 1 MiB.
If authentication fails before anything is sent, the error includes a CLI fallback: vercel feedback with Vercel CLI 64.5.0 or newer. Optional context can be passed as a JSON string with --field 'context={...}', and CLI submissions are recorded with the CLI source. There is no CLI fallback when the feedback service is unavailable or when a request times out with an uncertain outcome. In the timeout case the feedback may already have arrived, so resubmitting can create a duplicate.