Skip to main content
Glama
orjahren

Nettskjema MCP Server

by orjahren

delete_forms

Destructive

Remove one or more Nettskjema forms by ID. Deleted forms are moved to trash for limited-time restoration before permanent removal.

Instructions

Delete one or more forms by their IDs.

Deleted forms are moved to the trash and can be restored for a limited time. This operation is destructive and cannot be undone after the trash retention period expires.

Input Schema

NameRequiredDescriptionDefault
form_idsYesA list of form IDs to delete.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the safety profile is covered structurally; the description adds genuinely new context by disclosing soft-delete semantics (moved to trash, restorable for a limited time) and the point at which deletion becomes irreversible. It omits auth/permission requirements and response shape, but the trash-retention detail is real value beyond the annotation.

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?

Three short sentences, front-loaded with the action and scope, then the recoverability caveat and the irreversibility window. Nothing is wasted, though the last sentence partially restates the destructive nature already flagged by annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations cover the destructive flag, so the description only needs to add behavioral context — which it does via trash retention and irreversibility. It is close to complete for a one-parameter delete tool, with only auth/permission behavior left unaddressed.

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% for the single form_ids parameter, and the description adds no format or syntax detail beyond what the schema already documents. Baseline 3 applies when the schema carries the parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource (delete forms) and notes batch capability via 'one or more forms by their IDs'. It is clearly distinct from delete_submissions and delete_all_submissions by resource, but it never explicitly names a sibling or draw the boundary for the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no alternatives named. The trash/retention detail implies recoverability but the description never tells the agent when this tool is the right choice versus the other delete_* siblings.

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