Remesh
Plan and analyze research
- Category
- Data & Analytics
- Primary Subcategory
- Customer Feedback & Research Platforms
Integration details
Description
Remesh helps research teams find and manage conversations, build discussion guides, configure participant audiences, export study data, and analyze participant responses through ChatGPT.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Customer Feedback & Research Platforms
- Secondary Subcategories
- None listed
- Brand
- Remesh
- Access
- Account required
- First tracked
- 2026-09-04
- Tool count
- 52
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competing in ChatGPT Customer Feedback & Research Platforms
View Category52 tools agents can invoke
Apply Prolific demographic-targeting filters (+ optional screeners) for recruiting. REPLACE semantics: this REPLACES the entire Prolific filter set on the conversation — include every filter you want to keep in each call. A screeners-only call with prolific_filters=[] removes every existing filter except the country-of-residence default, which is always preserved (send a country filter to change it). Wiped filters are reported in the response's removedFilters. prolific_filters: filter objects built from list_prolific_filters (same shape as estimate_audience_count; "selected_options" are the option_id keys of the filter's "choices" map). screener_questions: optional custom (non-Prolific) screening questions, each {"text": str, "is_multiselect": bool, "options": [{"text": str, "is_termination_point": bool, "is_must_select": bool}, ...]} — each screener needs at least 2 options and cannot have every option be a termination point. At least one prolific_filters or screener_questions entry is required. Prerequisites / ordering: the workspace must have recruitment enabled. A non-recruit conversation in the Created state is auto-converted to a recruit conversation — reversible pre-launch by switching to a DIFFERENT link/uploaded mode via set_conversation_audience, which tears the recruit audience down (the filter questions are kept as onboarding polls; see that tool's caveats before re-applying). While it is a recruit conversation it BLOCKS set_conversation_type, so set the type FIRST. Applying is rejected once the conversation is published. This is DEMOGRAPHIC TARGETING (who to recruit from Prolific); for LINK DISTRIBUTION (how participants join) use set_conversation_audience. Returns the applied diff (added / replaced / removed filters, added screeners) plus launch-readiness fields: canLaunch, eligibleCount, and two DIFFERENT participant numbers — numCompletes is the study's target number of completed participants (what the study is sized and quoted on), while participantCap is how many will actually be recruited. Converting a flex conversation to recruit adds an over-recruit buffer, so participantCap comes back HIGHER than numCompletes; use numCompletes for anything user-facing about study size or cost, never participantCap.
Continue a multi-turn auto-DG flow after a clarifying question. Pass the ``thread_id`` from ``run_auto_dg_flow`` and your response to the clarifying question. Repeat until ``state.discussion_guide.status`` is ``complete``.
Create a new conversation in the given team. purpose: 'Billable', 'Non-Billable' or 'Sigora'. Choose 'Sigora' ONLY when the caller explicitly asks for a Sigora conversation; otherwise pick 'Billable' or 'Non-Billable'. It is not a neutral third option: it draws the billable participant cap rather than the much lower non-billable one, it is convertible to a recruit conversation that commissions paid external participants, and it lands in no billing rollup. It is also fixed at create — set_conversation_purpose can never move a conversation into or out of it — so a wrong choice here cannot be corrected afterwards. is_flex: True for async conversations. utc_start_time: ISO-8601 timestamp. language: e.g. 'en'.
Create discussion guide messages in a conversation. Every ``messages`` entry needs ``typename`` and ``section_id``. Most typenames also need ``text`` — branchingAsk is the exception (its prompt lives per-branch). Backend typenames are case-sensitive camelCase; every other spelling is rejected: * ``speak`` — moderator speaks. Needs ``text``, ``duration_in_seconds`` on non-flex conversations. * ``ask`` — Ask Opinion (open-ended qual question). Needs ``text``. No options. * ``experientialAsk`` — Ask Experience. NOT ``askExperience`` / ``ask_experience`` / ``experience``. Needs ``text`` and ``categories`` (array of OBJECTS, not strings): "categories": [ {"text": "Category A", "rank": 0}, {"text": "Category B", "rank": 1} ] Per-category flags: ``is_other``, ``is_none_of_above``. Top-level flags: ``has_other``, ``has_none_of_above``, ``is_randomized``, ``is_multiselect`` (default true), ``multiselect_limit``, ``minimum_thought_char_count``. * ``poll`` — single- or multi-select poll. Needs ``text``. Standard DG polls take ``options`` as an array of STRINGS: "options": ["Yes", "No", "Maybe"] — correct "options": [{"text": "Yes"}] — WRONG, backend rejects Onboarding polls and quota polls take option OBJECTS — see ``add_to_onboarding`` / ``is_quota`` paths. Flags: ``is_multiselect``, ``is_randomized``, ``multiselect_limit``, ``has_other``, ``has_none_of_above``. * ``ranking`` — rank-order question. Needs ``text``. ``options`` accepts strings or objects (``{"text": "...", "rank": N}``). Flag: ``is_randomized``. * ``branchingAsk`` — branching open-ended question. No top-level ``text`` (each branch carries its own prompt). Requires ``branched_poll`` (UUID of an existing poll on this conversation) and ``branches`` — each branch is exactly ``{"text": "...", "poll_options": [<branched_poll_option_UUIDs>]}``. ``rank`` on a branch is REJECTED; branch order is assigned from the array index. Optional ``minimum_thought_char_count``. * ``image`` / ``video`` — media messages. For onboarding polls add ``add_to_onboarding: true`` and omit ``section_id``. ``duration_in_seconds`` per-type minimums (UI + autopilot enforce — backend create does NOT, so it will silently accept too-small values and break later at conversation start): * ask / branchingAsk — 90s * experientialAsk — 60s * ranking — 30s * poll — 15s
Create discussion guide sections. Each section needs: ``name``, ``rank`` (int), ``color`` (hex like '#24DBC3'). New conversations start with one default 'New Section' — list_sections to find its ID, add yours, then delete_section to clean up.
Delete a discussion guide message.
Delete a discussion guide section. **Destructive**: messages inside the section are deleted (or archived if already sent). Confirm with the user before calling on a section that has messages worth preserving.
Duplicate an existing conversation. purpose: 'Billable', 'Non-Billable' or 'Sigora' — the copy's purpose, which need not match the source's. Choose 'Sigora' ONLY when the caller explicitly asks for a Sigora conversation; otherwise pick 'Billable' or 'Non-Billable'. The same warnings as create_conversation apply: it draws the billable participant cap, is convertible to a recruit conversation that commissions paid external participants, lands in no billing rollup, and is fixed on the copy at create — set_conversation_purpose can never move it into or out of that purpose afterwards. Copies discussion guide and settings into a new conversation with the given name. Duplicates of a recruit conversation start as plain (non-recruit) drafts with the source's duration preserved — re-apply a recruit audience via apply_recruit_audience if the duplicate should recruit too. The source's demographic filter questions are carried over as plain onboarding polls — delete them before re-applying a recruit audience, or the duplicate will ask the same questions twice.
Duplicate a discussion guide message within the same conversation. The copy is placed just after the original. ``user_email`` is the moderator attribution. Ended conversations, recruit polls, video interviews, in-flight flex conversations, sent messages in a published live conversation, and onboarding polls once a published live conversation is starting cannot be duplicated (the backend returns a validation error).
Duplicate a discussion guide section and its messages into the same conversation, placed just after the original. Fails if the conversation is ended, the section has a video interview, or the guide is already at its section limit.
Estimate how many Prolific participants match an audience filter spec. prolific_filters: a non-empty list of filter objects built from list_prolific_filters. Use the catalog entry's "filterId" value as "id": {"id": <filterId>, "type": "select"|"range"}. Select filters carry "selected_options": the option_id KEYS of the filter's "choices" map (e.g. "0"), never the human-readable labels. Range filters apply only to age: "range_options": {"lower_bound": int, "upper_bound": int}. Requires recruitment enabled on the workspace and write scope. This issues an external, rate-limited Prolific call (an eligibility query — not a billed/spend action).
Export conversation data. Defaults to JSON participant report. format: 'json' or 'csv'. report_type: 'participant' (default) or 'conversation-by-participant'. export_delimiter: for CSV, 'comma' (default) or 'semicolon'.
Get the result of a previously started analysis flow. ``flow_name`` must match the flow that created the ``run_id``: ``auto-dg-openai-agents`` (what ``run_auto_dg_flow`` kicks off), ``auto-dg-flow`` (result retrieval only — new runs are minted under ``auto-dg-openai-agents``), ``platform-help-flow``, ``talk-to-your-data-openai-agents``, ``talk-to-your-data-flow``, or ``message-routing-flow`` (result retrieval only - no MCP tool mints new runs for these). Run IDs are bound to the caller's workspace + user at creation and expire after 24 hours; callers outside that scope receive ``POLICY_DENIED``. ``verbosity`` (default ``'minimal'`` — pick this when the client resolves citations against ``citations[N-1]`` itself): - ``'minimal'``: ``state.answer``, ``state.citations``, ``state.answer_markdown_with_citations`` (markdown links pre-substituted), and ``state.selected_flow_name``. ~70× lower token cost than ``'standard'``. - ``'standard'``: full Joule state including the ``supporting_data_map`` (~200K characters on a typical TTYD run); opt in for analyst inspection or debugging. - ``'verbose'``: same as ``'standard'`` plus the ``intent`` subkeys inside ``input`` / ``debug_info`` / ``prepared`` that ``minimal`` and ``standard`` strip. Pick this when the client needs the un-trimmed Joule shape (e.g. downstream debugging tooling). Expect a payload increase. Vocabulary matches ``list_conversations``. Citations: when ``flow_name='talk-to-your-data-flow'`` and the run is finished, ``state.answer`` contains ``[N]`` markers and ``state.citations`` is the unified envelope. Always render each ``[N]`` as a markdown link ``[[N]](state.citations[N-1].url)`` so users can click through to the cited source. If ``state.citations[N-1]`` has no ``url`` field, render bare ``[N]`` with no link — never emit ``[N](null)`` or ``[N](#)``. A citation may also carry a ``response_id``, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes ``response_id`` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Supporting-data row labels (when present at ``state.supporting_data_map`` in ``standard`` verbosity): a leading ``All`` cell denotes an aggregate row covering every segment in the conversation; ``Multiple`` denotes a cross-segment row with per-segment breakdown elsewhere in the table.
Get metadata for one or more questions in a conversation — text, type (ask / poll / ranking / branchingAsk / experientialAsk), rank order. Useful when the LLM needs to disambiguate ``Q22`` labels across conversations or look up a question's exact wording before running a deeper retrieval. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Scope: returns data for the whole of each given conversation; `query_text` and `message_ids` are NOT used to select questions here (they are accepted for interface uniformity but do not affect what is returned).
Get segment names + participant counts for a conversation. Pairs naturally with get_segment_agreement_differences and get_segment_frequency_differences — call this first to surface the segment vocabulary the LLM should reason over. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Scope: returns data for the whole of each given conversation; `query_text` and `message_ids` are NOT used to select questions here (they are accepted for interface uniformity but do not affect what is returned).
Get details of a specific conversation.
Get all discussion guide messages for a conversation.
Get high-level conversation stats — participant count, message count, start time, status. Use as a sanity check before deeper analysis tools, or to confirm the right conversation_ids. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Scope: returns data for the whole of each given conversation; `query_text` and `message_ids` are NOT used to select questions here (they are accepted for interface uniformity but do not affect what is returned).
Compute a correlation MATRIX across several (2-8) single-choice poll / ranking questions within ONE conversation. For each pair it builds the participant-level joint distribution and computes the Spearman rank correlation, returning the full N×N coefficient matrix. Use this — NOT get_crosstab_participant_stats — when the user asks for a correlation matrix or how several questions correlate. Multi-select questions are excluded (they cannot be rank-correlated); returns a diagnostic note instead of a matrix when fewer than two eligible ordinal questions are in scope for the query. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get cross-tabulated participant statistics across two segment axes (e.g. age × political affiliation). Higher-cost than get_basic_segment_info; use when the LLM needs joint-distribution context, not just marginal segment sizes. Feature-flagged upstream — may return an empty payload when the workspace flag is disabled. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get a specific discussion guide message.
Get poll/ranking statistics for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get RAG-based summary insights for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get responses and poll results for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get consensus topics for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get high-frequency topics for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get responses for a conversation organized by submission segment (branchOpinion variant of get_relevant_responses_and_poll_results). Use when the conversation contains branching-ask flows and the LLM needs the response shape that preserves submission paths. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get cross-segment agreement differences. Each per-segment ``Agreement from ['<segment>']`` line carries the segment's participant count as ``(n=<count>)``. Treat segments with small n (< 5) as low-confidence — 0% / 100% values at that scale are usually small-sample artifacts, not real divergence. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get cross-segment frequency differences. Each per-segment ``Number of mentions from segment '<segment>'`` line carries the segment's participant count as ``(n=<count>)``. Treat segments with small n (< 5) as low-confidence — frequency spikes at that scale are usually small-sample artifacts. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get sentiment distribution (positive / neutral / negative) aggregated across a conversation's open-ended responses for ask, experiential-ask, and branchOpinion message types. IMPORTANT: ``query_text`` is used by an internal vector-RAG step to pick which ask-opinion messages to score — phrase the query against the SUBSTANTIVE TOPIC asked about, not the meta-question of sentiment. Good: 'sentiment of responses about sustainable shopping barriers' (matches Q12 ask content). Bad: 'overall sentiment distribution' (matches nothing → empty result). Feature-flagged upstream — may return an empty payload when the workspace flag is disabled. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Scoping: the response includes `routed_to` (the question(s) analyzed). Pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages) to bypass the router and target exact questions.
Get representative example responses per sentiment bucket (positive / neutral / negative) for a conversation. Pairs with get_sentiment_distribution — call distribution for the shape, examples for the supporting quotes. IMPORTANT: ``query_text`` is used by an internal vector-RAG step to pick which ask-opinion messages to draw examples from — phrase the query against the SUBSTANTIVE TOPIC asked about, not the meta-question of sentiment. Good: 'examples of negative responses to packaging tradeoffs'. Bad: 'show me sentiment examples' (matches nothing). Feature-flagged upstream. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Scoping: the response includes `routed_to` (the question(s) analyzed). Pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages) to bypass the router and target exact questions.
Get top responses ranked by agreement. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get topics ranked by agreement for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
Get topics ranked by frequency for conversations. Citations: this tool returns a `citations` array. Always render each `[N]` marker in the response as a markdown link `[[N]](citations[N-1].url)` so users can click through to the cited source. If `citations[N-1]` has no `url` field, render bare `[N]` with no link — never emit `[N](null)` or `[N](#)`. Citation joins: a citation may also carry a `response_id`, which identifies the single participant response that citation came from. When the field is absent, the citation covers an aggregate (a summary, topic, or segment) with no single underlying response — do not infer one. No tool takes `response_id` as a parameter today; treat it as an identifier to report or correlate, not something to look up. Routing: this tool runs `query_text` through an internal vector-RAG step to choose which questions/responses to analyze. Phrase `query_text` as the SUBSTANTIVE TOPIC you want (e.g. 'barriers to sustainable shopping'), not the metric or a meta-question (e.g. 'top responses', 'overall agreement'): topic-phrased queries retrieve the relevant content, while meta-phrased ones match little and yield low-relevance or untargeted results. The response includes `routed_to` (the question(s) actually analyzed, with their Q-labels) so you can confirm the router picked what you meant. To bypass the router and target exact questions, pass `message_ids` (question ids from get_basic_question_info / get_conversation_messages); an empty result carries a `results_note` explaining why and what to try instead.
List conversations in the workspace. Returns paginated results. Response envelope: ``{conversations: [...], total: int, limit: int, offset: int, has_more: bool}``. ``total`` is the unpaginated count after filters. ``has_more`` is ``true`` when further pages remain (``offset + len(conversations) < total``) — page on it directly instead of recomputing from ``offset``/``limit``/``total``. Each conversation's shape is controlled by ``verbosity`` below. Pagination: ``limit`` (1-500, default 50), ``offset`` (default 0). Filter semantics: filters are AND'd across params; values within a list filter (``status``, ``purpose``) are OR'd. Example: ``status=["Created", "Ended"]`` returns rows in either status. Filters (all optional): - ``search``: case-insensitive substring match against conversation name. - ``status``: list of {``Created``, ``Published``, ``Active``, ``Ended``, ``Canceled``}. ``Canceled`` is a separate terminal status and is not included in ``Ended`` — pass both to get every finished conversation. Pass as a JSON array, e.g. ``["Ended"]`` — a bare string is rejected. - ``purpose``: list of {``Billable``, ``Non-Billable``, ``Sigora``}. Same list shape as ``status``. Note the hyphen in ``Non-Billable``. - ``team_id``: restrict to a single team. Must be in the caller's team scope — call ``list_teams`` first to see valid IDs. - ``folder_id``: restrict to a single folder within the caller's workspace. Call ``list_team_folders`` on a team to discover folder IDs. Response shape: - ``verbosity``: ``standard`` (default, full conversation details incl. moderator/cover images, use case, duration) or ``minimal`` (``id``, ``name``, ``title``, ``status``, ``purpose``, ``teamId``, ``folderId``, ``startTime`` only — ~10x more conversations fit in a caller's context budget). Sorting: - ``sort_by``: {``start_time`` (default), ``updated_at``, ``created_at``, ``name``, ``id``}. ``name`` sort is case-insensitive. - ``sort_order``: {``desc`` (default), ``asc``}. Typical analysis flow: call with ``status=["Ended"]``, ``purpose=["Billable"]``, and ``search="<study name>"`` to find a specific finished billable study. For broad discovery on a crowded workspace, combine ``verbosity="minimal"`` with ``sort_by="updated_at"`` to page through recently touched conversations.
List participants in a conversation.
List the Prolific audience filters available for recruiting participants. Returns the catalog (gender, age, country, ...). Each entry carries its identifier under "filterId", a "type" ("select" or "range"), a display "question", and "choices". "choices" is a flat mapping of {option_id: label} (e.g. {"0": "Male", "1": "Female"}), NOT a list of objects with key/value fields. To build a spec for estimate_audience_count or apply_recruit_audience, pass the "filterId" value as "id"; for a select filter, "selected_options" are the option_id KEYS of "choices" (the left-hand side, e.g. "0"), never the labels. Requires the workspace to have recruitment enabled.
List discussion guide sections for a conversation.
List folders in a team.
List teams the user is a member of.
List workspace memberships for the current user. Returns all workspace IDs and names from the authenticated user's profile. Use ``set_workspace`` to select which workspace to work in. Bootstrap tool — runs before a workspace is picked, so it skips ``_rate_limited`` (no per-workspace/per-user key available). Transport OAuth still gates access.
Check server status and connectivity. Requires a valid auth context and counts against the READ rate-limit budget. The ``/health`` and ``/ready`` HTTP routes exist for unauthenticated infrastructure probes (Kubernetes liveness/readiness).
Generate a discussion guide from a research objective (multi-turn). ``research_questions``, ``hypotheses``, and ``patterns_to_derive`` accept either a single string or a list of strings — Joule's Auto-DG input expects list fields, and the downstream code normalizes scalars into single-element lists. The first call may return a clarifying question in ``state.answer`` — when ``state.tool_names`` contains ``run_clarifying_round``, respond with ``continue_auto_dg_flow`` using the returned ``thread_id`` and your answer. Repeat until ``state.discussion_guide.status`` is ``complete``.
Ask a question about Remesh platform features.
Schedule a conversation for launch (and optionally publish it). utc_start_time: ISO-8601 timestamp. publish: when True (default) the conversation is published after the schedule update; set False to stage without going live.
Configure how participants join a conversation (LINK DISTRIBUTION). pid_distribute_status sets the link-distribution mode: "SingleLink" (one shared link), "UniquePids"/"NonUniquePids" (generated unique/non-unique links), or "UploadedUniquePids"/"UploadedNonUniquePids" (uploaded participant data). is_limited_to_uploaded_pids restricts joining to uploaded participant IDs. Pass at least one. Audience-mode fields cannot be changed once the conversation has started. Turning off recruit: on a recruit conversation (see apply_recruit_audience), setting pid_distribute_status to a mode DIFFERENT from the current one tears the recruit audience down and switches to the requested mode — the inverse of applying one. Echoing the current mode is refused — a round-tripped GET payload never tears recruit down by accident — except when a recruit conversation sits at SingleLink (a mode recruiting never uses; legacy duplicates produced it), which is switchable regardless so those rows can escape. Allowed pre-launch only (a live recruit conversation must still be in Created status; converted conversations are refused). Caveats: the previously applied Prolific filter questions are kept as onboarding polls, not deleted — on flex conversations they retain their screening/termination behavior — and re-applying a recruit audience later does NOT reconcile them (the same question would be asked twice), so delete them first if re-applying. Other fields in the same call are applied after the teardown; without a differing pid_distribute_status they are refused on a recruit conversation. This controls how people join, NOT who to recruit. For DEMOGRAPHIC TARGETING via Prolific recruiting, use apply_recruit_audience instead — both tools say "audience" but are different concerns.
Set a conversation's billing purpose. purpose: "Billable" or "Non-Billable". Cannot be changed once the conversation has started, ended, or been reopened. "Sigora" is rejected: it is fixed at create, and a conversation already on it cannot be moved off either — use create_conversation or duplicate_conversation to choose that purpose.
Set an unpublished conversation's type to "live" or "flex". "live" is a real-time conversation; "flex" is the asynchronous variant. No-ops if the conversation is already the requested type. Only unpublished conversations can be converted, and the conversion is refused if the conversation has a quota poll, randomization/rotation logic, or was already converted once. Ordering: applying a recruit audience (apply_recruit_audience) auto-converts the conversation to a recruit conversation. While it is a recruit conversation it BLOCKS type conversion — set the conversation type BEFORE applying a recruit audience, or tear the recruit audience down first by switching to a different distribution mode via set_conversation_audience (pre-launch only; see that tool's caveats).
Set the active workspace for the OAuth session. Validates the user is a member of the workspace, fetches team memberships, and stores the session keyed by ``(user_id, client_id)``. May be auto-selected from the OAuth login — try a tool before calling this. Use ``list_workspaces`` to see available workspace IDs. Bootstrap tool — skips ``_rate_limited`` (see ``list_workspaces``).
Update a media message (image/video alt text only). Only image and video messages can be patched. For text messages (speak, ask, poll), delete and recreate instead.
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Remesh alternatives on ChatGPT?
As of 2026-09-04, Remesh competes with Appbot, AppReviewBot, Canny, Dovetail, Employee Surveys & eNPS, Enterpret, Feedbk.ai Survey Agent, Feedspace, Lyssna, Maze, Pheedback, PlaybookUX, Refiner, Reviewbird, Roux, Sleekplan, Strella, Userback, Userbrain, UserTold, Uxia, Voicepanel in ChatGPT Customer Feedback & Research Platforms, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.