niceform-mcp-server

close_form

DestructiveIdempotent

Stops a published form from accepting new responses immediately while keeping existing responses readable; reopen by publishing again.

Instructions

Close a live form so it stops accepting responses immediately (for example once the RSVP deadline has passed). Existing responses are kept and stay readable.

Only works on a published form; a draft cannot be closed (it returns a conflict error). To reopen, call publish_form again.

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

Input Schema

Name	Required	Description	Default
`form_id`	Yes	The form UUID or public id.

Output Schema

Name	Required	Description	Default
`formId`	Yes
`status`	Yes
`closedAt`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare destructiveHint/idempotentHint/openWorldHint, but the description adds meaning they don't carry: existing responses are preserved and remain readable, draft forms fail with a conflict error, and reopening is done via publish_form. That materially changes how an agent reasons about the 'destructive' flag and covers the failure mode.

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?

Three short sentences, all doing work: effect first, precondition second, reversal path third. Nothing is redundant with the annotations or schema, and the most important constraint is front-loaded.

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?

An output schema exists so return values needn't be explained, and annotations cover the safety profile. The remaining gaps an agent would care about — data retention, error on drafts, reopen path — are all explicitly addressed.

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

Parameters3/5

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

Single parameter with 100% schema description coverage ('The form UUID or public id'), so the schema already carries the semantics. The description adds nothing about form_id format beyond what is documented, so baseline 3 applies.

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 ('Close a live form') plus the immediate effect ('stops accepting responses immediately'), which cleanly separates it from publish_form, list_forms, and the response-reading siblings. No ambiguity about what the operation does.

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 use case (RSVP deadline passed), an explicit precondition (only published forms; drafts return a conflict error), and names the alternative path for reversing it ('To reopen, call publish_form again'). When-to-use, when-not, and alternative are all present.

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

Deploy Server