Nettskjema MCP Server

Overview Schema Source Related Servers Discussions Admin

upload_submission_attachment

Destructive

Upload a file to a Nettskjema submission question using its attachment token. Optionally transcribe audio/video with language, model, speaker, or translation options.

Instructions

Upload an attachment to a submission question, optionally requesting transcription.

The entire file is read into memory before uploading. The filename and fileSize are derived from the file itself rather than accepted as parameters, so they cannot drift out of sync. An audio recording awaiting transcription can be tens of megabytes; the whole file is held in RAM during the upload.

The attachment token comes from the attachmentToken field in the response body of POST /form/{formId}/submission. It authorizes writing to someone else's submission and must be kept as secure as the access token itself.

The spec does not document what happens when the named questionId already has an attachment. An upload may silently replace a respondent's file.

Transcription options apply only when the uploaded file is audio or video. The six supported models are: model_auto, nb_whisper_large_semantic, nb_whisper_large_verbatim, openai_whisper_large_v3, openai_whisper_large_v2, and KBLab-large. The language parameter accepts 100+ language codes; passing an unknown code raises BadRequestError naming the allowed values. The diarize flag requests speaker identification, and translate_to_english requests translation to English after transcription.

Input Schema

Name	Required	Description
`model`	No	Transcription model. Optional; the spec declares no default.
`diarize`	No	Request speaker identification in the transcription.
`language`	No	Language code for transcription (e.g., "en", "no", "auto"). Optional; the spec declares no default.
`file_path`	Yes	Path to the file to upload. May be relative or contain ~.
`question_id`	Yes	The question (form element) ID to attach the file to.
`submission_id`	Yes	The submission's numeric ID.
`attachment_token`	Yes	The attachment token from the submission creation response. Authorizes writing to this submission.
`translate_to_english`	No	Request translation to English after transcription.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With destructiveHint=true already declared, the description still adds substantial context: the whole file is read into RAM, filename/fileSize are derived rather than passed, the attachment token authorizes writes to someone else's submission and must be secured like an access token, and an upload may silently replace an existing attachment. The silent-replacement warning corroborates the destructive hint rather than contradicting it.

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 purpose is front-loaded and most sentences carry distinct, useful information. It is somewhat long and repeats the in-memory file handling across two sentences, but nothing is filler and the structure remains readable.

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 four required parameters and a security-sensitive token, the description covers authorization requirements, side effects, memory behavior, and transcription applicability. With an output schema present and annotations covering the destructive flag, nothing an agent needs to call this safely is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it enumerates the six supported transcription models, states that unknown language codes raise BadRequestError naming allowed values, and explains that diarize and translate_to_english only apply after transcription. The model enum values in particular are absent from the schema and materially help invocation.

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 first sentence states a specific verb (upload) and resource (an attachment to a submission question) plus the optional transcription facet. This cleanly separates it from siblings like upload_image and upload_codebook, which target different resources. An agent can identify the operation without opening the schema.

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 gives conditional context (transcription options apply only to audio/video, and the token must originate from the submission-creation response), which implies when the tool is applicable. However, it never routes the agent against the obvious alternatives such as upload_image or retranscribe_attachment, so usage guidance remains implicit rather than explicit.

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