Nettskjema MCP Server

Overview Schema Source Related Servers Discussions Admin

submit_form

Send a real answer to a Nettskjema form as the authenticated client. Answers are schema-checked before delivery and added to the form's collected data.

Instructions

Deliver a response to a form, as the authenticated API client.

This submits a real answer to a real form: it adds a row to the form's collected data, and the form's owner sees it alongside human responses. There is no draft or preview mode here. Use submit_form_for_invitation instead when answering on behalf of a specific invitation.

Each answer is checked against the vendored ClientAnswerDTO schema before the request is sent, so a bad enum value or a mistyped field fails without reaching the form. A field the snapshot does not declare is passed through to the API, which has the final say.

Input Schema

Name	Required	Description
`answers`	Yes	The answers to deliver, one object per answered element. The schema declares answerId, answerOptionIds, answered, date, datetime, id, ids, questionId, text, time, type and unAnswered; every one is optional. type must be one of SINGLE_OPTION, MULTIPLE_OPTIONS, TEXT, FILE, DATE_TIME, DATE, TIME or NOT_PROVIDED, and date, datetime and time are ISO 8601 strings.
`form_id`	Yes	The form's numeric ID.
`metadata`	No	Optional delivery metadata. The schema declares elapsedTime (integer) and tsdRespondent (an object with personal_identifier, provider, representation, sub, task_id and user_name). Omitted from the request entirely when not given.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses that submission creates a real collected-data row visible to the form owner, that there is no draft or preview, that answers are validated against ClientAnswerDTO before sending, and that unknown fields are passed through to the API.

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 purpose is front-loaded, followed by side effects, the alternative tool, and validation behavior. Every sentence adds useful information, with no redundant restatement of the tool name or schema.

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 mutation tool with an output schema and full schema coverage, the description supplies the essential missing context: real side effects, no preview mode, alternative invocation path, and preflight validation behavior. Nothing critical for correct selection or invocation is omitted.

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%, so the schema already documents form_id, answers, and metadata thoroughly. The description adds some behavioral context about validation and pass-through, but it does not materially expand parameter meaning beyond the schema baseline.

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: deliver a response to a form as the authenticated API client. It also names the sibling tool to use for invitation-based submissions, so an agent can distinguish it from submit_form_for_invitation.

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?

Explicitly says to use submit_form_for_invitation instead when answering on behalf of a specific invitation. It also clarifies there is no draft or preview mode, which gives clear usage context.

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