# submit\_feedback

Record whether a conversation helped, as an up or down rating with the reason, without asking another question.

Feedback belongs to the conversation, not to one answer. Each call adds a separate event to the chat, so a client can send several, at any point, including while an answer is still running. Submitting feedback starts no answer and runs no SQL.

The rating and its justification appear in the chat in the web app, marked as MCP feedback. They count as evidence when Cassis analyzes chats with Cassis for context gaps, and Cassis can take them into account when answering later questions in the same chat.

Record user corrections or confirmations, and concrete mistakes the agent observes in an answer, SQL or results, including externally executed SQL and failures recovered through retries. Label the reason “User feedback” or “Agent observation”; mark hypotheses unverified. A positive rating should reflect the user confirming correctness. Only the chat’s author can submit.

A clarification reply belongs in `ask_question`, with the same `chat_id` and the question’s `clarification_id`. Feedback does not answer or resume it. Wait for `status: recorded` before a follow-up that depends on the feedback; submission during a running answer may not affect that answer.

## Parameters

| Name | Type | Notes |
| --- | --- | --- |
| `chat_id` | string | The chat to rate, as returned by [`ask_question`](/reference/mcp/ask-question/). Required |
| `rating` | string | `"up"` or `"down"`. Required |
| `justification` | string | Why the conversation helped or did not. Required: 1 to 10,000 characters, after surrounding whitespace is trimmed |
| `project_id` | UUID | The chat’s project. Required, except with an API key scoped to one project, where it defaults to that project |

## Response

| Field | Notes |
| --- | --- |
| `status` | `"recorded"` |
| `feedback_id` | The id of the new feedback event |
| `chat_id` | The rated chat |
| `rating` | `"up"` or `"down"` |
| `justification` | The recorded text, trimmed |
| `source` | `"mcp"` |
| `created_at` | When the event was recorded, ISO 8601 |
| `error` | Handled failures can return this field, such as a malformed id or a chat the caller cannot rate. Parameter validation and other failures can instead be MCP tool errors; credentials can fail at HTTP level. See [Limits and errors](/reference/limits/) |

## Example

Example request when the user says the active-customer answer used the wrong window:

```yaml
chat_id: "019e3a41-7c2d-7b10-8f4e-2d61c0a9b7e5"
rating: "down"
justification: "User feedback: active means at least one delivered order in the last 90 days."
```

Example recorded response:

```yaml
status: "recorded"
feedback_id: "019e3a44-0b18-7d55-a3c2-91f6e8d40c27"
chat_id: "019e3a41-7c2d-7b10-8f4e-2d61c0a9b7e5"
rating: "down"
justification: "User feedback: active means at least one delivered order in the last 90 days."
source: "mcp"
created_at: "2026-10-08T14:02:11.482913+00:00"
```

The chat itself continues as before: send the next question with the same `chat_id`, or a correction such as “count only delivered orders in the last 90 days” so Cassis re-answers with it.