RooQuiz

List bookings

list_bookings

Read-only

List the bookings of the current team, earliest first: calls respondents booked through Cal.com from a quiz result page (synced back by the Cal.com connector; provider "calcom"), plus read-only history from the retired built-in scheduler (provider "native"). Each item carries the time range, status, the Cal.com event type, the attendee, the source quiz and submission, and the lead owner. Read-only: reschedule, cancel or confirm a booking in Cal.com and the change syncs back. Filter by status / quiz / respondent / time range. Reference a booking by its bookingId; the attendee name / email come back masked.

Input Schema

Name	Required	Description
`to`	No	Only bookings starting strictly before this ISO datetime, optional
`from`	No	Only bookings starting on/after this ISO datetime, optional
`page`	No	Page number (1-based), default 1
`sort`	No	Sort by start time, default startAt (earliest first)
`limit`	No	Items per page, default 20, max 100
`formId`	No	Only bookings that came from this quiz, optional
`status`	No	Filter by status. pending = a request still awaiting confirmation in Cal.com, scheduled = a confirmed meeting, the rest are terminal. Optional.
`recordId`	No	Only bookings tied to this submission record, optional
`examineeId`	No	Only bookings by this respondent — the internal examinee id (get_lead's respondent.id), not the examineeId business code. Optional.

Output Schema

Name	Required	Description
`page`	No	1-based page returned
`items`	No	The page of bookings (earliest first by default)
`totalDocs`	No	Total bookings matching the filter
`totalPages`	No	Total pages available

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 26, 2026

changedInput schema / properties / status / description

Previous value: -"Filter by status. pending = a request awaiting approval (the team has requireApproval on), scheduled = a confirmed meeting, the rest are terminal. Optional."New value: +"Filter by status. pending = a request still awaiting confirmation in Cal.com, scheduled = a confirmed meeting, the rest are terminal. Optional."

addedOutput schema / properties / items / items / properties / eventTypeTitle

Added value: +{
+  "description": "Cal.com event type title (calcom only)",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / items / items / properties / provider

Added value: +{
+  "description": "calcom = booked through Cal.com; native = history from the retired built-in scheduler",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / items / items / properties / status / description

Previous value: -"pending / scheduled / completed / no_show / cancelled"New value: +"pending / scheduled / completed / no_show / cancelled / declined"

Changed4 schema fields changedSep 9, 2026

changedOutput schema / properties / items / items / properties / form / description

Previous value: -"The quiz the booking came from"New value: +"The quiz the booking came from as { id, title }"

changedOutput schema / properties / items / items / properties / form / type

Previous value: -[
-  "string",
-  "number",
-  "null"
-]New value: +[
+  "object",
+  "null"
+]

changedOutput schema / properties / items / items / properties / record / description

Previous value: -"The submission the booking is tied to"New value: +"The submission the booking is tied to as { id, serialNumber, shareToken }"

changedOutput schema / properties / items / items / properties / record / type

Previous value: -[
-  "string",
-  "number",
-  "null"
-]New value: +[
+  "object",
+  "null"
+]

First observedAug 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered; the description nonetheless adds non-obvious behavior – the two provider sources, that reschedules/cancels in Cal.com propagate back, and that attendee name/email are returned masked. The masking disclosure in particular is operationally important and appears nowhere in the annotations.

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?

Effectively front-loaded: the core action and ordering come first, filters and identifiers follow. The second sentence carries a long parenthetical about providers and a full field inventory, which is useful but slightly overpacked relative to the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, full parameter descriptions and annotations available, the description supplies the parts structured data cannot: data provenance, sync direction, and result masking. The remaining gap is minor – page/limit behavior is left entirely to the schema.

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%, so the baseline is 3; the schema already documents from/to/status/formId/recordId/examineeId precisely, including the pending vs scheduled status meanings. The description recaps the filter dimensions and the 'reference by bookingId' convention but adds no format or edge-case detail beyond the schema.

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?

Opens with a specific verb and resource plus scope: 'List the bookings of the current team, earliest first.' It goes further than the name by defining what a booking actually is here – Cal.com-synced bookings plus read-only history from the retired native scheduler – which is information an agent cannot infer from the title.

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?

Gives clear operating context: it is read-only, changes made in Cal.com sync back, and results can be narrowed by status/quiz/respondent/time range with bookingId as the reference key. It does not state when a different tool should be used instead, but no sibling in the list covers bookings, so there is no real routing ambiguity to resolve.

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

All RooQuiz tools Inspect

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

Need Help?