Skip to main content
Glama

AskOne: Live Q&A and Polls

by io.github.phuryn
OverviewDiscussionsAdmin

Close a room

close_room
DestructiveIdempotent

Close an open room: the audience can no longer join, ask or vote, and every live survey in it closes at the same moment; questions and results stay readable. Use it when the session ends, then read the Q&A with get_room_qa; reopen it later with open_room. A prepared room cannot be closed (room_not_open). Returns the room and its links. No email is sent. Needs rooms:write.

Input Schema

NameRequiredDescriptionDefault
codeYesThe room's six-character code (letters and digits, any case), from list_rooms or create_room.

Output Schema

NameRequiredDescriptionDefault
roomYes
host_urlYes
join_urlYes
projector_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / code / description
      Added value: +"The room's six-character code (letters and digits, any case), from list_rooms or create_room."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "host_url": {
+      "type": "string"
+    },
+    "join_url": {
+      "type": "string"
+    },
+    "projector_url": {
+      "type": "string"
+    },
+    "room": {
+      "properties": {
+        "closed_at": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "code": {
+          "type": "string"
+        },
+        "counts": {
+          "properties": {
+            "active": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "answered": {
+              "description": "Included in questions.",
+              "minimum": 0,
+              "type": "integer"
+            },
+            "participants": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "pending": {
+              "minimum": 0,
+              "type": "integer"
+            },
+            "questions": {
+              "description": "Approved and answered questions.",
+              "minimum": 0,
+              "type": "integer"
+            }
+          },
+          "required": [
+            "questions",
+            "pending",
+            "answered",
+            "participants",
+            "active"
+          ],
+          "type": "object"
+        },
+        "created_at": {
+          "type": "string"
+        },
+        "description": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "name": {
+          "type": "string"
+        },
+        "opened_at": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "status": {
+          "description": "prepared: not joinable yet; open: live; closed: not joinable, content stays readable.",
+          "enum": [
+            "prepared",
+            "open",
+            "closed"
+          ],
+          "type": "string"
+        }
+      },
+      "required": [
+        "code",
+        "name",
+        "status",
+        "description",
+        "created_at",
+        "opened_at",
+        "closed_at",
+        "counts"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "room",
+    "join_url",
+    "projector_url",
+    "host_url"
+  ],
+  "type": "object"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say this is a destructive, idempotent, open-world write; the description goes further by stating the concrete side effects (audience lockout, simultaneous survey closure, data preserved as readable), the error case, the permission required (rooms:write), and that no email is sent. That is exactly the extra context annotations cannot carry.

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 the action and its effects, then usage, precondition, return and side notes in a tight sequence; every sentence carries information. It is densely packed with semicolon clauses, which is efficient but slightly crammed.

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?

Returns are covered by an output schema, yet the description still notes the room and links are returned; prerequisites, error behavior, permission scope and post-call workflow are all present. An agent has everything needed to call this correctly and safely.

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?

Only one parameter (code) and schema description coverage is 100%, so the schema already documents format, pattern and provenance. The description adds no parameter-level meaning, which matches the baseline of 3 when structured data does the work.

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?

Specific verb + resource ('Close an open room') followed immediately by the exact effects on the resource: audience blocked from joining/asking/voting and linked surveys closed. It is clearly distinguishable from open_room and close_survey without opening any schema.

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 ('when the session ends'), names the follow-up tool (get_room_qa) and the alternative for the opposite action (open_room), and states a blocking precondition ('A prepared room cannot be closed (room_not_open)'). Nothing is left to inference.

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

All AskOne: Live Q&A and Polls 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