Skip to main content
Glama

asksteps: read one form as an editable structure

asksteps_get_form
Read-onlyIdempotent

Reads one form of the connected asksteps account as a structure of steps and fields — the same shape asksteps_update_form takes. Requires "forms:read". ALWAYS call this before asksteps_update_form: the write replaces the whole form, so you need the current state to keep what you are not changing. The answer also tells you whether writing is allowed at all (field "editable").

Input Schema

NameRequiredDescriptionDefault
form_idYesThe form id, as returned by asksteps_list_forms.

Output Schema

NameRequiredDescriptionDefault
nameNoThe name of the form as the customer sees it in their account.
noteYesOne sentence for the user, explaining the outcome and what to do next.
specNoThe structure of the form: steps and fields, in the same shape asksteps_update_form expects.
formIdNoThe id of the form, to pass back to asksteps_update_form.
statusYesOutcome. One of: "ok", "not_connected", "not_found", "not_a_form" (this is a funnel with branching, which this tool cannot describe), "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.
editableNoWhether asksteps_update_form may write this form back. When false, DO NOT try — the form contains things this format cannot describe, and writing would delete them. Tell the user to edit it in the asksteps studio instead, and say why.
blockedByNoWhy writing is blocked, in one sentence. Empty when editable.
themeCustomizedNoTrue when the form uses a hand-built design instead of one of the presets. The themeId in the spec then does NOT describe what the user sees — say so instead of naming the preset. Leaving themeId empty keeps the hand-built design; setting it replaces it.
screensBlockedByNoWhy the intro/success/dismiss pages must not be sent back, in one sentence. Empty when they may be. When this is set, still change the form — just leave "screens" out of the spec, and the existing pages stay untouched.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / spec / properties / steps / items / properties / fields / 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 / steps / items / properties / fields / 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"
      +}
    • changedOutput schema / properties / spec / properties / steps / items / properties / fields / 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
    • changedOutput schema / properties / spec / properties / steps / items / properties / fields / 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.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value beyond that: it requires the forms:read permission, warns that the write is a full replacement (hence the read-first mandate), and notes the returned editable flag that gates whether writing is allowed. That goes well past what annotations supply.

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?

Three sentences, front-loaded with purpose then the read-before-write rule. No filler, though the pipe-dash phrasing is slightly dense; still efficient overall.

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?

Output schema exists, so return values needn't be fully explained, yet the description still names the editable flag and the steps/fields shape. Combined with the read permission and the write-replacement warning, an agent has everything needed to call it correctly.

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% and the sole parameter form_id is documented as coming from asksteps_list_forms, so the baseline is satisfied. The description adds meaning by framing the output shape (steps and fields) and the editable field, though it says nothing new about the single input parameter.

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 (reads) and resource (one form), and describes the shape returned (steps and fields), explicitly tying it to the sibling asksteps_update_form's expected shape. This distinguishes it clearly from asksteps_list_forms and asksteps_get_form_stats.

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 rule: ALWAYS call this before asksteps_update_form, and explains why (the write replaces the whole form, so you need current state). That is a concrete when-to-use constraint with reasoning, not vague guidance.

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