Triage product feedback from Claude Code
Feedback that arrives through the API is classified as bug, feature request, praise, billing or support. With the MCP server connected, the agent working in your codebase can read that queue, so "what are users reporting about the importer?" is answered next to the code that needs fixing.
Claude Code connects to remote MCP servers over HTTP directly. One command registers the server under the name nordva.
Setup
You need a secret key (nv_live_…) from Dashboard → API keys.
01Register the server
claude mcp add --transport http nordva https://mcp.nordva.dev \
--header "Authorization: Bearer nv_live_..."The name comes before the URL. By default the server is added for the current project only and stored outside the repository; add --scope user to make it available in every project.
02Or share it with the team without sharing the key
.mcp.json
{
"mcpServers": {
"nordva": {
"type": "http",
"url": "https://mcp.nordva.dev",
"headers": {
"Authorization": "Bearer ${NORDVA_API_KEY}"
}
}
}
}Claude Code expands ${NORDVA_API_KEY} from the environment, so the file can be committed while each developer keeps their own key in their shell profile.
03Check the connection
Run claude mcp list, or type /mcp inside a session. nordva should show as connected. Then ask Claude to run setup_check: it reports the project, the plan and which features are unlocked.
Then ask Claude Code
- Show me the latest bug reports.
- How many feature requests came in this week, and what are they about?
- Log this as feedback from user 4812: the export button does nothing on Safari.
- Route bugs to our GitHub repo acme/app.
For “Show me the latest bug reports.” Claude Code calls list_feedback with:
{
"classification": "bug",
"limit": 20
} Returned: A list of submissions with id, text, classification, confidence and page URL, plus a cursor if there are more.
Feedback tools and arguments
submit_feedback
Indie and BuilderSubmit, classify, and route user feedback
| feedback_text | required | string, max 2,000 | Verbatim user feedback text. Do not paraphrase. |
| user_id | optional | string, max 256 | Identifier of the user who submitted the feedback. |
| optional | string, max 254 | Submitter's email, if they want a reply. Never guess it. | |
| page_url | optional | string, max 2,048 | URL the user was on when leaving feedback. |
| category_hint | optional | "bug" | "feature_request" | "praise" | "billing" | "support" | Pre-classification hint when the agent is confident. |
list_feedback
Read-onlyList recent feedback submissions
| limit | optional | number, 1–100 | Page size (default 25). |
| cursor | optional | string | Opaque cursor from a previous page's meta.next_cursor. |
| classification | optional | "bug" | "feature_request" | "praise" | "billing" | "support" | "uncategorised" | Filter results to one classification. |
| status | optional | string, max 40 | A lifecycle status, or "open" for everything not yet reviewed or resolved. |
update_feedback
Mark feedback reviewed or resolved, or fix its category
| feedback_id | required | string, max 64 | Feedback id from list_feedback, e.g. "fb_...". |
| status | optional | "reviewed" | "resolved" | |
| classification | optional | "bug" | "feature_request" | "praise" | "billing" | "support" | "uncategorised" | Only to correct a wrong classification. |
configure_feedback_routing
Configure a feedback routing destination (email/linear/github/slack)
| destination | required | "email" | "linear" | "github" | "slack" | Which destination to configure. One of: email, linear, github, slack. |
| destination_email | optional | string | [email] Address to send feedback notifications to. |
| api_key | optional | string | [linear] Linear personal or workspace API key (lin_api_...). |
| team_id | optional | string | [linear] Linear team ID (from team Settings → API). |
| assignee_id | optional | string | [linear] Linear user ID to assign created issues to. |
| personal_access_token | optional | string | [github] GitHub PAT with repo scope (or fine-grained issues:write). |
| owner | optional | string | [github] GitHub username or organisation name. |
| repo | optional | string | [github] Repository name without the owner prefix. |
| assignee | optional | string | [github] GitHub username to assign created issues to. |
| label_map | optional | object | [linear/github] Map feedback category → destination label. e.g. { bug: 'bug', feature_request: 'enhancement' } |
| webhook_url | optional | string | [slack] Incoming Webhook URL (https://hooks.slack.com/services/...). |
Behaviour worth knowing
- Submitting feedback is part of the Indie and Builder plans. On Free, submit_feedback answers PLAN_UPGRADE_REQUIRED; list_feedback works but has nothing to list.
- submit_feedback takes between 10 and 2,000 characters of text. A category_hint can be passed; classification still runs and reports its own confidence.
- configure_feedback_routing replaces any existing configuration for the same destination. It creates and updates but does not delete.
- Routing credentials (a Linear API key, a GitHub token, a Slack webhook URL) pass through the agent. The tool description tells it to ask for consent first and never to repeat the secret back.
- Tools appear to the model as mcp__nordva__<tool>, which is the form to use in permission allowlists.
- Read-only tools are marked as such by the server; Claude Code still asks before the first call to each tool unless you allow it.