Skip to main content
Glama

Formstep

by io.github.formstep
OverviewDiscussionsAdmin

Insert contact question

editor_insertContactQuestion

Insert a contact question for email, phone, or URL. Choose contactType based on what information you need.

Input Schema

NameRequiredDescriptionDefault
afterNoNodeId to insert after. Use $prev to chain. Omitting appends to end (usually wrong).
titleYesQuestion title
formIdYesForm ID to insert into
patternNoRegex the email or url must match
isHiddenNoStart hidden (the target of a `show` rule).
parentIdNoParent node ID to insert into (e.g., column1)
positionNoPosition among siblings: inside parentId when given, else at the top level ('first' = top of the form, e.g. a title). Not combinable with after.
requiredNoWhether question is required. Default: true. Pass false to make the field optional.
contactTypeYesType of contact field
placeholderNoPlaceholder text
defaultValueNoLiteral default seeded on open; respondent can edit or clear it. Not with defaultValueFieldRef.
defaultCountryNoPhone only: preselected country, ISO 3166-1 alpha-2
requireVerificationNoEmail only: respondent confirms the address by emailed code (Business plan)
defaultValueFieldRefNoPre-fill the input with a hidden or calculated field value at fill time. The respondent can still edit it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / defaultCountry
      Added value: +{
+  "description": "Phone only: preselected country, ISO 3166-1 alpha-2",
+  "pattern": "^[A-Z]{2}$",
+  "type": "string"
+}
    • addedInput schema / properties / pattern
      Added value: +{
+  "description": "Regex the email or url must match",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / requireVerification
      Added value: +{
+  "description": "Email only: respondent confirms the address by emailed code (Business plan)",
+  "type": "boolean"
+}
  2. First observed

TDQS

B3.2/5.0
Behavior2/5

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

Annotations already declare a non-read-only, non-destructive, non-open-world write operation, so the safety profile is covered. The description adds no behavioral context beyond that – it says nothing about what node is created, what is returned, permissions, or the interaction of after/position (which the schema handles). For a mutation tool it contributes almost no disclosure.

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?

Two short sentences, correctly front-loaded with the action and resource. The second sentence is low-value filler rather than an operational constraint, but overall there is no bloat.

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

Completeness3/5

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

The schema is very rich (14 params, enums, nested object, insertion-position constraints), so the description needn't restate parameters, and no output schema exists to explain. However, for a complex insertion tool it omits any note on the created node's identity or return value, leaving it minimally adequate.

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?

Schema description coverage is 100%, so the schema documents all 14 parameters and the nested defaultValueFieldRef object, including mutual-exclusivity notes (after vs position, defaultValue vs defaultValueFieldRef). The description only lightly echoes contactType semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource ('Insert a contact question') and enumerates the domain (email, phone, URL), so an agent can distinguish it from other editor_insert*Question siblings without opening the schema. It stops short of explicitly naming the alternatives it is not (e.g., insertTextQuestion) for a truly differentiated 5.

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

Usage Guidelines3/5

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

'Choose contactType based on what information you need' is guidance about parameter choice, not about when to prefer this tool over the other insert-question tools. There is no when-to-use/when-not statement or named alternative, so usage is only implied.

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

All Formstep toolsInspect
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