Skip to main content
Glama

Share a quiz as a playable link

quiz_video_share_quiz
Idempotent

Get a URL where people take a quiz in their browser with no sign-in, and set who can open it. unlisted (the default) works for anyone with the link and is never listed or indexed; public also lists it in the quiz library and search engines; private turns the link off. Returns visibility, playUrl, quizUrl (public quizzes only) and embedHtml. Fails if the quiz has no questions with answers yet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "quizId": "<quizId>"
    },
    "name": "quiz_video_share_quiz"
  }
}

Input Schema

NameRequiredDescriptionDefault
quizIdYes
visibilityNoWho can open the quiz.unlisted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is partly covered. The description still adds real behavior: viewers need no sign-in, 'private' effectively revokes the link, and the call fails when the quiz has no questions with answers. It does not discuss caller-side auth or rate limits, so it is strong but not exhaustive.

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?

Two sentences, front-loaded with the outcome, then the visibility semantics, then the return shape, then the failure condition. No sentence is redundant and no filler is present.

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 two-parameter tool with no output schema, the description covers purpose, access-control semantics, returned fields (visibility, playUrl, quizUrl, embedHtml), and the precondition for failure. An agent has everything needed to call it and interpret the result.

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 only 50% (quizId is undocumented), yet the description compensates by spelling out all three visibility states, their indexing/listing consequences, and the default. quizId's meaning is self-evident from its name and the tool purpose, so nothing important is left ambiguous.

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 states a specific outcome: 'Get a URL where people take a quiz in their browser with no sign-in, and set who can open it.' That is a distinct verb+resource (share-link generation plus access control) that cannot be confused with siblings like quiz_video_create_quiz or quiz_video_get_quiz.

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 gives usable selection guidance for every visibility value ('unlisted' default, 'public' also lists in the library and search engines, 'private' turns the link off) so the agent can pick correctly without opening the schema. It stops short of naming a sibling alternative or stating when not to share at all, so it is clear context rather than a complete when/when-not rule set.

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