Skip to main content
Glama
Sign In

TenQueue

by com.tenqueue
OverviewDiscussionsAdmin

Publish live game

publish_quiz
Destructive

Changes data. Publish the quiz as a live game, using one event credit already on the maker's account. A credit is for up to 100, 500, 1,000 or 5,000 players; the game takes as many players as its credit. Pass players (the expected group size) to use the smallest credit that fits; without it the largest credit is used. Call only after the maker explicitly approved the content and confirmed using a credit (confirm=true). If no suitable credit is available the result says so; then tell the maker it is not available on their current account and give the informational link. Never offer to buy anything.

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": {
      "quiz_id": "<quiz_id>",
      "confirm": "<confirm>"
    },
    "name": "publish_quiz"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmYestrue only after the maker's explicit approval
playersNoExpected number of players, if the maker said; picks the smallest credit that fits
quiz_idYesquiz_id returned by create_quiz or list_quizzes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and non-idempotent, and the description adds the crucial substance behind that: one event credit is consumed, credits come in fixed player tiers, and the game inherits the credit's capacity. It does not spell out the consequence of calling twice (a second credit spent) or whether a published game can be unpublished, so it stops short of full disclosure.

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?

Front-loaded with 'Changes data' then the operation, and the conditional branches are ordered sensibly. It runs long and repeats the confirm-approval idea that the schema already carries, but most sentences encode real policy or cost information.

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 destructive, quota-consuming mutation with no output schema, the description covers cost, capacity semantics, gating, and the failure branch ('the result says so'), which is enough for an agent to act correctly and recover. Remaining unknowns are minor and partly served by sibling tools such as get_game_links.

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%, so the baseline is 3, but the description adds meaning the schema does not: the concrete credit tiers (100/500/1,000/5,000) and the default behavior when 'players' is omitted (largest credit is used). That materially changes how an agent should set the optional parameter.

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?

States a specific verb and resource — 'Publish the quiz as a live game' — and immediately frames the operation as a data-changing, credit-consuming action, which cleanly separates it from preview_quiz, start_test_game and create_quiz among the siblings.

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?

Gives explicit preconditions ('Call only after the maker explicitly approved the content and confirmed using a credit (confirm=true)'), describes the no-credit branch and the required follow-up message, and adds a hard policy boundary ('Never offer to buy anything'). The agent knows when to call, when not to, and what to do on failure.

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

All TenQueue toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources