Skip to main content
Glama
OuattaraTech

kobotoolbox-mcp-server

by OuattaraTech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get KoboToolbox Collect Links

kobo_get_collect_links
Read-onlyIdempotent

Retrieve shareable Enketo links for a deployed KoboToolbox form: offline, online, single, preview, and iframe URLs, plus public status and optional QR code for printing.

Instructions

Get the shareable links of a deployed form — the actual deliverable once a form is built.

Returns every Enketo URL Kobo publishes:

  • offline: caches in the browser and works without a connection, syncing later. The one to give field teams.

  • online: plain web form

  • single: submits once and closes, for one-response-per-person links

  • preview: renders the form without saving anything, for internal review

  • iframe: to embed the form in a web page

It also reports whether the form is genuinely PUBLIC. A deployed form's link still asks for a Kobo login until anonymous submissions are enabled — use kobo_set_sharing for that.

Args:

  • uid (string): asset uid of the deployed form

  • include_qr (boolean, default false): also return a QR code image of the offline link, to print on a flyer, a poster or a table card

  • response_format ('markdown' | 'json')

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uidYesAsset uid of the deployed form
include_qrNoAlso return a QR code image of the offline collect link, to print on a flyer or a table card
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavior beyond that by enumerating every returned link type (offline, online, single, preview, iframe) and revealing that the tool also reports the form's public-facing login requirement.

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 bullet lists make the five return variants and the QR/format arguments easy to scan. The Args section partially duplicates the schema, so not every line earns its place, but the size is still reasonable for a tool with no output 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?

Since there is no output schema, the description fully carries the responsibility of describing return content. It explains the five URL types, the public/login caveat, the optional QR image, and the response_format choices, which is sufficient for an agent to call the tool correctly.

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 baseline is 3 and the description only needs to add marginal value. It repeats the uid, include_qr, and response_format details almost exactly as the schema does, with only a small addition like printing the QR code on a flyer.

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 ('Get the shareable links of a deployed form') and clarifies this is the final deliverable once a form is built. It enumerates all five Enketo URL variants so there is no confusion about what the tool produces, and it explicitly points to kobo_set_sharing for the related but different task of enabling anonymous access.

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?

It tells the agent this is the tool to use after a form is deployed and for distributing links to field teams, while also giving one explicit alternative: use kobo_set_sharing to make a form genuinely public. It lacks a broader when-not-to-use statement against all sibling tools, so it is not a full routing guide.

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