Skip to main content
Glama

Clipform

by io.github.Clipform
OverviewDiscussionsAdmin

Get Build Workflow

clipform_get_workflow
Read-onlyIdempotent

Retrieve a step-by-step build workflow for creating a specific form type. Returns the exact tool sequence, form settings, node configuration, scoring setup, and end screen config as a build recipe.

Does NOT return craft knowledge (question psychology, difficulty curves, narration style) - use clipform_get_guide for that.

Available types: quiz, survey, interview, testimonial, application, booking, intake, lead-capture. Aliases also accepted: trivia → quiz, test → quiz, exam → quiz, feedback → survey, poll → survey, nps → survey, questionnaire → survey, case-study → interview, callout → interview, lead-gen → funnel, qualification → funnel, lead-magnet → funnel, story → testimonial, review → testimonial, job-application → application, admission → application, enrollment → application, grant → application, registration → booking, signup → booking, event → booking, rsvp → booking, workshop → booking, client-intake → intake, onboarding → intake, enquiry → intake, inquiry → intake, new-client → intake, lead → lead-capture, lead-form → lead-capture, enquiry-form → lead-capture, waitlist → lead-capture, get-a-quote → lead-capture. Quiz variants (optional): personality, comprehension, composition - returns the variant-specific workflow instead of the base quiz workflow.

Optional args by type:

  • quiz: topic, question_count (8)

  • quiz (variant: personality): topic, categories, question_count (8)

  • quiz (variant: comprehension): question_count (8), audience

  • interview: purpose, response_format (all), needs_consent (true)

  • survey: topic, anonymous (true)

  • funnel: outcomes, criteria, needs_contact (true)

  • testimonial: use_case

  • application: role

  • booking: event_name, event_type

  • intake: use_case, response_format (all)

  • lead-capture: use_case

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoWhat the application is for (application)
typeYesForm type to get the build workflow for (accepts aliases like 'feedback' → survey)
topicNoTopic or theme (quiz, survey)
contextYesDescribe the user's underlying goal in one sentence - not the tool you're calling.
purposeNoWhat you're collecting (interview)
variantNoQuiz sub-variant. Only used when type is 'quiz'. Omit for a standard scored quiz.
audienceNoTarget audience (quiz variant: comprehension)
criteriaNoRouting criteria (funnel)
outcomesNoSegments or recommendations (funnel)
use_caseNoWhat stories to collect (testimonial)
anonymousNoAnonymous survey (survey)
categoriesNoComma-separated outcome categories (quiz variant: personality)
event_nameNoEvent or offering name (booking)
event_typeNoType of event (booking)
needs_consentNoInclude consent statement (interview)
needs_contactNoInclude contact capture (funnel)
question_countNoNumber of questions, default 8 (quiz types)
response_formatNoHow respondents reply (interview)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / youtube_url
      Removed value: -{
-  "description": "YouTube video URL (quiz variant: comprehension)",
-  "type": "string"
-}
  2. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Describe the user's underlying goal in one sentence - not the tool you're calling.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "type"
-]New value: +[
+  "type",
+  "context"
+]
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare a safe, read-only, idempotent, closed-world retrieval, so the safety profile is covered. The description adds useful substance beyond that by spelling out what the recipe contains (tool sequence, settings, scoring, end screen), which matters since there is no output schema. It stops short of noting anything about response size or downstream application of the recipe.

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 the guide exclusion before the long tail of type/alias detail, so the critical routing information comes first. The exhaustive alias list is bulky but each mapping prevents a failed call, so it earns most of its space; the structure could still be tightened.

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 an 18-parameter, no-output-schema tool this is complete: the agent knows the valid types, variants, per-type optional args and defaults, and what the response will contain. The required 'context' parameter is documented in the schema, and nothing needed to invoke correctly is missing from the description.

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, but the description genuinely adds meaning: it maps which optional args apply to which type, states the question_count default of 8, and gives the full alias table (trivia→quiz, nps→survey, etc.) that the schema only gestures at. The tiering of args by type is information the flat schema cannot convey.

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+resource ('Retrieve a step-by-step build workflow for creating a specific form type') and enumerates the returned artifacts (tool sequence, settings, node config, scoring, end screen). It explicitly differentiates itself from clipform_get_guide, so an agent can route without opening either 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 exclusion: 'Does NOT return craft knowledge… use clipform_get_guide for that,' naming the alternative and the condition selecting it. It also enumerates the valid type values and variant options, preempting the main failure mode of calling with an unknown type.

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

All Clipform 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