QUESTIONSTAR

Add Jump Logic Rule

add_jump_logic_rule

Adds a jump (branching/skip) rule to a survey: when the SOURCE question's answer matches the condition, the respondent skips forward to a target page, or the survey finishes. The rule fires when the source question's page is submitted, so jumps only go FORWARD: the target page must be strictly after the source's page — put the branching/screening question on an EARLIER, SEPARATE page than the questions it gates (create pages with add_survey_page). A backward or same-page target is an explicit error. target is a 1-based page number or 'end'. target='end' finishes the survey right there as a LEGITIMATE COMPLETED response — the branch simply ends early; it is not a screen-out or disqualification. Operator and value work like add_display_logic_rule conditions (option code for choice questions, literal for text/number). Verified by readback: the reply is the rule as actually stored in the survey. Requires the edit-survey right.

Input Schema

TableJSON Schema

Name	Required	Description
`code`	Yes	Survey publication code — the 8-character code from the survey's public link (e.g. 1a2b3c4d). Returned by list_surveys.
`value`	No	Value to compare against: the option's numeric code for choice questions (get_survey lists them), a number or text otherwise. Omit for is_empty/is_not_empty.
`target`	No	Where to go when the condition matches: a 1-based page number strictly after the source question's page, or 'end' to finish the survey as completed.
`operator`	Yes	Comparison operator, e.g. equals / not_equals / greater / less_or_equal / is_empty.
`question`	Yes	Variable code of the SOURCE question whose answer is checked (Q1, Q2, … from get_survey).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	No	What the call did, verified, refused or previewed — the complete human-readable outcome.
`preview`	No	true when the call was a preview (confirm not passed): nothing was changed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: firing timing (on source page submit), a hard forward-only constraint, same/backward targets being an explicit error, readback verification of the stored rule, and the edit-survey right requirement. Crucially it clarifies that target='end' is a legitimate completed response, not a screen-out — semantics an agent could easily get wrong.

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-loaded with purpose, then constraints, then parameter behavior — dense and mostly waste-free. Slight redundancy with the schema's own target/operator descriptions, but nothing that misleads.

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?

For a mutation tool with an output schema (readback), the description covers everything an agent needs: prerequisites (edit right, page ordering), edge cases (backward target error, 'end' semantics), and verification behavior. Return format is delegated to the output schema appropriately.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: operator/value mirror display-logic conditions (option code for choice, literal for text/number), and target must be strictly after the source page. It re-explains target's definition already in the schema, so it is not fully additive.

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+resource ('Adds a jump (branching/skip) rule to a survey') and immediately distinguishes itself from the sibling add_display_logic_rule by contrasting jump/skip vs display semantics. An agent can tell exactly what this creates and how it differs from the display-logic tool.

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?

Explicit when-to-use guidance: place the branching question on an earlier, separate page (pointing to add_survey_page), forward-only targets, and what happens with target='end'. It also names the alternative (add_display_logic_rule) whose operator/value semantics this tool reuses.

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

All QUESTIONSTAR 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?