Skip to main content
Glama

asksteps: create a branching funnel

asksteps_create_funnel

Creates a conversational funnel in the connected asksteps account: one question at a time, where each answer decides what comes next. Requires "forms:write". Use this instead of asksteps_create_form when answers should lead to DIFFERENT follow-up questions, or when someone should be able to be ruled out part-way through. Give every question a short ref ("budget", "contact") and point each answer's target at another ref, at "next", at "success" or at "dismiss". The first question in the list is where the funnel starts. It is NOT published; publishing is a separate step.

Input Schema

NameRequiredDescriptionDefault
specYesThe funnel: a name and its questions with their answers and targets.

Output Schema

NameRequiredDescriptionDefault
urlNoLink that opens the form in the asksteps studio. Give it to the user so they can look at the result. Absolute when this deployment knows its public base URL, otherwise a site-relative path; never invent the domain part.
noteYesOne sentence for the user. On rejection it says exactly what to fix.
formIdNoThe id of the form. Keep it — it is how you read or change the form later.
statusYesOutcome. One of: "created", "updated", "not_connected", "not_found", "invalid_spec" (the structure was rejected — the note says exactly what to fix), "not_editable" (this form cannot be written from a spec), "unavailable", "error". Authorisation can also refuse before the tool runs: "plan_required" (the account's plan does not include agent access), "not_enabled" (the account owner has not switched agent access on), "owner_required" (only the account owner may do this), "mandate_required" (the owner has not granted a mandate for this). The note then says what the user has to do.
stepCountNoNumber of steps the form ended up with.
fieldCountNoTotal number of fields across all steps.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / spec / properties / nodes / items / properties / answers / items / properties / display
      Added value: +{
      +  "description": "For \"checkbox-group\": \"list\" (options listed one below the other, the default) or \"dropdown\" (a dropdown showing the picked options as tags). Optional.",
      +  "type": "string"
      +}
    • addedInput schema / properties / spec / properties / nodes / items / properties / answers / items / properties / selection
      Added value: +{
      +  "description": "For \"checkbox-group\": \"single\" (exactly one option may be picked, e.g. yes/no, gender, a membership class) or \"multiple\" (any number, the default). Optional.",
      +  "type": "string"
      +}
    • changedInput schema / properties / spec / properties / nodes / items / properties / answers / items / properties / type / description
      Previous value: -"Field type. One of: \"text\" (single line), \"text-area\" (multi-line), \"number\", \"date\", \"time\", \"select\" (dropdown, needs options), \"checkbox-group\" (multiple choice, needs options), \"boolean\" (single yes/no checkbox), \"file\" (upload), \"signature\" (drawn signature), \"image-upload\" (the visitor uploads one photo, e.g. a passport photo), \"contact\" (the built-in contact block: name, email, phone — use this instead of building those three by hand), \"text-block\" (explanatory text, not an input), \"table\" (a grid to fill in), \"image-choice\" (a picture to pick), \"image\", \"video\"."New value: +"Field type. One of: \"text\" (single line), \"text-area\" (multi-line), \"number\", \"date\", \"time\", \"select\" (dropdown, needs options), \"checkbox-group\" (choice group, needs options; one or several answers, see Selection), \"boolean\" (single yes/no checkbox), \"file\" (upload), \"signature\" (drawn signature), \"image-upload\" (the visitor uploads one photo, e.g. a passport photo), \"contact\" (the built-in contact block: name, email, phone — use this instead of building those three by hand), \"text-block\" (explanatory text, not an input), \"table\" (a grid to fill in), \"image-choice\" (a picture to pick), \"image\", \"video\"."
  2. Changed1 schema field changed
    • changedInput schema / properties / spec / properties / nodes / items / properties / answers / items / properties / type / description
      Previous value: -"Field type. One of: \"text\" (single line), \"text-area\" (multi-line), \"number\", \"date\", \"time\", \"select\" (dropdown, needs options), \"checkbox-group\" (multiple choice, needs options), \"boolean\" (single yes/no checkbox), \"file\" (upload), \"signature\" (drawn signature), \"contact\" (the built-in contact block: name, email, phone — use this instead of building those three by hand), \"text-block\" (explanatory text, not an input), \"table\" (a grid to fill in), \"image-choice\" (a picture to pick), \"image\", \"video\"."New value: +"Field type. One of: \"text\" (single line), \"text-area\" (multi-line), \"number\", \"date\", \"time\", \"select\" (dropdown, needs options), \"checkbox-group\" (multiple choice, needs options), \"boolean\" (single yes/no checkbox), \"file\" (upload), \"signature\" (drawn signature), \"image-upload\" (the visitor uploads one photo, e.g. a passport photo), \"contact\" (the built-in contact block: name, email, phone — use this instead of building those three by hand), \"text-block\" (explanatory text, not an input), \"table\" (a grid to fill in), \"image-choice\" (a picture to pick), \"image\", \"video\"."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the required scope ("forms:write") and the post-creation state ("It is NOT published; publishing is a separate step"), which an agent needs to know. It does not mention rate limits or return shape, but the annotations plus these additions cover the main behavioral questions for a non-destructive create.

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 and the sibling routing, then the structural rules, then the publication caveat. Every sentence carries information, though the ref/target sentence is somewhat dense and partly restates schema text.

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

Completeness4/5

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

Given a rich nested schema, an output schema, and annotations, the description covers what matters: scope requirement, non-publication, and how questions/answers/targets wire together. An agent could call this correctly without further guidance.

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 the baseline is 3, but the description adds a usable mental model: give every question a short ref, point each answer's target at another ref/"next"/"success"/"dismiss", and the first question is the start. This wiring explanation helps the agent construct a valid spec even though the schema repeats most of it.

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?

Specific verb (creates) plus resource (a conversational branching funnel) with the defining behavior stated up front: one question at a time where each answer decides what comes next. This clearly distinguishes it from asksteps_create_form, the sibling it shares a resource family with.

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?

Explicitly names the alternative tool (asksteps_create_form) and the two conditions that select this one: when answers should lead to DIFFERENT follow-up questions, or when a respondent can be ruled out part-way through. That is a genuine when-to-use/when-to-use-the-other rule.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources