asksteps

asksteps: read one funnel with its branching

asksteps_get_funnel

Read-onlyIdempotent

Reads one funnel of the connected asksteps account: its questions, answers and where each answer leads. Requires "forms:read". ALWAYS call this before asksteps_update_funnel — the write replaces every question, so you need the current state to keep what you are not changing. If the id turns out to be a flat form, the answer says so and points you at asksteps_get_form.

Input Schema

Name	Required	Description	Default
`funnel_id`	Yes	The funnel id, as returned by asksteps_list_forms.

Output Schema

Name	Required	Description
`name`	No	The name of the funnel as the customer sees it in their account.
`note`	Yes	One sentence for the user, explaining the outcome and what to do next.
`spec`	No	The structure of the funnel, in the same shape asksteps_update_funnel expects.
`status`	Yes	Outcome. One of: "ok", "not_connected", "not_found", "not_a_funnel" (this is a flat form — use asksteps_get_form instead), "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.
`editable`	No	Whether asksteps_update_funnel may write this funnel back. When false, DO NOT try — it contains things this format cannot describe, and writing would delete them.
`funnelId`	No	The id of the funnel, to pass back to asksteps_update_funnel.
`blockedBy`	No	Why writing is blocked, in one sentence. Empty when editable.
`themeCustomized`	No	True when the funnel uses a hand-built design instead of one of the presets.
`screensBlockedBy`	No	Why the intro/success/dismiss pages must not be sent back. Empty when they may be.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 16, 2026

addedOutput 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"
+}

addedOutput 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"
+}

changed

Output 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\"."

Changed1 schema field changedOct 14, 2026

changed

Output 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\"."

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint, idempotentHint); the description adds the required scope ('Requires "forms:read"'), the read-before-write workflow dependency, and the degraded-input behavior when the id is a flat form. That is meaningful context beyond what the annotations declare.

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?

Three sentences, zero filler, front-loaded with purpose then constraints then fallback. Each sentence changes agent behavior.

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 elaboration, yet the description still outlines the returned branching. Auth scope, prerequisite ordering, and the wrong-resource fallback all covered — nothing needed to invoke correctly is missing.

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% for the single funnel_id, so the schema already carries the baseline. The description adds value by warning that the id may actually refer to a flat form and what happens then, which clarifies the parameter's real-world semantics beyond the schema note.

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 ('Reads one funnel') plus the returned substance ('questions, answers and where each answer leads'), which immediately separates it from asksteps_get_form and asksteps_list_forms. An agent can identify the tool's job without opening the schema.

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?

Gives an explicit ordering rule ('ALWAYS call this before asksteps_update_funnel') with the reason (the write replaces every question), and names the alternative for the wrong-id case ('points you at asksteps_get_form'). When-to-use, when-not, and alternatives are all present.

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

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