Youform

Set block logic

set-block-logic-tool

Destructive

Replace the conditional-logic rules attached to one draft block (scoring, jumps, calculations). Rules are evaluated after the respondent answers this block, in order; the first matching jump wins. Every rule is validated against the form — invalid rules are rejected with a message per rule explaining what to change, and nothing is saved. Call list-logic-options-tool first for the block ids, option ids, variables and comparison operators you may use.

Rule shape: {"always"?: true, "conditions": [Condition, ...], "actions": [Action, ...]}. A rule needs at least one condition unless "always" is true.

Condition shape: {"operator_1_type": "block"|"variable"|"calculation", "operator_1": <block id | variable name | "highest_variable"/"lowest_variable">, "operand": , "operator_2": <option id for radio/dropdown/checkbox blocks; number or text for other blocks and variables; variable name for calculation>, "operator_2_type": "option_id" for choice blocks, otherwise "" , "gate"?: "and"|"or" (2nd condition onwards), "matrix_row_id"? for matrix blocks}. Conditions may only reference this block or earlier blocks — later blocks are unanswered when the rule runs.

Action shapes: {"type": "jump", "block_id": }; arithmetic {"type": "add"|"subtract"|"multiply"|"divide", "operand_1": , "operand_1_type": "variable", "operand_2": <number | block id | variable name>, "operand_2_type": "value"|"block"|"variable"} — computes operand_1 = operand_1 operand_2, e.g. lion = lion + 1; set {"type": "set", "operand_1": <source: number | block id | variable name>, "operand_1_type": "value"|"block"|"variable", "operand_2": , "operand_2_type": "variable"} — copies operand_1 INTO operand_2 (the target is always operand_2 for set). Arithmetic needs a number variable created with update-variables-tool.

Outcome quiz pattern: on each question one rule per option adding 1 to that outcome's variable; on the LAST question also one jump rule per outcome with condition {"operator_1_type": "calculation", "operator_1": "highest_variable", "operand": "equal", "operator_2": "", "operator_2_type": ""} jumping to that outcome's ending block. Set default_transition on the last question to a fallback ending.

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": {
      "form_slug": "<form_slug>",
      "block_id": "<block_id>",
      "logic": "<logic>"
    },
    "name": "set-block-logic-tool"
  }
}

Input Schema

Name	Required	Description
`logic`	Yes	The complete list of rules for this block, replacing any existing rules. Pass [] to remove all rules.
`block_id`	Yes	The id of the block the rules are attached to (the question whose answer triggers them).
`form_slug`	Yes	The form's slug.
`default_transition`	No	Optional fallback block id when no jump matches. Omit to preserve the existing fallback; pass an empty string to resume sequential order.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses that rules replace existing logic, are evaluated after the block is answered in order, and that validation is atomic: invalid rules are rejected per rule with nothing saved. It also explains ordering constraints, that conditions may only reference this block or earlier blocks, and that arithmetic requires a number variable created with update-variables-tool.

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

Conciseness5/5

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

The description is long but well structured and front-loaded: purpose and prerequisite first, then Rule shape, Condition shape, Action shapes, and an outcome-quiz pattern. Given the complexity of the nested logic payload, every section earns its place and there is no obvious filler.

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 complex mutation tool with no output schema, the description covers replacement behavior, validation failure handling, evaluation order, reference constraints, action semantics, and default_transition behavior. An agent has enough information to call it correctly and understand the main failure mode.

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?

Although the input schema has 100% description coverage, the description adds substantial meaning: exact rule/condition/action object shapes, operator types, gate semantics, matrix_row_id usage, jump targets, arithmetic direction, and set-copy semantics. The outcome-quiz pattern further clarifies how to compose parameters in a common real use case.

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?

The description states a specific verb and resource: 'Replace the conditional-logic rules attached to one draft block (scoring, jumps, calculations).' It distinguishes the tool from siblings by directing the agent to list-logic-options-tool for available ids/operators and to update-variables-tool for number variables.

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

Usage Guidelines4/5

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

It gives clear context and prerequisites: call list-logic-options-tool first, and rules are evaluated after the respondent answers this block in order, with the first matching jump winning. It also supplies an outcome-quiz pattern, but it does not explicitly state when not to use this tool versus alternatives.

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

All Youform 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.