Skip to main content
Glama

Get share links

get_share_links
Read-only

Get every way of handing a form to other people: the public link, a QR code image for print, an HTML snippet that puts the form inside a page they already have, and a read-only results page that opens in a browser with no login.

Call this when someone asks how to share a form, wants a QR code for a poster or a slide, wants the form on their own website, or wants to show the answers to somebody who is not in this conversation — a co-organiser, a colleague, a client. If they only want the form link itself, get_form already returns it and this call is unnecessary. If they want the data in their own hands as a spreadsheet, use export_responses instead.

The results page shows the most recent answers and works for thirty days. Anyone holding the link can read it, so say so when you hand it over.

A draft form has no public page yet, so its form link and QR code do not resolve until it is opened with set_form_status.

Example: { form_id: "k3nq8vre2p" }

Input Schema

NameRequiredDescriptionDefault
form_idYesThe form id from create_form or list_forms, or the slug from its share link (the part after /f/).

Output Schema

NameRequiredDescriptionDefault
embed_htmlYes
public_urlYes
qr_svg_urlYes
results_urlYes
results_expires_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint annotations by disclosing that the results page shows only recent answers, expires after thirty days, is readable by anyone holding the link, and that draft forms have no resolving link or QR until set_form_status is called. These auth, lifetime, and gating details are the kind of context an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then usage routing, then behavioral caveats, then an example. Every sentence carries distinct, actionable information with no filler.

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?

An output schema exists so return shapes need not be spelled out, and the description still covers the critical gotchas (draft forms, 30-day expiry, public readability, sibling alternatives). Nothing an agent needs to call it correctly is missing.

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 the single form_id parameter is already fully documented in the schema (id from create_form/list_forms or the slug after /f/). The description's example value adds a concrete illustration but no new semantic meaning, so the baseline 3 applies.

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?

A specific verb ('Get') plus resource ('share links'), and it enumerates the four concrete artifacts returned (public link, QR code image, HTML snippet, read-only results page). It clearly distinguishes itself from get_form and export_responses by naming both.

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?

Explicit when-to-use triggers are given (asks how to share, wants a QR for a poster/slide, wants it on their site, wants to show answers to an outsider). Explicit when-not routing is also present: 'get_form already returns it and this call is unnecessary' and 'use export_responses instead' for spreadsheets.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources