Skip to main content
Glama
OuattaraTech

kobotoolbox-mcp-server

by OuattaraTech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Replace KoboToolbox Form Questions

kobo_update_form
DestructiveIdempotent

Replace the complete question list of an existing form. Removed questions are deleted and their collected answers become orphaned, no longer appearing in exports.

Instructions

Replace the ENTIRE question list of an existing form with a new one.

Prefer kobo_patch_form for targeted edits (relabelling, adding choices, changing skip logic) — it leaves the rest of the form untouched and cannot accidentally drop questions.

Args:

  • uid (string): asset uid of the form to update

  • questions (array): FULL replacement list — any question left out is REMOVED from the form

  • redeploy (boolean, default true): redeploy so the new version goes live

  • confirm_replace (boolean): must be true when the form already has submissions

Notes:

  • Existing submissions are preserved, but answers to removed questions become orphaned and stop appearing in exports.

  • The question list is validated locally before anything is sent to Kobo.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesAsset uid of the form to update (from kobo_list_forms)
redeployNoIf true, redeploy the form after updating so the new version goes live
questionsYesFULL replacement list of questions — any question left out is deleted from the form.
confirm_replaceNoRequired (true) when the form already has submissions: replacing the structure can orphan collected data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds concrete consequences: submissions are preserved while answers to removed questions become orphaned and disappear from exports, and validation happens locally. This goes beyond the structured hints, though it doesn't cover authentication or failure modes.

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 description front-loads the core action and the sibling differentiation, then uses a clean Args/Notes structure. It is somewhat lengthy, but each section earns its place by communicating destructive behavior, safety conditions, and alternative routing.

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 destructive 4-parameter tool with a fully detailed input schema, the description covers high-level behavior, data consequences, and tool selection guidance. There is no output schema, so return values needn't be described; an agent has everything needed to invoke it safely.

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 each parameter is already thoroughly documented in the schema. The description reinforces the critical 'left-out questions are removed' semantics but adds no new meaning beyond the property descriptions, so the baseline 3 is appropriate.

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 description opens with a precise statement: 'Replace the ENTIRE question list of an existing form with a new one.' The explicit emphasis on 'ENTIRE' and the contrast with kobo_patch_form immediately distinguish this destructive full-replacement tool from its sibling for targeted edits.

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?

Guidance is explicit: 'Prefer kobo_patch_form for targeted edits... it leaves the rest of the form untouched and cannot accidentally drop questions.' It also explains when confirm_replace is required and what redeploy does, so an agent knows both when to use this tool and when to avoid it.

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

Deploy Server

Other Tools