QuestionPunk

Display Logic Container Create

display_logic_container_create

Show a question only when a condition holds, e.g. ask a follow-up only to people who rated 6 or lower. Creates the target question's display logic with one group and one rule; add more conditions with display_logic_group_create and display_logic_rule_create. A question has at most one container (a second is rejected): check display_logic_list first. Draft surveys only: a published survey rejects logic edits, so set logic up before publishing. Question ids and option order come from survey_get. Each group has exactly one source: sourceSurveyItemId or sourceUrlParameterId. URL parameter conditions support is/is_not with args.value matching a declared enumValues entry. Conditions by source question type: multiple_choice, dropdown, ranking, constant_sum: is_selected_option with { idx } (0-based index into answer_options, or "none" / "other"). opinion_scale, slider, rating, numeric: is_number_less, is_number_greater, is_number_equal_to, is_number_not_equal_to with { value: number }. date: is_date_on, is_date_not_on, is_date_before, is_date_later with { date: "YYYY-MM-DD" }. matrix: is_matrix_selected with { rowIdx, colIdx } (0-based). short_text, long_text: is, is_not (AI meaning match) with { value }. short_text, long_text, email, phone_number, website: string_contains, string_does_not_contain, is_string_equal_to, is_string_not_equal_to, string_begins_with, string_ends_with with {}, then set the text with display_logic_rule_update_text. URL parameter sources: is, is_not with { value: "" }. A decision question cannot be a source. The target question shows when its logic matches and is hidden otherwise.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "surveyId": "<surveyId>",
      "targetSurveyItemId": "<targetSurveyItemId>",
      "displayLogicGroups": "<displayLogicGroups>"
    },
    "name": "display_logic_container_create"
  }
}

Input Schema

Name	Required	Description
`surveyId`	Yes	The survey ID
`containerCondition`	No	How to combine groups in this container (optional, app default "or")
`displayLogicGroups`	Yes	Exactly one display logic group within this container
`targetSurveyItemId`	Yes	Question ID to show/hide based on conditions

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=false) by disclosing the one-container-per-question cardinality limit and that a second is rejected, the draft-only restriction, the exactly-one-source rule per group, and that decision questions cannot be sources. It also explains the semantic outcome: the target question shows when its logic matches and is hidden otherwise.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then the escalation path, then constraints, then the rule taxonomy, so an agent can stop reading once it has what it needs. It is dense but nearly every clause carries operational weight; the one blemish is that URL-parameter is/is_not with args.value is stated twice in different places.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and the remaining burden is fully carried: preconditions, cardinality, source exclusivity, per-type condition catalogs, and args formats are all present. Nothing an agent needs to construct a valid call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a 3 would be the baseline, but the description adds substantial meaning the schema cannot: which ruleCondition values are valid for each source question type, the exact args shapes (0-based idx into answer_options, or "none"/"other"; numeric value; YYYY-MM-DD dates; rowIdx/colIdx for matrix), and that string operators require a follow-up display_logic_rule_update_text call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Creates the target question's display logic with one group and one rule") plus the user-facing effect ("Show a question only when a condition holds"). It explicitly separates itself from the sibling escalation tools display_logic_group_create and display_logic_rule_create, which handle additional conditions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names alternatives and the conditions that select them (group/rule create for more conditions, display_logic_list to check for an existing container). It also states a hard prerequisite: draft surveys only, because a published survey rejects logic edits, so logic must be set up before publishing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All QuestionPunk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?