Skip to main content
Glama

asksteps

by co.asksteps

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

TableJSON Schema
NameRequiredDescriptionDefault
form_idYesThe form id, as returned by asksteps_list_forms.

Output Schema

TableJSON 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.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description explains the read is a prerequisite for safe updates, discloses the auth requirement ('forms:read'), and reveals that the response includes an 'editable' field indicating whether writing is allowed. This is valuable behavioral context that helps the agent understand side effects and sequencing.

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, each earning its place: the first defines what is read, the second gives a mandatory usage rule and why, and the third adds a relevant behavioral detail. No filler or repetition of schema/annotation content.

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 simple one-parameter read tool with an output schema and read/idempotent annotations, the description covers the essential context: what is returned, permission needed, why it must precede updates, and the editable flag. There are no critical gaps for an agent to discover at call time.

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

Parameters3/5

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

The input schema already provides full coverage for the single parameter, form_id, including its provenance from asksteps_list_forms. The description does not add parameter-level detail, so the baseline of 3 is appropriate since the schema carries the semantic weight.

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 form ... as a structure of steps and fields.' The phrase 'the same shape asksteps_update_form takes' distinguishes this read tool from other asksteps tools and clarifies its role in the update flow. The title reinforces the read-only, editable-structure purpose.

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?

The description gives explicit, actionable usage guidance: '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.' It also names the required permission. However, it does not explicitly state when not to use this tool or contrast it with sibling read tools such as asksteps_get_form_stats or asksteps_get_funnel.

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

All asksteps toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Tools are mostly distinct with clear ownership of each resource and action, and descriptions explicitly contrast sibling pairs (analyze_pdf vs import_pdf, create_form vs create_funnel, publish_form vs update_publication, change_plan vs start_checkout). However, an agent skimming names alone could misselect between the four creation tools or the two PDF tools without reading the descriptions carefully.

Naming Consistency5/5

Every tool follows the asksteps_<verb>_<noun> pattern perfectly, with uniform verbs like get_, list_, create_, and update_. The only slight deviation is create_from_template, but even that stays predictable and readable within the convention.

Tool Count3/5

At 24 tools, this sits at the heavy end of the 16-25 borderline range. The broad domain (form/funnel building, publishing, PDF import, billing, stats, leads) justifies most of them and there is no obvious redundancy, but the sheer volume makes navigation harder than a tighter set.

Completeness4/5

The core form and funnel lifecycle is well covered: multiple creation paths, read, full replacement update, delete with confirmation, publish/unpublish, stats, and leads export. Billing covers first purchase, plan changes, and quota checks. Minor gaps exist — no dedicated subdomain listing tool, no funnel-specific stats, and no programmatic PDF field mapping — but these are explicitly documented as human steps, so agents can work around them.

Resources