nc-mcp-server

update_form

Idempotent

Update a form’s settings—title, anonymity, submission limits, expiration, and more—by passing the form ID and key-value pairs. Returns the refreshed form JSON.

Instructions

Update a form's properties.

Args: form_id: Numeric form id. key_value_pairs: Object with the fields to change. Common keys: title (str), description (str), isAnonymous (bool), submitMultiple (bool), allowEditSubmissions (bool), expires (unix timestamp, 0 = never), showExpiration (bool), state (0=active, 1=closed, 2=archived), maxSubmissions (int, 0 = unlimited), submissionMessage (str), access (object with permitAllUsers/showToAllUsers), fileFormat, path (destination folder for the generated submissions spreadsheet — must be sent together with fileFormat to (re)link the form to a file).

Returns: JSON of the updated form (refetched after the patch for convenience).

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>",
      "key_value_pairs": "<key_value_pairs>"
    },
    "name": "update_form"
  }
}

Input Schema

Name	Required	Description	Default
`form_id`	Yes
`key_value_pairs`	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.3/5.0

Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail by stating that the JSON of the updated form is refetched after the patch, and it clarifies a special coupling requirement between fileFormat and path. It does not contradict 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but earned by the high number of customizable form properties. It is well-structured with an Args section and a Returns section, and the core purpose is front-loaded. A minor inefficiency is that the long key list could be formatted more compactly, but nothing is extraneous.

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 update tool with a flexible object parameter, the description provides a comprehensive field reference, return behavior, and special constraints. The output schema already covers return expectations, and the description fills in all remaining practical details an agent needs to invoke the tool correctly.

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 coverage is 0%, so the description carries the full burden of parameter documentation. It thoroughly explains form_id and enumerates the common keys of key_value_pairs with their types, allowed values, and special rules. This far exceeds the minimal 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 opens with a clear verb and resource: 'Update a form's properties.' It is unambiguous about what the tool operates on and is easily distinguishable from siblings like create_form, get_form, and delete_form. The detailed argument list further clarifies the scope.

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?

The description identifies the tool as an update operation but does not explicitly state when to use it versus alternatives such as create_form or update_question. The intended use is implied by the name and the fields listed, but no exclusions or alternative routing are provided. It does add useful context about the fileFormat/path constraint, which helps correct usage.

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

Deploy Server