- Brand
- BlockSurvey
- Category
- Data & Analytics
- Primary Subcategory
- Form & Survey Builders
Integration details
Description
Create and manage surveys in your BlockSurvey team workspace without leaving ChatGPT. Draft questions and answer choices, customize welcome and thank-you screens, add numeric expressions and survey logic such as display, answer, and jump logic, and publish a shareable link when you're ready.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Form & Survey Builders
- Secondary Subcategories
- None listed
- Brand
- BlockSurvey
- Access
- Account required
- First tracked
- 2026-10-23
- Tool count
- 33
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Agent Discoverability
ChatGPT Plugin Discovery ScoreYour score is coming
ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.
What discovery looks like
Get alerts for BlockSurvey
Get updates when BlockSurvey’s Discoverability Score or category rank changes.
Competing in ChatGPT Form & Survey Builders
View Category33 tools agents can invoke
Add ONE new answer choice to a question in a BlockSurvey team draft, without touching any other choice. Prefer this over update_question's `options` field when you're only adding a choice — update_question replaces the whole choice list and reassigns every choice a new id, which silently breaks anything keyed to an option's id (skip logic, calculations). To add several choices, call this once per choice. For choice-style questions (multiplechoice, checkboxes, dropdown, dropdownmultiple, ranking, colorpicker — for colorpicker, `value` is a text prompt to pick a color for, e.g. "Preferred logo color"; the respondent picks the actual color when answering) this works on `options`; for matrix questions you must also say whether you mean `rows` or `columns` via `target`. Not applicable to consent (its choices are fixed) or any other question type without answer choices. Use get_survey_details first to get the question's and choices' current ids.
add_answer_choice
Add Answer Logic to one answer choice — the per-option (or per-matrix-row/-column) "if / then show" rule that decides whether THAT SPECIFIC choice appears to a respondent. This is NOT Jump/Skip Logic (that's add_jump_logic) and there is no "jump to a question" or "end the survey" action here — Answer Logic has exactly ONE possible outcome: show this one option (or, matrix rows/columns only, show OR hide it — see `visibility` below) when the condition(s) match. Never ask the end user for an action/destination; the only real decisions are (1) which condition(s) trigger it and (2) — matrix only — show or hide. Only available on multiplechoice, checkboxes, dropdown, colorpicker, multiplenumber, multipletext, ranking, and matrixrating questions. Identify the question with `questionId`/`position`, then the choice with `optionId`/`optionPosition` (for matrixrating, also pass `target: "rows"` or `"columns"` first). Omit `entryIndex` to create the choice's first "if" block; provide `entryIndex: 0` (from get_answer_logic) to append the given condition(s) to it instead, combined via each condition's own `conidition`. Each choice can only ever have ONE entry — confirmed directly in the builder source (the "Add option/row/column condition" trigger only ever creates an entry for a choice that has none yet) — so omitting `entryIndex` when one already exists is refused outright (no force override; there's nothing legitimate to force through), pointing you at `entryIndex: 0` instead. Use `insertAfterConditionIndex` to control WHERE a condition lands within an existing entry (omit to append at the end). Additive, not destructive — no confirmation needed beyond that one refusal, and NO randomization side effect either (confirmed absent, unlike question/submit Display Logic's first-entry button). The call is refused outright (no force override, nothing added) if a condition's source question comes after the OWNING question (the one this choice belongs to) in the survey — its answer wouldn't exist yet at that point. Reorder the questions (reorder_questions) or pick an earlier source question first, then retry. `visibility` ("show", the default, or "dontShow") is only meaningful for a matrixrating target and only applied when creating a NEW entry — a plain option always means "show when true," no toggle exists for it (use update_answer_logic to change visibility on an entry that already exists).
add_answer_logic
Add Display Logic to a question, or to the submit screen — the "Display the question only, If..." / "Display the submit button only, If..." conditions in the builder's Logic tab. This is NOT Jump/Skip Logic (that's add_jump_logic — controls where the respondent goes next, never whether something is shown) and NOT Answer Logic (that's add_answer_logic — controls one specific answer choice, not the whole question/button). The only outcome here is visibility: the target is shown when the condition(s) match, hidden otherwise — nothing else happens. Identify the TARGET (the thing that will be shown/hidden) with `questionId` or `position`, OR pass `submitScreen: true` to target the submit button instead (`displayLogics[survey.submit.id]` — same map, same rules, just a different target; exactly one of questionId/position/submitScreen). Omit `entryIndex` to create the target's first "if" block; provide `entryIndex: 0` (from get_display_logic) to append the given condition(s) to it instead, combined via each condition's own `conidition`. Both a question and the submit screen can only ever have ONE entry — confirmed for both directly in the builder source, no "add another" affordance either way — so omitting `entryIndex` when one already exists is refused outright (no force override; there's nothing legitimate to force through), pointing you at `entryIndex: 0` instead. Use `insertAfterConditionIndex` to control WHERE a condition lands within an existing entry (omit to append at the end). This is additive, not destructive — no confirmation needed beyond that one refusal. Creating a QUESTION's first entry also auto-disables Question Randomization if it was on (matches the builder's own side effect) — check `randomizationDisabled` in the result and mention it to the user if true; this never happens for the submit screen (confirmed: its own "Add Display Logic" click has no such side effect), and never happens when appending to an existing entry either way. Question/submit-level Display Logic ONLY — does not cover Answer Logic (that's add_answer_logic) or thank-you-screen display logic (that's add_thankyou_screen_logic). The call is refused outright (no force override, nothing added) if a condition's source question comes after the target question in the survey — its answer wouldn't exist yet at that point, so the condition can never be satisfied, not just risky (this never applies to a submit target, since submit always comes after every question). Reorder the questions (reorder_questions) or pick an earlier source question first, then retry.
add_display_logic
Add Jump Logic to a question — the "Then Jump To" rules in the builder's Logic tab that send the respondent to a different question (or end the survey) based on an earlier answer. This is NOT Display Logic (that's add_display_logic — controls whether a question is SHOWN at all, never where the respondent goes next) and NOT Answer Logic (that's add_answer_logic — controls whether one specific answer choice is shown, also never a destination). The only outcome here is routing: which question (or "end") comes next. Two independent modes, exactly one per call: (1) entry mode — `skipTo` (a question id or the literal string "end") + `conditions` (1+) adds a new jump-logic entry (unlike Display Logic, a question can have MANY entries — omit `insertAfterEntryIndex` to append, or set it to control where the new entry lands, -1 = start, N = right after entry N); provide `entryIndex` instead of `skipTo` to append the given condition(s) to an EXISTING entry's condition list instead (use `insertAfterConditionIndex` to control position within it). (2) defaultJumpTo mode — set `defaultJumpTo` (a question id or "end") instead of skipTo/conditions/entryIndex to set the question's unconditional fallback target (used when no jump-logic rule matches, or when there are none at all) — no conditions involved. This mode REPLACES any existing default jump target on the question without warning, so check get_jump_logic first if the user might already have one. A condition's source question can be the OWNING question itself (checking the answer just given — the common case) or any EARLIER question, but never a later one — refused outright (no force override) if it is, since jump logic evaluates right after the owning question is answered. Creating a question's FIRST jump-logic entry, or setting `defaultJumpTo` for the first time while it has neither entries nor an existing default, auto-disables Question Randomization if it was on (matches the builder's own side effect) — check `randomizationDisabled` in the result. Questions ONLY — not welcome/thank-you screens (get_thankyou_screen_logic) or the submit screen. The submit screen does have its OWN entry in this same `logics` map, but for a different feature entirely — a conditional URL redirect after submission (`redirectTo`, not `skipTo`) — which this tool does not support; there is currently no MCP tool for it.
add_jump_logic
Create a Numeric Expression — Settings > Assignment & Formulas > Numeric Expressions > Create Expression in the builder. A Numeric Expression is a named, computed number built from question scores (and, optionally, other already-created expressions) combined with `+`, `-`, `*`, `/` and parenthesized grouping, given here as a structured `terms` list instead of free text; ordinary arithmetic precedence applies (`*` and `/` bind tighter than `+` and `-` unless grouped). Example: `total = 20 + Q1 - Q6` is terms: [{value:20}, {questionId, operator:"+"}, {questionId, operator:"-"}]; and `ratio = trait-score / Q3 * 100` (using an earlier expression) is [{expressionId}, {questionId, operator:"/"}, {value:100, operator:"*"}]. Each term is exactly one of a question (`questionId`/`position`), another expression (`expressionId`/`expressionLabel` — must already be defined EARLIER in the survey's expression list; a forward reference is refused with a clear error), a literal number (`value`), or a parenthesized sub-formula (`group`, itself an array of terms — use this when precedence needs forcing, e.g. `(a + b) / c`). Unanswered questions count as 0, and a divide-by-zero result is displayed as 0, as in the builder. Optionally add conditional overrides via `conditions`: each is an "IF `when` conditions match, THEN use `thenTerms` instead of the base formula" rule (same condition shape as add_display_logic's). If none of the conditions match for a given respondent, the base `terms` formula is used as the fallback, so it is still meaningful when conditions are present. `recalculateFlag` (default false) mirrors the builder's "Recalculate expression on the results screen" checkbox; `executeOncePerResponse` (default false) mirrors "Evaluate once and fix result" (freezes the value after the first successful computation instead of recomputing on every later answer). The response includes `recallToken` (`{{exp:<id>}}`) for later use — ONLY if the user separately asks to display this score somewhere (e.g. "show the total score on the thank you screen"), paste that exact string into update_question's label/description or update_thankyou_screen's title/description. Do not insert it anywhere on your own initiative just because the expression was created — creating the formula and displaying it are separate asks. Refused for the reserved built-in names (e.g. "score"), for "price" (already exists on every survey — use update_numeric_expression with expressionId: "price" instead), and for any name already used by another expression or a Text Variable.
add_numeric_expression
Add a new question to an existing BlockSurvey team draft, either appended to the end or inserted at a specific position. Mirrors clicking "Add Question" in the builder and picking a type. For choice-style or matrix questionTypes, you MUST ask the end user for the actual answer choices first — do not invent placeholder options. For questionType 'customerexperience', ask the end user which experience metric they want — NPS, CSAT, or CES — if they haven't already said (don't just default to NPS silently). Then, matching whichever it is: for NPS, ask whether they want a specific scale color theme (Solid / Gradient / 2 Color Bleed via `npsTheme`) or the default Solid is fine; for CSAT/CES, ask whether they want it shown as a 1-5 Opinion Scale or a Choose Single with text labels (`componentType`) — the difference is visible to respondents, not a technical detail, so don't pick silently on the user's behalf. Skip asking only if the user has already stated a preference or explicitly says the default is fine.
add_question
Add Display Logic to a thank-you screen — the builder's own label for it, even though it's the same survey.logics map as question-level Jump Logic, keyed by the screen's id. This is what selects WHICH thank-you screen a respondent sees when a survey has more than one: the first screen whose entry conditions evaluate true wins, or the first screen with no logic entries at all. Despite sharing a map with Jump Logic, there is NO "jump to a question" action here — `skipTo` isn't even a parameter on this tool, and has no effect for a screen even where it technically exists on old data. The only two effects are (1) screen selection (which entry's conditions determine this screen gets shown) and (2), optionally, assigning a text variable. Identify the screen with `screenId` or `position` (omit both for position 0). Omit `entryIndex` to create a new entry (a screen can have MANY, unlike question/submit Display Logic's one-entry limit) — position it with `insertAfterEntryIndex` (-1 = start, N = right after entry N, omit = append). Provide `entryIndex` instead to append the given condition(s) to an EXISTING entry (position within it via `insertAfterConditionIndex`). Optionally, when creating a NEW entry, `variable` + `variableValue` sets that entry's "Assign to text variable" — a real, functional side-effect applied when the entry's conditions match (use update_thankyou_screen_logic to add/change one on an entry that already exists). This only assigns a FIXED value to a variable that ALREADY EXISTS — it cannot create a new variable (refused if `variable` isn't a recognized name) and cannot capture/recall a respondent's actual answer into it (refused if `variableValue` contains recall/piping syntax) — see those two fields' own descriptions. No ordering restriction on a condition's source question — thank-you screens only evaluate once the whole survey is complete, so every question is always a valid source. No confirmation/force gate — purely additive.
add_thankyou_screen_logic
Change an existing question's type in a BlockSurvey team draft (e.g. single choice -> multiple choice). This is a CHECK-THEN-CONFIRM operation, not a one-shot mutation: call it first WITHOUT `force`. If the question isn't referenced anywhere else in the survey, it changes immediately. If it IS referenced (skip logic, another question's default jump-to, calculations, feedback, validation logic, discount/display logic, duplicate submission logic, piped references, loop references, or as the question randomization range's start/end), the call makes NO changes and instead returns a categorized report of exactly what depends on it — relay that to the user verbatim (or summarized) and ask whether to proceed anyway, since changing the type regenerates the question's id (and its options' ids) entirely. Only call again with `force: true` if the user explicitly confirms after seeing that report — never set force preemptively or guess that it's fine. Calculations, feedback, validation logic, discount logic, display logic, and duplicate submission logic are always fully cleaned up when the change proceeds (each one's own rules, and any other question's condition pointing at it) — check `calculationsCleaned`/`feedbackCleaned`/`validationLogicCleaned`/`discountLogicCleaned`/`displayLogicCleaned`/`duplicateSubmissionLogicCleaned` in the result and mention whichever are non-empty. Jump-logic rules that skip TO this question, and its own defaultJumpTo (plus other questions' defaultJumpTo pointing at it), are automatically repointed at the new id rather than broken (its own outgoing jump-logic rules and loop references are cleared instead, matching the builder). Piped references and email notifications are the only categories left dangling even with force. If this question itself has custom regex validation rules or a Default Feedback fallback configured, those are simply discarded as part of the type change (neither can ever be referenced by anything else) — check `regexValidationsLost`/`defaultFeedbackLost` and mention if non-empty. questiongroup and A/B test questions can't be changed with this tool (they hold nested child questions). This is also the tool for switching an EXISTING 'customerexperience' (NPS/CSAT/CES) question's Component Type between Opinion Scale and Choose Single — the builder's own toggle for that is this exact same type-change machinery under the hood, so there's no lighter-weight way to do it. Call with questionType: 'customerexperience' and `componentType` set to the target; its exType (nps/csat/ces) and answer-choice text are preserved automatically.
change_question_type
Create a new BlockSurvey survey with a title, a complete list of questions, a welcome screen, and a thank-you screen, all in one call. You (the assistant) write ALL of this content yourself from the conversation with the end user — this tool does not generate anything itself, it just persists exactly what you send. Ask the end user what the survey should cover, and for any choice-style or matrix question, ask for the actual answer choices — never invent placeholder questions or options. For any 'customerexperience' question, ask which metric they want — NPS, CSAT, or CES — if they haven't said (don't default to NPS silently), then ask the matching follow-up: NPS's scale color theme (`npsTheme` — Solid / Gradient / 2 Color Bleed, default Solid) or, for CSAT/CES, whether it should show as a 1-5 Opinion Scale or a Choose Single with text labels (`componentType`) — that's visible to respondents, not a technical detail. Skip asking only if the user already stated a preference or says the default is fine. Always also compose welcomeScreen and thankyouScreen content tailored to that same topic (see their field descriptions) — include both by default, the same way you'd never leave the questions blank; only skip one if the end user explicitly says they don't want it. Use add_answer_choice / edit_answer_choice / delete_answer_choice / update_question / update_welcome_screen / update_thankyou_screen for any later edits.
create_survey
Delete ONE answer choice from a question in a BlockSurvey team draft. This is destructive — confirm with the end user which choice they mean before calling this. Identify the choice with `optionId` or `choicePosition`. The question must keep at least 2 choices. Deleting a choice that's still referenced elsewhere is refused unless `force` is set — tell the user about that in plain language and ask whether they still want to delete it instead of blindly forcing it through. Display logic, discount logic, calculations, feedback, and jump-logic conditions referencing the deleted choice are fully cleaned up automatically once you proceed; only a piped reference is left dangling even with force. For choice-style questions (multiplechoice, checkboxes, dropdown, dropdownmultiple, ranking, colorpicker — for colorpicker, `value` is a text prompt to pick a color for, e.g. "Preferred logo color"; the respondent picks the actual color when answering) this works on `options`; for matrix questions you must also say whether you mean `rows` or `columns` via `target`. Not applicable to consent (its choices are fixed) or any other question type without answer choices. Use get_survey_details first to get the question's and choices' current ids.
delete_answer_choice
Delete a Numeric Expression. Identify it with `expressionId` or its current `label`. Before deleting, this checks whether the expression is referenced elsewhere: recalled inside another expression's formula, used as a condition's comparison value (skip/jump/thank-you-screen/display/answer/discount logic), set as the Price expression for Payment, or recalled (`{{exp:<id>}}`) inside a question's label/description or a Thank You screen's title/description. If any references are found, the call is refused with the list — nothing is deleted, and nothing is auto-repointed (unlike delete_question, references here are NOT automatically cleaned up; force:true leaves them dangling, silently resolving to 0/blank). The refusal message ends with an AGENT_NOTE aimed at you, the calling model: never quote that message or mention the `force` parameter to the end user — just ask a plain yes/no about deleting the expression.
delete_numeric_expression
Delete a question from a BlockSurvey team draft. Identify it with `questionId` (from get_survey_details) or its 0-based `position` in the questions array (e.g. the 4th question is position 3). This is destructive — always confirm with the end user which question they mean before calling this, especially when they refer to it by number or description rather than an exact id. If the question turns out to be referenced elsewhere in the survey — skip logic (including another question's rule that skips TO it), another question's default jump-to, calculations, feedback, validation logic, discount logic, display logic, duplicate submission logic, loop references, the randomization range, piped references, or email notification — the call is refused with a message describing what was found; ask the user in plain language whether they still want to delete it, then retry with `force: true` once they say yes. Every category above EXCEPT piped references and email notification is fully cleaned up automatically on that retry, nothing left dangling; those two are left dangling even with force. Also reports (never blocking, just informational) if this question itself has custom regex validation rules or a Default Feedback fallback configured — both are simply discarded when the question is deleted, since neither can ever be referenced by anything else. The refusal message ends with an AGENT_NOTE aimed at you, the calling model: never quote that message or mention the `force` parameter to the end user — just ask a plain yes/no about deleting the question.
delete_question
Change the text and/or score of ONE existing answer choice on a question in a BlockSurvey team draft, keeping its id and every other choice untouched (so skip logic, calculations, etc. that reference it keep working). Identify the choice with `optionId` or `choicePosition`. Provide `value` and/or `score`. For choice-style questions (multiplechoice, checkboxes, dropdown, dropdownmultiple, ranking, colorpicker — for colorpicker, `value` is a text prompt to pick a color for, e.g. "Preferred logo color"; the respondent picks the actual color when answering) this works on `options`; for matrix questions you must also say whether you mean `rows` or `columns` via `target`. Not applicable to consent (its choices are fixed) or any other question type without answer choices. Use get_survey_details first to get the question's and choices' current ids.
edit_answer_choice
Get basic info about the BlockSurvey account connected to this session: the user's name and email, every team/workspace they belong to (with their role in each — owner/admin/member/contributor/guest), and which workspace is "current" for this session (the one picked at OAuth consent time, or the personal "My Items" workspace). Call this when the user asks who they're logged in as, what teams they're part of, or which workspace this session is currently operating in.
get_account_info
Read one answer choice's Answer Logic — the per-option (or per-matrix-row/-column) "if / then show" rule that decides whether THAT SPECIFIC choice appears to a respondent, based on an earlier answer. This is the SAME `displayLogics` map question/submit Display Logic uses, just keyed by the option's/row's/column's own id instead of a question's id. This is NOT Jump/Skip Logic (that's get_jump_logic) — there is no "jump to a question"/"end survey" action anywhere in this data; the only possible outcome is showing (or, matrix only, showing/hiding) this one choice. A separate builder feature only available on multiplechoice, checkboxes, dropdown, colorpicker, multiplenumber, multipletext, ranking, and matrixrating questions. Identify the question with `questionId` or `position`, then the choice with `optionId` or `optionPosition` — for a matrixrating question, also pass `target: "rows"` or `"columns"` first to say which axis it belongs to (required for matrix, rejected for every other type). Read-only. `hasAnswerLogic: false` with an empty `entries` array if there's none. Each entry's `visibility` ("show" or "dontShow") is only present for a matrixrating target — a plain option's Answer Logic always means "show this option when the conditions match," full stop, matching question-level Display Logic's own fixed semantics; matrix rows/columns can instead mean "don't show it when they match." When describing this to the end user, describe conditions in plain English — never quote raw field names like `qid`/`conidition`/`entryIndex` verbatim. Before stating whether a choice currently HAS Answer Logic, or what it contains, call this tool fresh and read its result — never assert this from memory of an earlier call in this conversation, including your own earlier edits; the survey may have changed since then, including edits you made yourself.
get_answer_logic
Read a question's (or the submit screen's) Display Logic — the "Display the question only, If..." / "Display the submit button only, If..." conditions in the builder's Logic tab that decide whether it's shown at all, based on an earlier answer. Identify the question with `questionId` (from get_survey_details) or its 0-based `position`, OR pass `submitScreen: true` to read the submit button's own Display Logic instead (`displayLogics[survey.submit.id]` — same map, same shape, just a different target; exactly one of questionId/position/submitScreen). Read-only. This is NOT Jump/Skip Logic (that's get_jump_logic — a routing decision, never a visibility one) — the only outcome in this data is shown-or-hidden. Question/submit-level Display Logic ONLY — does NOT cover Answer Logic (per-option/per-matrix-row-or-column display rules, a separate builder feature keyed by option/row/column id instead — that's get_answer_logic) or thank-you-screen display logic (a different, unrelated mechanism — that's get_thankyou_screen_logic). Returns an empty result cleanly if there's none. When describing this to the end user, describe conditions in plain English ("if Q2's answer is X") — never quote raw field names like `qid`/`conidition`/`entryIndex` verbatim. Before stating whether a question/the submit screen currently HAS display logic, or what it contains, call this tool fresh and read its result — never assert this from memory of an earlier call in this conversation, including your own earlier edits; the survey may have changed since then, including edits you made yourself.
get_display_logic
Read a question's Jump Logic (also called Skip Logic) — the "Then Jump To" rules in the builder's Logic tab that send the respondent to a different question (or end the survey) based on an earlier answer, plus its separate `defaultJumpTo` fallback (used when no rule matches, or when there are no rules at all). Identify the question with `questionId` (from get_survey_details) or its 0-based `position`. Read-only. Questions ONLY — does not cover jump logic on welcome/thank-you screens (a structurally identical map, different target — get_thankyou_screen_logic is the separate tool for that) or the submit screen. The submit screen has its own entry in this same `logics` map, but for a different feature — a conditional URL redirect after submission (`redirectTo`, not `skipTo`) — which no MCP tool currently covers; submit's Display Logic (whether the button shows at all) is separately covered by get_display_logic's submitScreen option. A question can have many jump-logic entries, unlike Display Logic's one-entry limit. When describing this to the end user, describe conditions in plain English ("if Q2's answer is X, skip to Q5") — never quote raw field names like `qid`/`conidition`/`skipTo`/`entryIndex` verbatim. Before stating whether a question currently HAS jump logic, or what it contains, call this tool fresh and read its result — never assert this from memory of an earlier call in this conversation, including your own earlier edits; the survey may have changed since then, including edits you made yourself.
get_jump_logic
Read one Numeric Expression (by expressionId or label) or, with both omitted, every expression in the survey. Decodes the stored formula's `{{que:id}}`/`{{exp:id}}` recall tokens back to readable question/expression labels (`readableFormula`, e.g. "20+[1. How satisfied are you?]-[6. How likely are you to return?]...") and flags `hasDanglingReference: true` on any expression containing a token whose question/expression id no longer exists — the exact failure mode behind "my expression returns 0 / doesn't return the expected sum": nothing in the BlockSurvey builder itself validates a stored expression's tokens, so a stale or malformed one is otherwise invisible until a respondent's score comes back wrong. Use this to diagnose that before rebuilding an expression from scratch. Also returns each expression's conditional overrides (if any, decoded the same way) and its `recallToken` (`{{exp:<id>}}`) — only paste that into update_question / update_thankyou_screen if the user separately asks to display the score somewhere, never on your own initiative.
get_numeric_expression
Retrieve the full survey JSON (questions, options, welcome/thank-you screens) for a survey previously created with create_survey. If the survey has no encryption keys yet (e.g. it was created before its team's key was escrowed), this also attempts to generate and attach them automatically, the same way opening a keyless survey in the real BlockSurvey builder does - silent and best-effort, never a reason this call fails. The raw `displayLogics` map is shared by THREE separate builder features, distinguishable only by what its key is: an entry keyed by a question's own id is that question's Display Logic; an entry keyed by `survey.submit.id` is the submit button's Display Logic; an entry keyed by an OPTION's (or matrix row's/column's) id is Answer Logic — a distinct, per-choice feature, never call it "Display Logic (option-level)" or similar. Likewise `logics` is shared between question-level Jump Logic and thank-you-screen logic, keyed by question id vs. screen id respectively. To VERIFY whether a specific piece of display/answer/jump/thank-you-screen logic was actually added, changed, or removed — e.g. confirming a prior add/update/delete call took effect — call the matching get_display_logic/get_answer_logic/get_jump_logic/get_thankyou_screen_logic tool for that exact target instead of re-pulling this whole survey and inspecting `displayLogics`/`logics` yourself; those tools already resolve and correctly label everything this map conflates, so re-deriving it by hand is exactly how "Answer Logic" gets miscalled "Display Logic" or a target gets misidentified. If you do end up looking at `displayLogics`/`logics` here for some other reason, never describe them to the user as "the displayLogics map," "keyed by X," or similar — that's internal storage detail, not something to explain. When summarizing this for the user, focus on what they asked about — don't volunteer every field present. This is internal builder-JSON, not end-user language: NEVER quote a raw field/property name to the user (e.g. `preventDuplicateSubmission`, `preventDuplicateSubmissionByAnswer`, `hideAssignVariable`, `conidition` — that last one is the real app's own typo, not yours to explain) — translate every fact into plain English instead ("this question is used to detect duplicate submissions", not "it has preventDuplicateSubmission: true set on it"). And never speculate about what a field probably does or how it's probably implemented (e.g. "likely alongside device/session-based detection") — state only what you can actually confirm from the data, and say plainly that you're not sure rather than inventing a plausible-sounding mechanism.
get_survey_details
Get the edit (builder) link for a survey, plus its public share link if it's already published. Call this whenever the user asks for the edit link, builder link, or 'the link to my survey' for a survey that already exists (found via list_surveys, or an id you already have from create_survey/publish_survey) — don't reconstruct the URL yourself. If the survey has never been published, only the edit link is returned; publishing state doesn't affect the edit link itself, since edits made after publishing go live immediately at the same share link (there is no separate re-publish step).
get_survey_link
Read a thank-you screen's Display Logic — the builder's own label for it (the "Add Display Logic" button in the thank-you screen's Logic tab), even though under the hood it's the same survey.logics map and add/clone/delete-logic machinery as question-level Jump Logic, just keyed by the screen's id instead of a question's. This is the real SCREEN-SELECTION mechanism when a survey has multiple thank-you screens: goToThankyouSection walks them in order and shows the first one whose entry conditions evaluate true, or the first screen with no logic entries at all (an unconditional catch-all). Identify the screen with `screenId` (from get_survey_details) or its 0-based `position` in `thankyouScreens[]`; omit both to read position 0, the default screen every survey has. Read-only. A screen can have MANY entries (no one-entry limit like question/submit Display Logic). Each entry can also carry an "Assign to text variable" — a real, functional side-effect (unlike `skipTo`, which technically exists on the underlying object but is never read for a screen and isn't exposed here at all). When describing this to the end user, describe conditions in plain English — never quote raw field names like `qid`/`conidition`/`entryIndex` verbatim. Before stating whether a screen currently HAS logic, or what it contains, call this tool fresh and read its result — never assert this from memory of an earlier call in this conversation, including your own earlier edits; the survey may have changed since then, including edits you made yourself.
get_thankyou_screen_logic
List the surveys in this session's team workspace (whichever team was selected at OAuth consent time) — each with its id, title, and status (live/draft/closed). Call this whenever the user refers to a survey by name or description rather than giving its id directly (e.g. "add a question to my Rolls Royce survey") — match their description against the titles returned here to find the right id, then use that id with the other tools. Does not include surveys in other teams/workspaces this session isn't connected to.
list_surveys
Publish a survey so it's live and can start collecting responses, and return its public share link — once published, anyone with that link can open and respond to the survey. Call this when the user asks to publish, launch, go live, or share a survey. Before calling, ask the user which display format they want the survey shown in — one question at a time (default), classic (all questions on one scrollable page), or conversational (chat-style) — unless they've already said or it's obvious they don't care, in which case just use the default. Safe to call on a survey that's already published — it won't re-publish, but passing viewType still updates the display format and share link if changed.
publish_survey
Reorder the top-level questions in a BlockSurvey team draft. Give the COMPLETE new order as a list of question ids — call get_survey_details first to see the current ids and order. To swap two questions (e.g. move the 5th question to where the 9th is, and vice versa), take the current id list, swap those two entries, and pass the whole list back; for a bulk reorder, pass the whole list in its new order. This only changes order — it never adds or removes questions (use add_question / delete_question for that) — and it only reaches top-level questions, not ones nested inside a question group or A/B test. If the new order would flip a skip-logic condition, a piped/recalled reference, a loop reference, or the randomization range so that it now points at a question moved to the wrong side, the call is refused unless `force` is set — tell the user about that instead of blindly forcing it through.
reorder_questions
Set whether a question in a BlockSurvey team draft requires an answer — the "Required" checkbox in the builder. Identify the question with `questionId` (from get_survey_details) or its 0-based `position` (the 4th question is position 3). Rejected for questiongroup, statement, and A/B test questions — the builder has no Required toggle for those at all. For a matrix question this is the same field as "Required: One response per row". For a contact form question, toggling this also toggles every one of its fields.
set_question_required
Edit one Answer Logic entry on an answer choice — the per-option (or per-matrix-row/-column) "if / then show" rule that decides whether THAT SPECIFIC choice appears to a respondent. Identify the question with `questionId`/`position`, the choice with `optionId`/`optionPosition` (for matrixrating, also pass `target: "rows"` or `"columns"` first), and the entry with `entryIndex` (call get_answer_logic first — always 0, since a choice can only ever have one entry). Provide EXACTLY ONE of: `conditions` and/or `visibility` together (edits that entry in place — can be combined in one call, matching the builder where both are independently editable on the same entry: `conditions` replaces the entry's whole condition list, `visibility` — matrixrating targets only, "show" or "dontShow" — changes whether the row/column shows or hides when the conditions match); `deleteConditionIndex` (removes one condition — if that empties the entry, the entry is removed too, nothing left dangling); or `deleteEntry: true` (removes the whole entry; if it was the last entry for this choice, its displayLogics key is removed too). The `conditions` (replace) path is refused outright (no force override, nothing changed) if a condition's source question comes after the OWNING question (the one this choice belongs to) in the survey. Reorder the questions or pick an earlier source first. `visibility` on a plain-option (non-matrixrating) target is refused — those choices have no such field at all, matching the builder exactly.
update_answer_logic
Edit one Display Logic entry on a question, or on the submit screen — the "Display the question only, If..." / "Display the submit button only, If..." conditions in the builder's Logic tab. Identify the TARGET with `questionId`/`position`, OR pass `submitScreen: true` for the submit button's Display Logic instead (same map, same rules, different target; exactly one of questionId/position/submitScreen), and the entry with `entryIndex` (call get_display_logic first to see current entries and their indices — always 0, since either target can only ever have one entry). Provide EXACTLY ONE of: `conditions` (replaces the entry's whole condition list), `deleteConditionIndex` (removes one condition — if that empties the entry, the entry is removed too, nothing left dangling), or `deleteEntry: true` (removes the whole entry; if it was the last entry, its displayLogics key is removed too). The `conditions` (replace) path is refused outright (no force override, nothing changed) if a condition's source question comes after the target question in the survey — its answer wouldn't exist yet at that point, so the condition can never be satisfied (never applies to a submit target, since submit always comes after every question). Reorder the questions or pick an earlier source first. Question/submit-level Display Logic ONLY — does not cover Answer Logic (that's update_answer_logic) or thank-you-screen display logic (that's update_thankyou_screen_logic).
update_display_logic
Edit a question's Jump Logic. Identify the question with `questionId`/`position` (call get_jump_logic first to see current entries and their indices). Provide EXACTLY ONE of these modes: (1) `conditions` and/or `skipTo` together with `entryIndex` — edits that entry in place (these two can be combined in one call, matching the builder where both fields are independently editable on the same entry at once: `conditions` replaces the entry's whole condition list, `skipTo` changes its jump target to another question's id or "end"); (2) `deleteConditionIndex` with `entryIndex` — removes one condition from that entry (if that empties it, the entry is removed too, nothing left dangling); (3) `deleteEntry: true` with `entryIndex` — removes the whole entry (if it was the question's last one, its `logics` key is removed too); (4) `defaultJumpTo` alone (no entryIndex needed) — "" clears the question's existing default-jump-to fallback, or a question id/"end" sets/changes it. The conditions/skipTo path is refused outright (no force override) if a condition's source question comes after the OWNING question in the survey — jump logic evaluates right after the owning question is answered, so a source can be that question itself or an earlier one, never a later one.
update_jump_logic
Edit an existing Numeric Expression in place — its id never changes, so every existing recall of it (`{{exp:<id>}}` in other expressions, question text/description, Thank You screen text, or a condition's valueRef) keeps resolving correctly afterward. Identify the expression with `expressionId` or its current `label`. Only the fields you provide are changed; everything else is left as-is. This is also how "Price" gets its formula set: it already exists on every survey (pre-seeded, id "price", no formula yet) — use `expressionId: "price"` here rather than add_numeric_expression, which refuses to create a second one. Provide `terms` to replace the base formula entirely — this is a whole-list replace, not a merge; include every term you want kept. Same term shapes as add_numeric_expression: a question, another expression, a literal `value`, or a parenthesized `group`, combined with `+`/`-`/`*`/`/` — full arithmetic, matching the builder's own eval()-based formula box, not just addition/subtraction. Provide `conditions` to replace the whole conditional-override list (`[]` removes all conditions and falls back to the base formula only). Provide `newLabel` to rename it (subject to the same name-collision rules as add_numeric_expression). The response includes `recallToken` (`{{exp:<id>}}`) for later use — ONLY if the user separately asks to display the score somewhere, paste it into update_question / update_thankyou_screen. Don't insert it anywhere on your own initiative.
update_numeric_expression
Edit an existing question in a BlockSurvey team draft — its label, description, required flag, answer choices, and/or type-specific scale/limit/format settings (scale range, star count, character/value limits, date format, file count limit, list max entries, default phone country — see `options`' field descriptions). Identify the question with `questionId` (from get_survey_details) or its 0-based `position` in the questions array (e.g. the 4th question is position 3). Does NOT support changing a question's fundamental type — that's a separate, more destructive operation in the real app; use change_question_type for that. The one exception is `exType` on an existing customerexperience question — switching NPS/CSAT/CES is a same-type scale change, not a type change, so it's supported here directly (no need to delete and re-add). `npsTheme` (cosmetic NPS scale coloring) is also editable directly, same reasoning. For choice-style or matrix questions, if you're changing the answer choices you MUST ask the end user for the actual new choices first — do not invent them. `options.values`/`rows`/`columns` REPLACE the choices entirely and generate fresh ids for them — if any discarded choice is still referenced elsewhere as a piped reference, the call is refused unless `force` is set; tell the user about that instead of blindly forcing it through — piped references are left dangling even with force. Display logic, discount logic, calculations, feedback, and jump-logic conditions are NOT left dangling: if a discarded choice is referenced in any of those, it's always fully cleaned up once the replace proceeds (check `displayLogicCleaned`/`discountLogicCleaned`/`calculationsCleaned`/`feedbackCleaned`/`jumpLogicCleaned` in the result) — and the refusal message says so distinctly when that's the only kind of reference found. If you're only adding, renaming, or removing specific choices rather than replacing the whole list, prefer add_answer_choice / edit_answer_choice / delete_answer_choice instead — it edits choices in place and never has this problem. Changing a scale/range field doesn't have that same dangling-reference risk, but can still make existing skip logic or a calculation referencing this question stop making sense against the new range — the response will flag it if that's a possibility, so relay that to the user rather than assuming everything downstream is still fine.
update_question
Edit a survey's thank-you screen — shown after a respondent submits. Every survey has at least one by default. A survey can have more than one when branching logic routes different respondents to different thank-you screens — identify which one with `screenId` (from get_survey_details) or its 0-based `position` in thankyouScreens; omit both to target the default (position 0). Editable fields: title, description, button text, image layout, whether social share icons show, whether the BlockSurvey branding footer shows, the parent-redirect setting for iframe embeds, and hideAlways (keeps the screen configured but skips it for respondents — useful when a survey has multiple thank-you screens and one should only ever be reached via branching logic, never as a fallback). Does NOT support setting the screen's image itself or the social-follow-icons section (needs actual social links, which this tool has no way to supply) — those stay in the builder UI.
update_thankyou_screen
Edit a thank-you screen's Display Logic. Identify the screen with `screenId`/`position` (omit both for position 0) and the entry with `entryIndex` (call get_thankyou_screen_logic first to see current entries and their indices). Provide EXACTLY ONE of: `conditions` and/or `variable`/`variableValue` together with `entryIndex` (edits that entry in place — conditions and variable can be combined in one call, matching the builder where both are independently editable on the same entry: `conditions` replaces the entry's whole condition list, `variable: ""` clears its "Assign to text variable", any other value sets/changes it paired with `variableValue` — must be a name that ALREADY EXISTS in the survey's variable list (this tool can't create one, and refuses an unrecognized name), and `variableValue` must be a fixed value, never recall/piping syntax — refused if it looks like `{{prefix:id}}`, since it would never actually resolve to the respondent's answer); `deleteConditionIndex` with `entryIndex` (removes one condition — if that empties the entry, the entry is removed too); or `deleteEntry: true` with `entryIndex` (removes the whole entry; if it was the screen's last one, its `logics` key is removed too).
update_thankyou_screen_logic
Edit a survey's welcome (cover) screen — the optional intro shown before question 1: its title, description, call-to-action button text, and image layout. There's at most one welcome screen per survey. Calling this with title/description/buttonTxt creates the welcome screen if the survey doesn't have one yet, using the same defaults the builder's "Add Welcome Screen" button does. Pass enabled: false to remove it entirely (the survey then starts directly on question 1) — that discards the screen's content. For a softer, reversible hide that keeps the content but skips it for respondents, use hideAlways instead. Does NOT support setting the screen's image itself — this MCP server has no file-upload capability.
update_welcome_screen
Recommended guideHow to get your ChatGPT Plugin suggestedFollow the practical steps agents use to find, shortlist, and choose your Plugin.Read guideBlockSurvey ChatGPT Plugin FAQ
How the directory, categories and Discoverability Score work.
Read the methodologyHow do I improve BlockSurvey's ChatGPT Plugin 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 BlockSurvey alternatives on ChatGPT?
As of 2026-10-23, BlockSurvey competes with CalcForms, Clipform, Cognito MCP, CrowdHum, Dayalogs, Fillo, Form Backend, FormBuilder and 28 more in ChatGPT Form & Survey Builders, 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.