nc-mcp-server

create_options

Add answer options to choice questions in forms. Provide form ID, question ID, and option labels to create them in order, returning assigned IDs and order.

Instructions

Add one or more answer options to a choice question (dropdown/multiple/etc.).

Args: form_id: Numeric form id. question_id: Numeric question id. Intended for choice-type questions (dropdown, multiple, multiple_unique, linearscale, grid); options on other types are accepted by the server but have no effect. option_texts: Array of option labels to create. Each creates a separate option in order.

Returns: JSON array of created options with their assigned ids and order.

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": {
      "form_id": "<form_id>",
      "question_id": "<question_id>",
      "option_texts": "<option_texts>"
    },
    "name": "create_options"
  }
}

Input Schema

Name	Required	Description	Default
`form_id`	Yes
`question_id`	Yes
`option_texts`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 21, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate this is a write operation (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds valuable behavioral context: options on non-choice questions are accepted but have no effect, and options are created in order. It also discloses the return value (JSON array of created options with ids and order), which goes beyond the annotations.

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, with a clear summary line followed by parameter explanations and return value. Every sentence earns its place, and the key behavioral caveat (options on other types have no effect) is included without bloat.

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

Completeness4/5

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

Given the tool's moderate complexity (3 required params, no nested objects) and the presence of an output schema, the description is largely complete. It covers the purpose, parameter semantics, and return value. The only minor gap is that it doesn't explicitly state error conditions or prerequisites (e.g., whether the question must exist), but this is not critical for an agent to invoke the tool correctly.

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 description coverage is 0%, so the description must compensate. It explains each parameter: form_id is a numeric form id, question_id is a numeric question id intended for choice-type questions, and option_texts is an array of labels creating separate options in order. This adds meaning beyond the bare schema types, though it could be more explicit about the format of option_texts (e.g., strings).

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 clearly states the action ('Add one or more answer options') and the resource ('choice question'), and distinguishes it from sibling tools like update_option and reorder_options by focusing on creation. It also specifies the intended question types, which helps an agent understand the tool's scope.

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 provides clear context for when to use this tool: when adding options to choice-type questions. It also notes that options on other question types are accepted but have no effect, which is an implicit exclusion. However, it doesn't explicitly name alternatives like update_option or reorder_options for modifying existing options, so it falls short of full when/when-not guidance.

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

Deploy Server