Riddle Quiz Maker

media_upload_link

Creates a single-use link for uploading ONE media file into the media library. Call it when the user has a LOCAL file for a Riddle: this server cannot receive bytes, so the upload is yours. A link expires after 5 minutes, dies on first use (successful or not), and only 20 are handed out per account per 5 minutes - so create one immediately before each upload, a batch one file at a time rather than the links up front, and never store or share one. Check the file BEFORE minting a link, since a link a rejected file burns is gone: an image, a video or an audio file, at most 10 MB (some environments cap lower - "maxBytes" and "allowedTypes" in the answer are the authoritative pair). Returns {uploadUrl, expiresAt (UTC), singleUse, maxBytes, allowedTypes, usage, requiresNetworkAccessTo}. POST the file to "uploadUrl" as multipart/form-data under the field name "file" - "usage" is that command ready to run, e.g. curl -F 'file=@/path/to/image.png' '' (the link carries its own signature, so no API key or header). That POST leaves your environment and needs outbound HTTPS to the host in "requiresNetworkAccessTo" (allowlist the wildcard it gives; in Claude only an admin can change that organization setting). If it is blocked or does not resolve, tell the user which host to allow - do not retry or look for another way in. The POST answers with {mediaId, type, width, height, size, folderId}: "mediaId" is the ONLY handle - use it as "media": {"type": "Image", "mediaId": } in a block (riddle://reference/riddle-builder/block-types). Never guess a url for it: a CDN url passed as a plain "url" media is re-downloaded as a second, unrelated copy - the account pays twice and this file records no usage, which makes an image in a live Riddle look safe to delete. The file lands in the account's "AI Uploads" folder tagged "AI Upload" (fixed, so the user can review what an agent uploaded in one place), counts against their storage, and media_delete removes it again.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

AddedSep 2, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description discloses numerous behavioral traits beyond the sparse annotations: expiration after 5 minutes, single-use even on failure, per-account rate limit of 20 per 5 minutes, return field semantics, exact POST requirements (multipart/form-data under field 'file'), storage location in 'AI Uploads', and interaction with media_delete. This far exceeds what annotations convey.

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

Conciseness3/5

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

The description is dense and informative, but it runs long and includes an awkward meta-transition ('Let's go over the description again') that disrupts flow. Every sentence carries value, but the structure is not optimized for quick scanning; it mixes rate limits, return fields, storage notes, and CDN warnings in a single block.

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 input schema and no output schema, the description is exceptionally complete. It explains the full lifecycle: why one link per upload, how to upload, what the response contains, where the file lands, how it counts against storage, and how to delete it. An agent has everything it needs to call this correctly.

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?

The tool has zero parameters, and schema coverage is 100% (empty schema). Baseline for 0 params is 4. The description doesn't need to explain parameters but instead explains the output contract and usage flow, which 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 starts with a specific verb-resource pair: 'Creates a single-use link for uploading ONE media file into the media library.' It clearly distinguishes itself from media_delete and any other sibling by focusing on the upload-link creation flow, and the scope is explicitly limited to one file.

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?

It gives an explicit trigger condition: 'Call it when the user has a LOCAL file for a Riddle' and explains why (the server cannot receive bytes). It also provides operational constraints: create links immediately before each upload, batch one file at a time, never store or share links, and check the file before minting. This is actionable, context-rich guidance beyond a simple 'use this for uploads.'

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

All Riddle Quiz Maker tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?