Nettskjema MCP Server

Overview Schema Source Related Servers Discussions Admin

replace_form_elements

Destructive

Replace a Nettskjema form's full element list by sending the complete array; any omitted elements are deleted. Use to set all questions, headings, and page breaks at once.

Instructions

Replace the form's ENTIRE element list. Every element you leave out is DELETED.

This is not an "add an element" tool. Whatever you send becomes the form's complete content: any question, heading, image or page break that is not in elements is removed from the form. To add or change anything, call get_form_elements first, modify the array it returns, and send all of it back — or call update_form_element, which does that read-modify-write for one element. Sending a one-element list to a ten-element form deletes nine elements.

Nothing locks the form in between: an edit made by someone else after your get_form_elements call is overwritten by this one without warning. The endpoint offers no version field, ETag or conditional header to detect that.

Each element is checked against the vendored ElementDTO schema before the request is sent: elementType is required on every element and must be one of the known types, and every field the schema declares is checked for type and range. A field the schema does not declare is passed through to the API rather than rejected here, so an element read back from a newer API than the vendored snapshot can still be written back unchanged.

Input Schema

Name	Required	Description	Default
`form_id`	Yes	The form's numeric ID.
`elements`	Yes	The complete list of elements the form should have, in order. Anything missing from this list is deleted. Keep each existing element's elementId so the API updates it instead of recreating it.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations supply only destructiveHint=true, and the description goes well beyond that: concurrent edits made after get_form_elements are silently overwritten, no version field/ETag/conditional header exists to detect it, and each element is validated against the vendored ElementDTO schema with unknown fields passed through. This is exactly the extra behavioral context the annotation does not carry.

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 critical destructive warning is front-loaded in the first sentence, and each paragraph (destructive semantics, sibling alternatives, concurrency, validation) covers a distinct concern. It is longer than typical, but the length is justified by the danger of a silent mass-delete.

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?

With an output schema present the description need not explain return values, and it covers everything else an agent needs: full-overwrite semantics, the get/modify/resend workflow, the update_form_element alternative, lost-update concurrency risk, and validation behavior. Nothing material is missing for a 2-param destructive tool.

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?

Schema description coverage is 100% and the schema already explains that elements is the complete ordered list and that existing elementIds should be preserved. The description restates that same semantic (complete content, omitted elements removed) without adding format, ordering, or elementId syntax details beyond the 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?

States a precise verb+resource ('Replace the form's ENTIRE element list') and immediately scopes it as a full overwrite, not an append. It explicitly distinguishes itself from the 'add an element' interpretation and from update_form_element, so an agent can pick between siblings without opening their schemas.

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 explicit when-to-use routing: call get_form_elements first and send the modified array back, or use update_form_element for the read-modify-write of a single element. It also warns when NOT to use this by describing the destructive consequence of a partial list, with a concrete example (one-element list on a ten-element form deletes nine).

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