Skip to main content
Glama

Set KoboToolbox Form Sharing

kobo_set_sharing
DestructiveIdempotent

Control who can fill in or work on a form: enable anonymous public submission links, grant view/edit/manage access to collaborators, or revoke permissions.

Instructions

Control who can fill in a form and who can work on it.

Two independent things:

  • anonymous_submissions: makes the collect link usable by ANYONE who has it, with no Kobo account. This is what turns a deployed form into a genuinely public link. It never lets the public read the responses already collected — only submit new ones.

  • share_with / revoke_from: give or remove named collaborators' access to the form and its data.

Roles:

  • view: see the form and read its submissions

  • edit: also add and change submissions, and edit the form

  • manage: full control, including sharing it further

Args:

  • uid (string): asset uid of the form

  • anonymous_submissions (boolean, optional): true to publish, false to revoke

  • share_with: [{username, role}]

  • revoke_from: [usernames] — removes every permission that user holds

  • response_format ('markdown' | 'json')

Returns: the resulting access list, and the collect links when the form becomes public.

Examples:

  • "Make my form publicly fillable" -> anonymous_submissions=true

  • "Let Awa edit the data" -> share_with=[{username:"awa", role:"edit"}]

Notes:

  • Publishing a form is outward-facing: anyone with the URL can then submit. Confirm with the user before enabling it unless they asked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesAsset uid of the form
share_withNoGrant collaborators access to the form
revoke_fromNoKobo usernames whose access should be removed entirely
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown
anonymous_submissionsNotrue makes the Enketo collect link usable by anyone without a Kobo account — this is what turns a deployed form into a genuinely public link. false revokes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Despite annotations already covering destructiveHint and readOnlyHint, the description adds valuable behavioral context: anonymous_submissions never exposes existing responses to the public, only allows new submissions; revoke_from removes every permission a user holds; and publishing is outward-facing and should be confirmed with the user. These details go beyond the annotations and give an agent a solid mental model of the tool's side effects.

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 is well-structured with clear sections (purpose, mechanisms, roles, args, returns, examples, notes) and front-loads the core purpose. It is somewhat long, and the Args section largely repeats the input schema's descriptions, which is redundant. Overall, the organization earns its place, but tightening the redundant parts would make it stronger.

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 tool with no output schema, the description explicitly states what it returns (the resulting access list and collect links when public), making agent expectations clear. It covers all five parameters, gives role semantics, includes examples, and highlights the one risky behavior (public publishing) with a confirmation note. Nothing essential for correct invocation 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%, which sets the baseline at 3. The description still adds meaningful semantics: it explains that anonymous_submissions is what turns a deployed form into a genuinely public link, clarifies the role hierarchy, and provides concrete examples that map user intents to specific parameter values. This goes beyond simply restating the schema, though the Args section does partially duplicate schema text.

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 specific verb and resource: 'Control who can fill in a form and who can work on it.' It then breaks the purpose into two concrete, distinct mechanisms (anonymous_submissions vs. share_with/revoke_from), which clearly separates it from siblings like kobo_update_form (editing form content) or kobo_deploy_form (deployment). This is an unambiguous, well-differentiated statement of what the tool does.

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

Usage Guidelines4/5

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

The description makes the usage context clear through the two-mechanism breakdown, role definitions, and concrete examples mapping natural-language requests to argument values. It also includes an important caution to confirm before enabling public submissions. However, it does not explicitly name alternatives or state when not to use this tool versus related ones, so it falls just short of the top score.

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