nc-mcp-server

create_form

Create a new form, optionally cloning questions and options from an existing form ID. Returns a new form with a generated ID and empty title for further editing.

Instructions

Create a new form. Returns the form with a generated id and default empty title.

Args: from_id: Optional id of an existing form to clone (copies questions and options; does not copy submissions or shares).

Returns: JSON of the new form. Use update_form to set title/description, then create_question to add questions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_form"
  }
}

Input Schema

Name	Required	Description	Default
`from_id`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 21, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations only provide readOnly/idempotent/destructive hints, so the description carries the behavioral burden. It discloses return behavior, the default empty title, and the important clone boundary that submissions and shares are not copied. It does not mention permissions or error behavior, but the core side effects are transparent.

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?

The description is compact and well-structured: a one-sentence summary, an Args section, a Returns section, and a brief workflow. No fluff, and every sentence adds either behavior or routing information.

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 create tool with an output schema, the description covers what the tool does, what it returns, how the optional parameter behaves, and what to do next. Nothing essential is missing for correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully document from_id. It does: optional id of an existing form to clone, copying questions and options, but not submissions or shares. This adds meaningful semantic detail far beyond the bare integer-or-null schema.

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?

The description uses a specific verb and resource ('Create a new form') and adds concrete details about the generated id and default empty title. It also clearly differentiates this tool from nearby siblings by explicitly pointing to update_form and create_question as follow-up steps.

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 an explicit workflow: use update_form to set title/description, then create_question to add questions. It also explains the cloning use case via from_id. It does not give formal 'when not to use' guidance, but the context is clear enough for an agent to select this tool correctly.

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

Deploy Server