getuserfeedback.com

View saved version →

---
name: collect-product-feedback
description: Create or edit getuserfeedback.com Flows to collect product feedback. Use when a user wants to ask their users a question or change an existing Flow.
---

# Collect product feedback

Start from what the user wants to learn or decide. When that is clear, propose
a short Flow rather than turning setup into a questionnaire for the user.
Ask about one thing at a time, use neutral wording, and keep the effort
proportionate to the question. Prefer a concrete recent experience over a
hypothetical prediction. A low rating can identify a problem without explaining
its cause. An open question can help uncover what to investigate next.
Keep wording and scales consistent when comparing results over time. Consider
who can see the Flow and when they see it: an in-app question cannot reach
people who never return. Avoid collecting personal information the question
does not need.

When improving an existing Flow, preserve questions and settings unrelated to
the requested change. Edits to a live Flow take effect immediately, so say so
before changing one. Saving a Flow's first delivery rule makes it live. Explain
the chosen delivery surface and audience without assuming they are already
configured.

`flow_templates_list` returns actionable template IDs. `flow_create` accepts
either a template or custom pages, not both. Flow content is page-first. The
schema and editing semantics are at `getuserfeedback://docs/flow-content`.

`flow_get.flow.editableContent` is the safe editing projection. Its `versionId`
is the revision required by `flow_content_update`. Null means the content is
unavailable for editing through MCP. `currentVersion` is a read projection and
may contain omissions.

Launch surface, delivery rule, and live window are distinct settings.
`flow_get` exposes them through `launchPlan`, `flowSchedule`, and
`deliveryRuleAuthoring`. Delivery-rule edits replace the complete rule and use
its automation version ID. Launch and rule changes can return
`confirmation_required` when they affect pending deliveries.

A `cacheInvalidationWarning` describes a committed write whose cache refresh
failed, rather than a failed write.

View saved version →

---
name: follow-up-with-users
description: Read feedback conversations, send respondent follow-ups, or manage inbox state through getuserfeedback.com.
---

# Follow up with users

Use the Response and conversation context to identify what a follow-up would
clarify. A useful question asks about the specific experience, its consequence,
or the workaround the person used. Keep it short and neutral; avoid asking the
respondent to endorse a proposed solution or repeat something they already
explained. Do not promise a fix or delivery date without an explicit commitment
from the user.

When asked for drafts or suggestions, return drafts without sending them or
changing inbox state. When sending is requested, distinguish the message actually
sent from any remaining drafts and report the returned delivery state accurately.

`conversation_start` starts a thread from a Response. `conversation_continue`
replies to an existing thread. Both send an external message; their message
receipts expose delivery state, not proof that the recipient read the message.
The server resolves the recipient from the Response or conversation, without
exposing their stored contact details to the model.

`inboxItemId` identifies the current user's inbox row, separately from the
Response and conversation IDs. Inbox read, archive, and star operations affect
that row. `inbox_items_list` uses priority ordering; concurrent inbox changes
can shift records between pages.

View saved version →

---
name: review-user-feedback
description: Inspect getuserfeedback.com Responses to answer questions about user feedback.
---

# Review user feedback

Answer the product question using the feedback actually examined. Group related
problems, explain the evidence behind each theme, and link to the supporting
Responses when their product links are available. Include relevant conflicting
feedback rather than forcing every answer into the dominant theme.
Preserve the wording of permitted answer content when quoting. Label paraphrases
as summaries. Consider the severity of a reported problem as well as how often
it appears.

Separate what users reported from your interpretation and proposed next step.
Feedback can suggest an explanation. It does not by itself establish causation
or represent everyone who uses the product. State the scope and coverage of the
review. Do not describe a page or sample as the complete dataset, count multiple
Responses as distinct people, or turn a few examples into a population percentage.
If the available evidence cannot answer the question, identify the gap and a
focused question that would help resolve it.

`responses_list` provides compact analysis. `response_get` provides approved
answer content. Query matching verifies sanitized answer content permitted for
the model and fills pages with matching responses. Dedicated contact fields and
withheld answers are excluded.

`user_get` opens the current User behind a Response's opaque
`respondentReference`. References are scoped to the organization and may change
after identity deletion or reset. Stored identity, attributes, and dynamic
event properties are withheld from the model. The User UI can show separately
delivered sensitive context, marked with a padlock.