Skip to main content
Glama

Create form with questions

create-form-with-questions-tool

Create a new draft form with 1–100 fully configured questions in their supplied order, plus default welcome and thank-you screens. Use this for a new form with supported question types instead of adding and updating questions individually; no schema lookup is needed. Choice options are plain strings. Returns question ids and saved settings. Does not publish: call publish-form-tool separately when requested. The entire creation is rolled back if any question fails. Repeating a successful call creates another form.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "questions": "<questions>"
    },
    "name": "create-form-with-questions-tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesName for the new form.
questionsYesQuestions in respondent order. Advanced types and settings use the existing individual block tools.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations only covering safety hints, the description adds the operationally important facts: the whole creation is rolled back if any question fails, the tool does not publish, and repeating a successful call creates a duplicate form (non-idempotent). Choice options being plain strings is a useful constraint beyond the schema example.

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 scope, then usage, then behavioral caveats. Dense but each sentence carries information; only the 'Returns question ids and saved settings' line borders on filler given the transactional detail already given.

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 two-parameter creation tool with no output schema, the description covers outcome, atomicity, publish separation, and repeat-call behavior. Nothing an agent needs in order to call it safely 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%, so the baseline is 3; the description adds the question-count bound, supplied-order semantics, and the 'no schema lookup is needed' assurance that reduces pre-call exploration. It does not restate per-type option requirements, which the schema already handles well.

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 ('Create a new draft form') and pins down scope: 1–100 fully configured questions in supplied order, plus default welcome and thank-you screens. This is clearly distinguishable from create-form-tool and from the block-level siblings.

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 says to use this 'instead of adding and updating questions individually' and that advanced types/settings should use the existing individual block tools. It also routes publishing to publish-form-tool with an explicit condition ('when requested').

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.